Dragging and Rigid-Body
Transformations

QD GX can make your Mac a swinging place

By Lawrence D’Oliveiro

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.

Consider a body with its center of mass at a point C. Say you apply a small force on it at a point F, sufficient to displace that point to a new position G close to F. The center of mass is in turn moved to a new position D (Figure 2).

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).

Now draw a line P1P2 parallel to CF, and project the points C, D, F and G onto 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;

LastMouse is the point F, while ThisMouse is the point G. ThisDelta is the 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)

Note that the center of rotation used in the RotateMapping call is the point G rather than C. This is all right, because the direction of rotation calculated by the code 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!