Next: ntransform, Previous: image, Up: Non-geometric objects
Where a single 4x4 matrix is expected – as in the INST
transform field, the camera's camtoworld transform and the
Geomview xform* commands – use a transform object.
Note that a transform is distinct from a TLIST, which is a type
of geometry. TLISTs can contain one or more 4x4 transformations;
"transform" objects must have exactly one.
Why have both? In many places – e.g. camera positioning – it's only meaningful to have a single transform. Using a separate object type enforces this.
Syntax for a transform object is
<transform> ::=
[ "{" ] (curly brace, generally needed to make
the end of the object unambiguous.)
[ "transform" ] (optional keyword; unnecessary if the type
is determined by the context, which it
usually is.)
[ "define" <name> ]
(defines a transform named <name>, setting
its value from the stuff which follows)
<sixteen floating-point numbers>
(interpreted as a 4x4 homogeneous transform
given row by row, intended to apply to a
row vector multiplied on its LEFT, so that e.g.
Euclidean translations appear in the bottom row)
|
"<" <filename> (meaning: read transform from that file)
|
":" <name> (meaning: use variable <name>,
defined elsewhere; if undefined the initial
value is the identity transform)
[ "}" ] (matching curly brace)
The whole should be enclosed in { braces }. Braces are not essential if exactly one of the above items is present, so e.g. a 4x4 array of floats standing alone may but needn't have braces.
Some examples, in contexts where they might be used:
# Example 1: A GCL command to define a transform
# called "fred"
(read transform { transform define fred
1 0 0 0
0 1 0 0
0 0 1 0
-3 0 1 1
}
)
# Example 2: A camera object using transform
# "fred" for camera positioning
# Given the definition above, this puts the camera at
# (-3, 0, 1), looking toward -Z.
{ camera
halfyfield 1
aspect 1.33
camtoworld { : fred }
}
Next: transform-incr, Previous: time-interests, Up: GCL Reference
(transform objectID centerID frameID [rotate|translate|translate-scaled|scale] x y z [bbox-center|origin] [dt [smooth]])objectID;
that is, construct and concatenate a transformation matrix with
objectID's transform The 3 IDs involved are the object
that moves, the center of motion, and the frame of reference
in which to apply the motion. The center is easiest understood
for rotations: if centerID is the same as objectID then it will
spin around its own axes; otherwise the moving object will orbit
the center object. Normally frameID, in whose coordinate system
the (mouse) motions are interpreted, is focus, the current camera.
Translations can be scaled proportional to the
distance between the target and the center. Support for
spherical and hyperbolic as well as Euclidean space is
built-in: use the space command to change spaces. With type
rotate x, y, and z are floats specifying angles in RADIANS.
For types translate and translate-scaled x, y, and z are
floats specifying distances in the coordinate system of the
center object.
The next field is optional and may consist of the keyword
bbox-center or the keyword origin and modifies the
location of the origin of objectID's co-ordinate frame:
bbox-center temporarily translates objectID's co-ordinate
frame to the center of objectID's bounding box. origin is
the default (and means not to modify objectID's co-ordinate frame)
and bbox-center is only valid in Euclidean space.
The optional dt field allows a simple form of
animation; if present, the object moves by just that amount during
approximately dt seconds, then stops. If present and followed by
the smooth keyword, the motion is animated with a 3t^2-2t^3
function, so as to start and stop smoothly. If absent, the motion is
applied immediately.