Spin
Spin (ST Actorname) [to] (Ve #4 rotation);
The Syntax of Spin is:
Spin "myActor" to quat(<angle>, [<n1>, <n2>, <n3>]);
This rotates the vertices of V about the origin by the unit quaternion argument. The nonzero quaternion is normalized if it does not have length 1.
An important form of animation manipulates the actors in a scene while leaving the scene (and camera) coordinates fixed. This is why the named actors have names, so that scripts can manipulate them. The Spin Command is used to rotate an individual actor about the origin. The simplest and most straightforward use is to apply the command to an actor to rotate it discretely to a new orientation. Variations on this command: ShiftSpin and SpinShift either translate, then rotate an actor, or else rotate, then translate an actor.
Another sort of variation on Spin is used to move one or several actors through "continuous" sequences of rotations and translations simultaneously. These are the commands: DoShiftSpin and DoSpinShift that move sets of actors through complex simultaneous motions, such as orbiting planets, or spinning tops.
Here, we discuss the simplest of these, the Spin Command. In order to understand the actor animation commands it is necessary to fix ideas on just what an actor is (and what it is not). We first observe that each actor is, ultimately, only a collection of vertices V in global coordinates (the "fixed stars"), together with the "geometry" that binds the vertices together (the lines, triangles, quadrilaterals, etc. ) This is true of all actors in Mathwright32, whether defined by equations, imported, or defined by OpenGL script.
Now, after the actor vertices are defined, the actor is positioned in a scene by actively transforming these vertices to scene coordinates (usually using Translate() and Rotate() in the Actor Script). The fact that these transformations commute with the navigation transformations (Move and Turn) means that these initial positions are independent of viewpoint. That is natural.
Note: In all of this discussion, we assume that Scale() transformations are not used in actor scripts. They are not orthogonal, hence do not belong in general, to the Euclidean group. All of the actors you may create or import into Mathwright32 may be scaled initially as you like to fit the scene without using the Scale() transformation in any case.
The transformations in the Actor Script define the initial position and orientation of the actor, the way it appears when selected into the scene, in terms of the global coordinate system. Together, they may be viewed as a rigid (Euclidean) transformation, I, from R3 to R3. We have already observed that each rigid transformation from R3 to R3 has unique representation as the composition of a rotation about the origin followed by a translation. This is a SpinShift. It also has a (usually different) unique representation as the composition of a translation first, followed by a rotation about the origin. This is a ShiftSpin
. We find it convenient sometimes to use one such representation, sometimes the other, because while, in principle, we can always translate from one to the other, the algebra is sometimes messy.
Each actor therefore has, attached to it two things: A set of vertices, V, referred to the global coordinate system, and a rigid transformation of the global coordinate system to itself that actively carries those vertices to the initial position, defined by its script. Call this initial transformation of R3: I. It is a permanent property of the actor (like the vertices V) as long as the actor script is not changed. "I" will also be called the "Initial Stage Transformation."
Before this initial stage transformation is applied, the actor is simply defined by its vertex coordinates, V. While you will only see an actor in this state before you script it, it will be important to be aware of what that state, V, is when you script motion for an actor. The important thing to understand is that, in order to move any given actor, we must define a Euclidean transformation of all of R3 -- a combination of a spin and a shift. That transformation will not affect other actors, but it will carry the vertices V of the current actor to new vertices, and we will see the effect of that transformation. The Initial Stage transformation, I, defined by each actor's script does just that, for each actor, individually.
This is all well and good. When navigation commands are issued, they affect all actors in the same way, maintaining all relative spatial relations. Now the question is: How do we change the position of a single actor, leaving the others alone? To do this, we define a new Euclidean stage transformation for the actor, one that replaces the Initial Stage transformation, and transforms V to its new destination.
Each of the commands: SpinShift, ShiftSpin, Spin, and Shift defines for the actor a new Stage Transformation. These do not accumulate. Each new one simply replaces the previous one. The actor is simply wherever the last command put it. Thus at any time, the actor's vertices are the image of V under the last SpinShift, ShiftSpin, Spin, or Shift that was called on the actor. In this way, your program "knows" at any time what the position and orientation of each actor is.
This is why it is important to remember what the vertex set V looks like for each actor. Every motion will transform that vertex set to the desired position and orientation.
Therefore, each actor carries with it, first, the initial coordinates, V, defined by its vertices. Its script defines the initial transformation, I, into the global scene. This defines the initial position and orientation of the actor.
Again, the syntax of Spin is:
Spin "myActor" to quat(Angle, [n1,n2,n3]);
Note: A quaternion product u*v applied to an actor means v first, then u, just as in function composition. This is the opposite of how quaternions are composed in the navigation command: Turn.
Now if the original vertex set V for "myActor" places the "center of mass" of "myActor" at the origin, the spin will appear to be a natural motion, about the center of mass. But if the center of mass of "myActor" as defined by V is not at the origin, then "myActor" will appear to orbit the origin. So it is important to be familiar with the appearance of "myActor" as defined by V.
Fortunately, we may determine the disposition of "myActor" under V when we create V. This is true even for actors imported from .x files. For the surface and geometric actors, it is obviously so. But there will be other motions for which it will not be appropriate to place the center of mass at the origin. For example, a swinging pendulum should probably place the origin at the pivot, or point of support. In these cases, some calculation may be required to give the right motion. And usually, we'll want to use ShiftSpin, or SpinShift rather than Spin to obtain the right effect. See the discussion of those commands for details.
See Also