Xref: utzoo rec.games.programmer:3369 comp.os.msdos.programmer:4546 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!daver!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: rec.games.programmer,comp.os.msdos.programmer Subject: Re: 3D Rotation Message-ID: <1991Apr10.060418.29400@zorch.SF-Bay.ORG> Date: 10 Apr 91 06:04:18 GMT References: <1991Apr05.224711.12750@lynx.CS.ORST.EDU> <1991Apr8.224148.18412@unislc.uucp> Organization: SF-Bay Public-Access Unix Lines: 82 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.