Constraints are essentially a user interface-oriented tool. To model the motion or evolution of a physical system without collisions, differential equations are the universal tool. However, to be able to write down those equations requires a substantial amount of human intelligence. The use of constraints in an interactive modeling system such as 3D Max is intended to provide the modeler with an expressive medium in which natural propositions such as the following can be expressed, without using mathematics:
"This object is bolted to the reference plane and rotates around point P."
"This object slides along the planar surface S and is free to move in two directions parallel to the surface."
"This mechanical linkage relates points A and B such that if force is applied to A to move it along one degree of freedom, B moves so as to keep the mechanical relationships valid."
There are two broad classes of problems to be dealt with:
- Collisions
and
- Continuous motion
Because collisions are essentiall ydiscrete events which alter the logical relationships between objects, they are almost always dealt with separately from the problems of continuous motion. Typically when rigid objects are involved in collisions, the transfer of momentum and energy is very rapid and requires careful attention to the integration techniques and step size. In most realtime simulations the solutions used are ad hoc and require tuning to get adequate performance.
This lecture concentrates on continuous motion rather than on collisions.
Kinematic and Dynamic Constraints. Kinematics is the mathematical modeling of motion, without regard to the energies and momenta involved. Often it is the case that kinematics is sufficient to produce plausible animations or interactions. "Inverse kinematics" is really no different from kinematics. The implication of "inverse" is that the system will "work backwards" from the desired end position of one more more control points on a mechanical linkage, to infer the positions of other parts of the system so that the goal is achieved.
We begin by studying an early object oriented modeling system called ThingLab, which reveals some general techniques.
ThingLab was developed in the 1980's at the University of Washington by Alan Borning. It was inspired by Sutherland's Sketchpad, the mother of all realtime computer graphics projects. The standard class for introductory discussion is the MidPointLine (we'll call it MPL.) An object of class MPL named 'Line1' has three static attributes: point1, point2 and midpoint, which are its two ends and midpoint respectively. After constraint resolution takes place, the stick is always redrawn by drawing a line from point1 to point2 and making a cross-mark at its midpoint.
When constructing an object, each point contains a list of all the other objects' points to which it is attached. In this example, the only kind of attachment permitted is a rotary joint. We first consider a system with three objects: an anchor A, a handle H, and the line segment Line1 of class MPL.
Initial assumptions:
Line1.point1 is attached to A.
Line1.midpoint is attached to H.
MPL has the following rule and methods which implement it.
rule: midpoint = (point1 + point2)/2)
method move(midpoint, P) (Hereafter referred to as METHOD 1)
If a request comes to the object 'line1' to move
the midpoint to new location P
0) if P=midpoint, return true (success: no movement
needed)
1) a check is made to see if any of the objects attached
to midpoint are anchors
if so, return false (we cannot move this midpoint.)
then each object B attached
to midpoint by some point q is asked
move(B.q, P).
If any object reports that it is immovable, return false.
If no obstacles exist to moving the midpoint, we proceed.
2) The first heuristic is tried. It says
if move(point2, (point1 + 2*(P - point1)))
midpoint=P
return true (we succeeded!)
But if point2 was unmovable for some reason,
3) The next heuristic is tried. It says
if move(point1, (point2 + 2*(P-point2)))
midpoint=P
return true (we succeeded!)
4) If nothing has succeeded at this point, don't
change midpoint.
return false (we failed.)
method move has to be 'overloaded' in that it can tell whether the parameter refers to an endpoint or a midpoint.
Query 15.1 Modify this heuristic to construct a method move(point, P) which moves endpoints.
Query 15.2 If I attach a handle H to the midpoint of a MPL object M which has no anchors and no other objects attached to either of its endpoints, and I move H ten units northward on the screen, describe exactly where M.point1 and M.point2 will go.
Query 15.3 Modify METHOD 1 so that the experiment described in Query 15.2 yields a more physically plausible response.
The above example actually shows a concept called 'propagation of degrees of freedom'. If a given call to 'move' returns false, this means that there are zero degrees of freedom available down this pathway. One can generalize on this so that instead of simply returning 'true' the system returns the number of DOF available to make things true. In some circumstances (discussed below) it is necessary to search for feasible solutions, using this heuristic information.
Query 15.4 Consider a two-stick linkage with objects S1 and S2 in which S1.point1 is anchored, S2.point2 is anchored, and S2.point1 is tied to S1.midpoint. Attach a handle to S2.midpoint and move it. Show that S1.point2 moves appropriately.
Query 15.5 Does METHOD 1 preserve the length of the object? If so, how? If not, how could you modify it so that it did so?
ANSWER
In general when you add a length-preserving feature, you lose the ability for the system to respond to all requests with an exact match. That is, midpoint (or an endpoint) may be told to go to location H but only get partway there. The above constraint could be expressed, for instance, as dist(point1, point2) = k. A penalty function associated with this metric would then be
penalty = (dist(point1,point2) - k)^2
Squaring produces nonnegative results, and actually saves a sqrt step.
Now the problem becomes to find a solution which minimizes the penalty. Next section please.
/ANSWER
Midpointlines are useful and interesting as programming exercises because (without length constraints) they define systems which solve exactly unless you overconstrain them with too many anchors. However, as soon as length constraints come into the picture, it is very easy to define shapes which cause problems.
Query 15.6. Would our naive system developed above have trouble with cyclic constraints? Consider three sticks S1, S2 and S3 which are coupled end to end. Move the midpoint of S2 and see what happens.
ANSWER
Without length constraints, if something can move it will move and the rest of the structure will flex to accomodate. With length constraints, it is necessary to find a consistent solution. This is often done by 'relaxation' - that is, propagate a first assumption through the net of constraints while relaxing some of them if necessary, then ask each constrained point (e. g. anchored points) to move toward their intended location and see if an overall error measure is reduced. Penalty methods are the result.
Penalty Methods
Read Burg's paper, pages 83-92.
Out of time, as usual. Well, we'll go onward from here on the final exam. Heh heh....
JMM