GX Rigid Body Dragging
Volume Number: 12
Issue Number: 8
Column Tag: New Technologies
Dragging and Rigid-Body 
Transformations
QD GX can make your Mac a swinging place
By Lawrence D’Oliveiro
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
QuickDraw GX offers some interesting new possibilities for interactive graphics. This
article is a note on one of them: the idea of dragging an object about, and having it
rotate to follow the drag, just like real objects tend to do when you pull or push them.
The code I’m presenting here is by no means finished; think of it as a rough
sketch, a demonstration of the concept. It is written in Modula-2, and makes heavy use
of my standard libraries, which you can find at
ftp://ftphost.waikato.ac.nz/pub/ldo/MyModLib.hqx.
Feel free to use my code as a starting point for your own experiments.
Transformations in QuickDraw GX
QuickDraw GX supports 3-by-3 mappings, which are capable of applying any kind of
linear transformation to the geometry of a GX shape. (A linear transformation is
one that preserves the straightness of lines. Thus, a GX mapping cannot transform a
straight line to a curve, or vice versa.)
Linear transformations can be broken down into various simple types:
translations (changes of position), rotations, scaling, skewing and perspective. In
fact, any arbitrary linear transformation can be considered to be built from
components of these types.
There are various useful subsets of linear transformations: an affine
transformation is one where any pair of parallel lines remains parallel after the
transformation. GX’s perspective transformations clearly are not affine; thus, an
affine transformation is one that has no perspective component.
An important subset of affine transformations is the set of rigid-body
transformations: these are ones that preserve the distance between any two given
points. Rigid-body transformations consist only of translations and rotations; this
corresponds intuitively to our notions of real rigid bodies, which cannot be scaled or
stretched in any way, though you can usually move them around and reorient them any
way you like (unless they’re a lot bigger or heavier than you are).
Figure 1. As the cursor pulls the arrow to the right, the arrow swings into line with
the direction of motion. These are successive screen shots from my program; the
upper-left corner of each shot is the upper-left corner of the window.
Dragging a Rigid Body
Consider what happens when you try to move a real rigid body. The body has a center
of mass; if you orient the direction of your force so that it passes exactly through this
point, the object will change its position without rotating. But if you offset your force
by any amount, you will produce a torque, and the object will change both its position
and its orientation. (For example, place a book on a smooth surface such a desk, grasp
it by just one corner, and pull in a straight line; the book, as it starts to move, also
swings around to line up its center of mass with the direction of travel.)
Figure 1 shows this happening in my program.
In the following analysis, I’ll follow the rules of Aristotelian, rather than
Newtonian, physics: objects have no inertia, but they are subject to friction, which
acts through their center of mass. Thus, they stop moving as soon as you stop pushing
them.
Figure 2. Movements... Figure 3. ...and analysis
The force you apply can be split into two components: the component parallel to
CF moves the object without rotating it (hence the new position of the center of mass,
D, lies on this line), while the component perpendicular to this line exerts a pure
rotational force on the object without moving the center of mass.
In Figure 2, q is the angle CFG and can have any value, while f is the angle of
rotation FCG, and is assumed to be small (you’ll see why shortly).
this line at the points Cp, Dp, Fp and Gp (Figure 3). Gt is the intersection between
FFp and CG. In this case, q is greater than 90°, so the angle GFGt is q - 90° (I’ll
leave the analysis of the case where q is less than 90° as an “exercise for the reader”,
as they say). Since f is small, FGtG is close to 90°, so the ratio FGtFG is
approximately cos q - 90°, which equals sin q. Now, since GFGt is a right angle, sin f
equals FGtCF which becomes FG sin qCF when you apply the above
approximation.
For larger movements, where the angle f might not be small, simply split the
movement into lots of small steps with correspondingly small f. If you want a
fancy-sounding term for this mathematical trick, it’s called differential calculus.
Translating This Into Code
The next step is to write some actual code based on this analysis. In the following, I’ll
intermingle declarations and statements to suit the exposition, rather than the
requirements of strict language syntax (in other words, I’ll be following the order in
which code is usually written).
VAR
LastMouse, ThisMouse : Point;
ThisDelta : gxPoint;
ShapeCenter : gxPoint;
displacement FG, computed as follows:
ThisDelta.x := IntToFixed(ThisMouse.h - LastMouse.h);
ThisDelta.y := IntToFixed(ThisMouse.v - LastMouse.v);
ShapeCenter is supposed to be the center of mass, or center of geometry, of the
shape. GX provides a call, GXGetShapeCenter, that is supposed to return this in the
coordinate system of the shape geometry itself. You could then put this through the
shape mapping to get the center in “local coordinates”. Unfortunately, when I tried
this, I got incorrect results for a complex picture shape (a QuickDraw GX bug?). So,
to avoid this problem, my code takes ShapeCenter as the center of the shape’s
bounding rectangle, rather than of its actual geometry:
GXGetShapeLocalBounds(TheShape, Bounds);
ShapeCenter.x := (Bounds.right + Bounds.left) DIV 2;
ShapeCenter.y := (Bounds.bottom + Bounds.top) DIV 2;
Next we perform the computation of the actual rotation angle, using good old
floating-point numbers instead of fixed-point ones:
VAR
DeltaX, DeltaY, Delta : LongReal;
RadiusX, RadiusY, Radius : LongReal;
DragAngle, RotationAngleSin : LongReal;
RotationAngle : LongReal;
DeltaX and DeltaY are the x- and y-components of the displacement FG, while
Delta is the magnitude of this displacement.
DeltaX := Fix2Double(ThisDelta.x);
DeltaY := Fix2Double(ThisDelta.y);
Delta := Sqrt(Squared(DeltaX) + Squared(DeltaY));
Similarly, RadiusX and RadiusY are the x- and y-components of thedistance CF,
while Radius is the magnitude of this distance.
RadiusX := Fix2Double(IntToFixed(LastMouse.h) - ShapeCenter.x);
RadiusY := Fix2Double(IntToFixed(LastMouse.v) - ShapeCenter.y);
Radius := Sqrt(Squared(RadiusX) + Squared(RadiusY));
DragAngle is the angle q. I compute it here from the difference between the
angles of the lines FG and CF (ArcTan2(x, y) returns the angle with tangent y/x in
the appropriate quadrant, taking account of the signs of x and y):
DragAngle := ArcTan2(DeltaX, DeltaY) - ArcTan2(RadiusX, RadiusY);
RotationAngleSin is the sine of the angle f. DLimit is just a routine that
constrains its first argument to within the specified limits (in this case, between -1
and 1). The need for this constraint will become apparent later.
RotationAngleSin := DLimit
(
Delta * Sin(DragAngle) / Radius,
FLOATD(-1),
FLOATD(1)
);
And finally, we compute the angle f itself, converting from the floating-point
radians that SANE operates in, to the fixed-point degrees that QuickDraw GX uses:
RotationAngle :=
Double2Fix(ArcSin(RotationAngleSin) * FLOATD(180) / Pi())
Applying the transformation to the shape is pretty straightforward. Simply
obtain the shape’s existing mapping:
VAR
ShapeMapping : gxMapping;
...
GXGetShapeMapping(TheShape, ShapeMapping);
then apply the appropriate movement and rotation:
MoveMapping
(
(*@target :=*) ShapeMapping,
(*hOffset :=*) ThisDelta.x,
(*vOffset :=*) ThisDelta.y
);
RotateMapping
(
(*@target :=*) ShapeMapping,
(*angle :=*) RotationAngle,
(*xCenter :=*) IntToFixed(ThisMouse.h),
(*yCenter :=*) IntToFixed(ThisMouse.v)
);
GXSetShapeMapping(TheShape, ShapeMapping)
is actually the opposite of that in the analysis; thus the effect is the same.
Other Matters
There are several other aspects of the example code that I’ve glossed over so far.
To keep the size of the source code down, the program itself has absolutely the
minimum user interface I felt I could get away with. It doesn’t even have any menus!
When you start it up, it already has a shape loaded that you can try dragging about. You
can bring in a different shape by dragging it into the window, from a Finder clipping
file or another drag-aware application (I’ve provided a few sample clippings you can
try). To quit the program, click the close box in the window.
An important issue is how to do off-screen rendering, so that your on-screen
drawing doesn’t flicker. There is no direct equivalent to QuickDraw GWorlds in
QuickDraw GX, but the GX SDK library code shows you how to create a much more
powerful alternative: an offscreen graphics context that can optimize drawing
simultaneously for multiple screens, rather than just the deepest one that your
window happens to cross.
My actual program uses a routine I wrote called MoveSprite, which creates
temporary offscreen structures every time you call it to move an object. It
automatically sizes these structures to cover only the affected on-screen area (and
doesn’t bother doing off-screen drawing if the old and new positions of the object don’t
overlap). Thus, this routine is simpler to use than explicitly creating separate
off-screen structures and reusing them for the duration of the drag, though it may be
slower.
One feature of the code is that it doesn’t rotate the shape if you drag it at a point
close to its center, or if you hold the command-key down. I figure this sort of feature
could be useful in a “real” program, where the user might not always want the object
to rotate.
One pitfall you always have to keep in mind when doing calculations on a
computer is rounding error. In this case, repeated calls to RotateMapping can
accumulate distortions in the shape geometry, since the mapping elements cannot be
computed exactly. To get around this, you should keep separate track of the shape
position and rotation angle, and recompute the shape mapping from these values each
time, instead of applying an incremental rotation to the previous mapping. This will
keep the distortion within fixed bounds, instead of letting it accumulate. My code
doesn’t do this, though I must admit I have yet to notice any distortions in shapes after
repeated drags.
Finally, I should own up to one important liberty I have taken with the
mathematical analysis. Remember how I kept saying that the displacement and rotation
angle were assumed to be small? In fact, the code will happily compute arbitrarily
large values for the FG displacement, depending on how quickly you can move the
mouse, and how long it takes your machine to redraw the shape in between checking the
mouse position. This means that, for large mouse movements, the code is no longer
strictly MC (Mathematically Correct). It’s also why I put in the DLimit call.
But then, I figure this is part of the fun of programming. For instance, I have
found that I can drag a shape to a corner of the window, and leave the mouse absolutely
stationary outside the window, while the shape continues to spin round and round in the
corner. Is this a consequence of the code hitting a non-MC situation? I don’t know -
you tell me!