🚀 go-pugleaf

If you want to see 3D display math in all its most gruesome generality,
find

	Puk, Richard F., "General Clipping on an Oblique Viewing Frustrum",
	SIGGRAPH '77 Proceedings, Computer Graphics Volume 11, Number 2,
	Summer 1977, pages 229 - 235.

I implemented this into firmware in a graphics display workstation for
an employer in 1981, along with the general 4x4 homogeneous
transformation code ably covered in, e.g., the recently referenced Foley
& van Dam 2nd Edition.

The published math, I remember, had one rather obvious bug when
converted to software; it assumes infinite precision arithmetic, and
stops a loop based on equality between two real values computed from
different inputs. This is nonsense with limited precision arithmetic,
and I stopped the same loop with an ugly but fast set of flags to assure
I only clipped a line once at each clipping plane.

There have been several quite good responses to the original posted
request for help, but I feel that a couple of things haven't been
emphasized enough, so let me restate one point, and add a bit of
information of my own from my experience doing the above coding.

1) The complaint was that the rotations seemed absolute to the screen,
rather than relative to the object. That's correct; the homogeneous
rotation transform rotates about _the origin of the coordinate system_,
not about your modeled object's "design "axes. As posted, you need
logically to a) move the object to be centered with _its_ "design
origin" at the coordinate systems' origin, b) do the desired rotation,
and c) move the object's design origin back to its previous location in
the scene. I said logically, because it is normally _much_ faster to
take the three 4x4 matrices needed to accomplish these three operations,
multiply them together as several posters have mentioned, and use the
single product matrix to multiply times each point in the object's point
list to do the transformation "all at once".

2) Another possible source of "this doesn't look right" when doing a
screen rotation is to neglect the screen pixel shapes, or "aspect
ratio"; if the pixels are 4/3rds as tall as they are wide, an object
when rotated will appear to change shape with various orientations if
the drawing code treats the pixels as grid coordinates on a grid equal
in x and y dimensions.

3) Doing the "move, rotate, move back" transformations of 1) repeatedly
and storing only the new coordinates will eventually, if you are doing
real time rotation or at least lots of rotations of the same object,
"destroy" the object by the effects of accumulated round off errors
moving the points with respect to one another.  You want instead to keep
an original copy of the object description, and accumulate the rotations
about each "object design" axis, scaling along each "object design" axis,
and translation along each scene coordinate axis, and use these to build
the transformation matrices fresh before each use.  This way small errors
in the accumulated values may still occur, but the created transformation
matrix will transform the original data without inappropriate moves of
the object's points with respect to one another.

4) The _easy_ way to do smooth rotations through a series of positions
is to create transformation matrix for the original and final position,
do a linear interpolation between individual matrix elements for each
rotation step to be displayed, and use the interpolated matrix to do the
intermediate transformation. Do _not_ take the delta matrix for one
frame and repeatedly apply it; the same accumulated roundoff will get
you.  When using this technique, do a maximum rotation in one set of
interpolations of 90 degrees about any axis; this assures that you don't
accidently rotate the object backwards to your intended direction.

I really don't know if the interpolation is mathematically sound, but it
looks right, which is what counted for me. I suspect, since a sine curve
is being interpolated by a straight line, that the rotation speed is not
really constant, but the eye doesn't pick up on this kind of a problem,
and the start and end positions are correct. The less the maximum
rotation you allow for endpoint matrices between which you interpolate,
the better the straight line interpolates the sine curve, of course, and
the less the problem would show, but the extra math can hurt.

Of course, if you're doing sines and cosines by table lookup, either
interpolating or doing each frame's transformation matrix separately
works out about the same.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>