Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!umich!zip!spencer From: spencer@eecs.umich.edu (Spencer W. Thomas) Newsgroups: comp.graphics Subject: Re: 3D Animation Source Code Wanted Message-ID: Date: 4 Jan 90 15:30:20 GMT References: <9170@cbmvax.commodore.com> <21550@mimsy.umd.edu> <21561@mimsy.umd.edu> <21562@mimsy.umd.edu> <9182@cbmvax.commodore.com> <1990Jan2.224220.4136@ux1.cso.uiuc.edu> <1920@tellab5.TELLABS.COM> Sender: news@zip.eecs.umich.edu Organization: University of Michigan EECS Dept Lines: 52 In-reply-to: fayne@tellab5.TELLABS.COM's message of 3 Jan 90 13:39:20 GMT In article <1920@tellab5.TELLABS.COM> fayne@tellab5.TELLABS.COM (Jeffrey Fayne) writes: The biggest problem I'm having is that all the rotation texts I've seen assume that the rotations are based on the viewers viewpoint and not the objects (ie. I can rotate an object (say an airplane with the nose pointing away from the viewer) and apply rotations (yaw, roll and pitch) that look correct only from this perspective. As soon as the object is rotated (say 90 degrees with the nose pointing to the positive X axis) the rotations are incorrect for the object but still correct from the viewer's perspective(plane: pitch rotations look like rolls, roll rotations look like pitch, while from the viewer's perspective the object is still rotated the same). This really should be covered in the "standard" references, but may not be obvious from their presentations. The "usual" way that many people set up rotations is to have a fixed sequence of three rotations: one about each coordinate axis. Notationally: [object] [Rx] [Ry] [Rz] => [rotated object] The problem, as you point out, is that as soon as Rx is a non-zero rotation, that the Y and Z axes for the following rotations are no longer aligned with the Y and Z axes of the object. This is a problem inherent in this representation. In order to always rotate about object axes, you must maintain a combined transformation matrix (CTM) corresponding to the sequence of rotations up to "now", and pre-concatenate a matrix representing the current rotation. For example, if you rotated 20deg about X, then 30deg about Y, then -10deg about Z, then another 20deg about X, the CTM would be [CTM] = [Rx(20)] [Rz(-10)] [Ry(30)] [Rx(20)] Note: since rotations do not commute, this is NOT the same as [Rx(40)] [Ry(30)] [Rz(-10)] To apply a further rotation about Z by 10 deg, the new CTM is computed as [CTM'] = [Rz(10)] [CTM] (To rotate about the screen axes, you postconcatenate the rotation matrix to the CTM.) The problem with this technique is that the CTM will gradually become non-orthornormal due to round-off error. That is, it will begin to contain some skew/scaling components as well as rotations. This distorts the resulting image (e.g., a square would start to look like a parallelogram). There are renormalization procedures that you can apply (e.g., Gram-Schmidt), or you can use a different representation for your rotation, and convert that representation to a matrix when needed. The best alternative representation is probably the quaternion formulation. For details, see the paper by Shoemake in SIGGRAPH 85: "Animating Rotation with Quaternion Curves", Ken Shoemake, Computer Graphics, Vol 19, No 3, July, 1985, pp 245-254. In particular, the appendix describes the conversion from a quaternion to a rotation matrix. -- =Spencer (spencer@eecs.umich.edu)