Alias File Formats 1

Overview 2
Alias Pix 5
Matte 7
Alias Camera Depth 9
Polygons: Object-separated Triangle Output 11
Polygons: Object-separated Quadrilateral Output 14
Animation SDL 18
Maya IFF 24
Particle file 28
Bulge definition 30
Index 35

FileFormats - StudioTools19.5
FileFormats
2 - StudioTools 9.5
Alias File Formats
This document describes 2D image file formats
used by Studio.
For information on the 3D image file formats, see
Basic Tools -General.
(Note that the following 3D file formats are not
available on all platforms, including Studio 9.5 for
the Solaris Operating Environment: DBView,
Inventor, StyleGuide, OBJ.)

File Formats
1
 Overview
The file formats are available in the following
operating environments.

File Format Systems

Alias Pix IRIX, Solaris, Windows NT

Matte IRIX,, Solaris, Windows NT
Alias Camera Depth IRIX, Solaris, Windows NT
Polygons: Object-separated IRIX, Solaris, Windows NT
Quadrilateral Output
Polygons: Object-separated Triangle IRIX, Solaris, Windows NT
Output
Animation SDL IRIX, Solaris, Windows NT
Maya IFF Windows NT (reading only)
Particle file IRIX, Solaris, Windows NT
Bulge definition IRIX, Solaris, Windows NT

Note: This information applies to the following

versions of Studio and operating systems:
•IRIX: Studio 9.5 for IRIX 6.5
•Solaris: Studio 9.5 for Solaris 2.5.1 or 2.6
•Windows NT: Studio 9.5 for Windows NT 4.0
with Service Pack 5.

Directories and files

Here are some other pieces of information that may
be useful.
Note: The directory separator is a slash for UNIX
or a backslash for Windows.
• The Studio interactive package puts Alias
image files into a pix subdirectory and Alias
matte files in a separate mask subdirectory
since the pix and matte files are named the
same for each frame of the animation. These
names, by default, match the name of the SDL
file (Scene Description Language) which is
in its own sdl subdirectory. The file extension

File Formats
2
Overview
 is, in most cases, a simple integer representing
the frame number.
• These subdirectories are typically found in the
user_data/demo or user_data/<project>
directories used by the interactive package.
• So for a user in the default demo project who
has output all the information to render an
animation to the file sdl/final, the renderer will
output pix files pix/final.1, pix/final.2,... and, if
requested, will also output matte files mask/
final.1, mask/final.2,...
• When rendering on fields, a trailing “o” or
“e” is appended to the end of the frame
number (for odd and even).
• Studio uses the “o'' extension to indicate that
this image has been rendered for the odd
field, and we assume that it is the odd field
that is displayed first, followed by the even
field. This assumption can be changed,
however, using Render → Globals and setting
the Image File Output to ODD FIRST or EVEN
FIRST.

• So the renderer will output pix files pix/

final.1o, pix/final.1e, pix/final.2o, pix/final.2e...
and, if requested, will also output matte files
mask/final.1o, mask/final.1e, mask/final.2o, mask/
final.2e....
• When rendering stereo pairs, the base name of
the file is suffixed with “_right” or “_left”
before any frame or field extension is added.
For example, a stereo rendering on fields
produces these files, in this order:
pix/final_left.1o
pix/final_right.1o
pix/final_left.1e
pix/final_right.1e
pix/final_left.2o
pix/final_right.2o
pix/final_left.2e

File Formats
3
Overview
 pix/final_right.2e

File Formats
4
Overview
Alias Pix
Systems
IRIX, Solaris, Windows NT
Description
An Alias pix file has a 10-byte header containing 5
short integers (there is no explicit magic number)
which is then followed immediately by image data
in a simple run-length encoded scheme.
Only RGB information is contained in the file.
Matte files are similar but exist in a separate file
(see Matte File Format for details).
bytes header value notes
0, 1 width x resolution in pixels
2, 3 height y resolution in pixels
4, 5 xoffset unused
6, 7 yoffset unused
8, 9 bits/pixel 24 for pix files (0x18)

The pixels are then run-length encoded in 4-byte

packets on a per-scanline basis (runs do not extend
beyond a single scanline) starting with the top
scanline in the image.
bytes data range notes
runlength 1 - 255 number of pixels in
succession with given RGB
blue 0 - 255 value of blue component
green 0 - 255 value of green component
red 0 - 255 value of red component

Example
Here is the output of od -x for a pix file that is 8
pixels wide and 6 pixels high, representing a ramp
that goes from black at the bottom of the image to
blue at the top:
0000000 0008 0006 0000 0005 0018 08ff 0000 08cc
0000020 0000 0899 0000 0866 0000 0833 0000 0800
0000040 0000
0000042

File Formats
5
Alias Pix
 This is read as describing an image that is 8 pixels
wide [0008] and 6 scanlines high [0006]. The next
four bytes describe the obsolete offset information.
This is a pix file since there are 24 bits/pixel [0018].
The first (top) scanline is composed of a run of 8
pixels of (B=255, G=0, R=0)[08ff 0000]. The next
scanline (since this one is complete) is 8 pixels of
(B=204, G=0, R=0) [08cc 0000]. The rest of the
scanlines are coded in the same fashion with the
last scanline of eight pixels of (B=0, G=0, R=0) [0800
0000].

File Formats
6
Alias Pix
Matte
Systems
IRIX, Solaris, Windows NT
Description
Alias matte files are a variant of Alias pix files.
bytes header value notes
0, 1 width x resolution in pixels
2, 3 height y resolution in pixels
4, 5 xoffset unused
6, 7 yoffset unused
8, 9 bits/pixel 8 for matte files (0x8)

The coverage (matte) information is then run-

length encoded in 2-byte packets on a per-scanline
basis (i.e. runs do not extend beyond a single
scanline) starting with the top scanline in the
image, where a value of zero indicates no coverage
and a value of 255 indicates complete coverage of
that pixel:
bytes data range notes
runlength 1 - 255 number of pixels in
succession with given
coverage
coverage 0 - 255 value for coverage

Example
The following is an octal dump of an 8x6 Alias
matte file for a sphere that nearly fills the image:
0000000 0008 0006 0000 0005 0008 0100 0110 015f
0000020 02bf 015f 0110 0100 0100 015f 04ff 015f
0000040 0100 0100 01bf 04ff 01bf 0100 0100 01bf
0000060 04ff 01bf 0100 0100 015f 04ff 015f 0100
0000100 0100 010f 015f 02bf 015f 010f 0100
0000116
This is read as describing an image that is 8 pixels
wide [0008] and 6 scanlines high [0006]. The
next four bytes describe the obsolete offset
information.This is a matte file since there are 8
bits/pixel [0008].The description below shows

File Formats
7
Matte
 the remainder of the file which describes the matte
from the top scanline to the bottom.
0100 - one pixel of 0/255 (0%) coverage,
0110 - one pixel of 16/255 (6%) coverage,
015f - one pixel of 95/255 (37%) coverage,
02bf - two pixels of 191/255 (75%) coverage,
015f - one pixel of 95/255 (37%) coverage,
0110 - one pixel of 16/255 (6%) coverage,
0100 - one pixel of 0/255 (0%) coverage.

Now you know you are on the next scanline since

the first is filled.
0100 - one pixel of 0/255 (0%) coverage,
015f - one pixel of 95/255 (37%) coverage,
04ff - four pixels of 255/255 (100%) coverage,
015f - one pixel of 95/255 (37%) coverage,
0100 - one pixel of 0/255 (0%) coverage.

Moving on to the next scanline:

0100 - one pixel of 0/255 (0%) coverage,
01bf - one pixel of 191/255 (75%) coverage,
04ff - four pixels of 255/255 (100%) coverage,
015f - one pixel of 191/255 (75%) coverage,
0100 - one pixel of 0/255 (0%) coverage.

And so on. The next scanline is exactly the same,

the one after that matches the second and the last
one is the same as the first. This is the fortunate
result of choosing a sphere.

File Formats
8
Matte
Alias Camera Depth
Systems
IRIX, Solaris, Windows NT
Description
An Studio Camera Depth file contains depth
information corresponding to the image created
from that camera. The Camera Depth file is used
for post-render 3D compositing. The file contains a
magic number, an X and Y resolution, and an array
of floating point depth values.
bytes header notes C-type
value
0, 1, 2, magic Uniquely identifies int
3 number files of this type
4, 5 width x resolution in pixels short
6, 7 height y resolution in pixels short

The magic number for Studio camera depth files is

55655. The rest of the file contains an X by Y array
of floating point values in row order.
Example
The following C-code is an example of how to read
a Camera Depth File:
filein = open( infilename, O_RDONLY );

read( filein, &magic, sizeof( int ) ); /*

magic number */
if ( magic != 55655 ) {
fprintf( stderr,”given input file '%s'
does not have proper magic number (55655)\n”,
infilename );
exit(0);
}

read ( filein, &width, sizeof(short) ); /*

Xres */
read ( filein, &height, sizeof(short) ); /*
Yres */

size = width * height;

buffer = (float *)malloc ( size * sizeof(

float ) );
read( filein, buffer, sizeof(float)*size2 ); /

File Formats
9
Alias Camera Depth
 * fill the array */

close( filein );

for (i = 0; i < height; ++i) {

for (j = 0; j < width; ++j) {
/* Do something to the pixel.
*/
}
}

File Formats
10
Alias Camera Depth
Polygons: Object-separated
Triangle Output
Systems
IRIX, Solaris, Windows NT
Description
This format is used when polygons are exported
from Studio using File > Export > Polygons.
The following definitions are used to delineate
objects.
#define FLOAT_START 99999.0
#define FLOAT_END -FLOAT_START

Each triangle file is composed of lists of numbers

output in machine format. A triangle is made up of
three normals, vertices, colors, and parametric
coordinates. Objects are delineated by two arbitrary
floating point values, which are too large to be
valid surface normal values.
The starting floating point value marking an object
is followed by a null terminated string (the object’s
name), a single integer representing the number of
triangles in this object, and finally, the name of the
texture applied to this object (if any).
Object-separated Triangle Format
The object-separated triangle format is illustrated
by the following example:
FLOAT_START /* Marks start of an object (float)
*/
name /* A NULL-terminated string (chars)
*/
count /* No.of triangles to follow (int) */
texture_name /* A NULL-terminated string (chars) */
nx ny nz /* Normal, vertex 1 (floats)*/
fx fy fz /* Vertex 1, triangle 1 (floats)*/
cr cg cb /* Color of vertex 1.0-255 (floats) */
u v /* U,V of vertex 1 (floats) */
nx ny nz /* Normal,vertex 2 */
fx fy fz /* Vertex 2, triangle 1 */
cr cg cb /* The color of vertex 2. 0-255 */
u v /* U,V of vertex 2 */
nx ny nz /* Normal, vertex 3 */
fx fy fz /* Vertex 3, triangle 1 */
cr cg cb /* The color of vertex 3. 0-255 */

File Formats
11
Polygons: Object-separated Triangle Output
 u v /* U,V of vertex 3 */
etc... (defines another triangle)
FLOAT_END /* Marks the end of an object */
name /* - name of object just terminated */
FLOAT_START
etc....
Zero Count Objects
If the number of triangles for an object is zero (0),
then the object is a collection of other objects that
may or may not contain triangles or other sub-
groups of objects. In other words, zero count
objects describe the hierarchy or DAG of the model.
Example
For example, a model of an arm might look
something like the following (if translated into
plain text and formatted):
FLOAT_START
arm
0
FLOAT_START
hand
0
FLOAT_START
thumb
567
(567 triangles here)
FLOAT_END
thumb

FLOAT_START
finger
2143
(2143 triangles here)
FLOAT_END
finger

(3 other fingers here)

FLOAT_END
hand
FLOAT_START
forearm

345

(345 triangles here)

File Formats
12
Polygons: Object-separated Triangle Output
 FLOAT_END
forearm
(some other arm-related objects here)
FLOAT_END
arm

For an example of how to read a triangle file, see

the sample file "/usr/aw/alias/Gifts/src/
reader/reader.c".

File Formats
13
Polygons: Object-separated Triangle Output
 Polygons: Object-separated
Quadrilateral Output
Description
This format is used when quadrilateral polygons
are exported from Studio using File > Export >
Polygons.
The quadrilateral output file format allows
tessellated output in a form other than triangles,
and outputs texture information if it exists. (For
information on Windows > Information > Render stats,
see Rendering in Alias.)
Each quadrilateral corresponds to the subdivided
approximations to the surface created during the
Alias triangle tessellation phase of rendering. The
higher the surface subdivisions set in the Render
Stats spreadsheet editor, the more quadrilaterals
are produced for that surface.
If the object is textured on the color channel, each
quadrilateral can have a texture swatch on it. The
swatch is created by a uniform parametric
sampling of the texture across the quadrilateral. In
addition to the texture swatch, the name of the
texture assigned is included at the head of each
object, and the hierarchy of the model is
maintained.
In UNIX systems, you can access this feature by
setting a shell ENVIRONMENT variable from a UNIX
shell window, and then running Alias from that
window. The command to set this variable is as
follows:
setenv QUAD_OUTPUT 16

If the QUAD_OUTPUT environment variable is set to

any positive integer, excluding zero (0), then
quadrilaterals are output into the file instead of
triangles when you select the Object Separators
option of the triangle output menu.
QUAD_OUTPUT controls the resolution of the texture
swatch created in the file. For example, using 16 the
texture swatches produced in the quad file are 16
by 16 pixels.

File Formats
14
Polygons: Object-separated Quadrilateral Output
 The following definitions are used to delineate
objects.
#define FLOAT_START 99999.0
#define FLOAT_END -FLOAT_START

A quadrilateral is made up of four normals,

vertices, and parametric coordinates. Objects are
delineated by two arbitrarily large floating point
values that are too large to be valid surface normal
values. You cannot read quadrilateral files, because
they are composed of lists of numbers in binary
format.
The starting floating point value marking an object
is followed by a null-terminated string (the object’s
name), a single integer representing a count of the
number of quadrilaterals in this object, and then if
the number of quadrilaterals is non-zero, the name
of the texture applied to the object (if any). If there
is no texture applied to the object, a single, null
character is printed.
Note: In some cases, Alias is forced to write
triangles instead of quadrilaterals— near
the edge of trim curves, some faces,
triangle polysets, and so on. In such a case,
a quadrilateral is printed for every field in
the last vertex that is set to 111.3, and the
texture array is always 1 by 1. (The number
111.3 was chosen because it is a floating
point (real) number that gets written
exactly with fprintf. Not all floating
point numbers have this property).
Example
The following example illustrates the quadrilateral
format.
FLOAT_START /* Marks start of an object (float) */
name /* A NULL terminated string (chars) */
count /* Number of quads to follow. (int) */
texture_name /* A NULL terminated string (chars) */
nx ny nz /* Normal, vertex 1 (floats)*/
fx fy fz /* Vertex 1, quad 1 (floats)*/
u v /* U,V of vertex 1 (floats) */
nx ny nz /* Normal, vertex 2 */
fx fy fz /* Vertex 2, quadrilateral 1 */
u v /* U,V of vertex 2 */
nx ny nz /* Normal, vertex 3 */

File Formats
15
Polygons: Object-separated Quadrilateral Output
 fx fy fz /* Vertex 3, quadrilateral 1 */
u v /* U,V of vertex 3 */
nx ny nz /* Normal, vertex 4 */
fx fy fz /* Vertex 4, quadrilateral 1 */
u v /* U,V of vertex 4 */
s t /* Ints. for resolving text. swatch */
texture_swatch /* s times t Rgba structures. */
etc...
FLOAT_END /* Marks the end of an object */
name /* Name of object just terminated */
FLOAT_START
etc....

If the number of quadrilaterals for an object is zero

(0), then the object is a collection of other objects
that might contain quadrilaterals or other sub-
groups of objects. In other words, objects with a
count of zero describe the hierarchy or nodes of the
model.
For example, a model of an arm might look
something like the following (if translated into
plain text and formatted).
FLOAT_START
arm
0
FLOAT_START
hand
0
FLOAT_START
thumb
567
(567 quadrilaterals here)
FLOAT_END
thumb
FLOAT_START
finger
2143
(2143 quadrilaterals here)
FLOAT_END
finger
(3 other fingers here)
FLOAT_END
hand
FLOAT_START
elbow
345
(345 quadrilaterals here)

File Formats
16
Polygons: Object-separated Quadrilateral Output
 FLOAT_END
elbow
(some other arm-related objects here)
FLOAT_END
arm

For an example of how to read a quad file, see /

usr/aw/alias/Gifts/src/reader/qreader.c

Note: In this format, polysets are written.

However, if you have converted your
object to a triangular polyset and then
choose quadrilateral output, only triangles
are printed—they are not welded back into
quads.You can preview the kind of
triangles that will be output by using the
Convert to Polygons feature in Alias.

File Formats
17
Polygons: Object-separated Quadrilateral Output
 Animation SDL
Systems
IRIX, Solaris, Windows NT
Description
An Animation SDL file is like a regular Scene
Description Language file (see File → Save SDL)
with an extra section to describe the model’s
hierarchies. An Animation SDL file has two sections,
DEFINITION and HIERARCHY.

Note: The HIERARCHY section may be omitted. In

this case, the Animation SDL file contains
only a library of animation curves (or
actions).
In the DEFINITION section, you specify the
description of the curves (or actions) as you do in
regular SDL. The syntax for actions is the same for
Animation SDL and regular SDL.
In the HIERARCHY section, you describe how the
animation curves in the DEFINITION section are
applied to the model’s hierarchy.
•The braces, { }, bracket these descriptions. You
must supply at least one set of braces.
•The order of the braces describes the hierarchy.
•A matching pair of braces inside another refers
to an object that is a child of the outer pair’s
object.
•Matching pairs that follow one another
indicate that the pairs are children of the same
parent.
Example 1
See the following example.
HIERARCHY
{ <----- Picked object
Apply animation to picked object.
{ <----- A child of the picked object.
Apply animation to child of picked object.
{ <----- A child of a child of the picked
object.
Apply animation to child of a child of picked
object.

File Formats
18
Animation SDL
}
}
{ <----- Another child of the picked object.
Apply animation to other child picked object.
}
}

If an object has no animation, but a descendant

does, you must still specify the braces as a place-
holder for the object, but omit the statements
applying any animation to it. This is also necessary
for siblings. If the leftmost sibling is unanimated,
but the one to its right is animated, specify an
empty pair of braces as a place-holder for the
leftmost child.
There are two statements in the HIERARCHY section
that apply animation to objects. The first is the type
statement, which indicates the type of object that
will receive the animation.
Specifying the type of object
The general form of the type statement is:
type “animatable item type name” ( <additional
information> );

Examples of the “animatable item type name” are Dag

Node, Camera, Light, Shader, Surface CV, and Curve
CV.
• For a Dag Node, specify a name for the dag
node.
• For Animation SDL, a Shader includes
textures. Lights and shaders have no
additional information, so the parentheses
should be empty.
• For a Surface CV, specify the U and V values
for the CV, separated by a comma. For
example, if the u=2 and v=3 CV on a surface is
animated, the type statement is written as:
type “Surface CV” (2, 3);
• For a Curve CV, specify which CV of the curve
is being referred to.
If the curve is part of a face, two values are
specified separated by a comma. The first value
specifies the curve of the face, and the second value

File Formats
19
Animation SDL
 specifies the CV on the curve. For example, if a face
is made up of 3 curves, then to refer to the 4th CV
on the 2nd curve of the face, the type statement is
written as:
type “Curve CV” (2, 4);
• For a Polyset Vertex, specify the vertex
number in the polyset.
type "Polyset Vertex" (62);
• No other animatable items have additional
information, so their parentheses should be
empty.
Applying the animation
The statements following the type statements
indicate how animation is applied to each of the
item’s animation parameters. These are called
channel statements, and specify how the animation
parameter uses the actions from the DEFINITION
section.
The general form of the channel statement is:
channel “channel name” (action_name [extract
axis] (action_name...));

Each animatable item type has its own set of

animation parameter names, which can be seen in
the param control window (see Animation → Param
control for details). For example, Dag Nodes have X
Translate, Y Translate, Z Scale, and Visibility. These
names, which appear in the param control window,
can be used as channel name.
Note: Do not assign a channel to an item that
does not animate in that parameter. Also,
do not assign a channel that is not part of
the current animation item type. For
example, Animation SDL does not
differentiate between types of lights, so it is
possible to try to read a Spot spread channel
onto a point light, but that results in an
error.
Within the parentheses of the channel statement,
you specify the list of actions that make up the
channel. If the action is a motion path, you must
specify which axis of the 3D NURBS curve to use.

File Formats
20
Animation SDL
 Additional actions that are within additional
parentheses act as timewarps on the original curve
(see Anim → Time Warps → New time warp).
Example 2
The following is a commented example Animation
SDL file of an animated cylinder.
DEFINITION
/* the 3-D NURBS curve used by the motion path
action */
curve curve#2 (
degree = 3,
knots = (0.0, 0.0, 0.0, 1.0, 1.0 , 1.0 ),
cvs = (
cv( (0.0, 0.0, 0.0),1.0),
cv( (3.0, 3.0, 3.0),1.0),
cv( (-4.0, 2.0, -6.0),1.0),
cv( (-3.0, 2.0, 3.0),1.0) )
);
/* a motion path action */
motion_curve motion_path ( curve#2, in =
PRE_CONSTANT, out = POST_CONSTANT );

/* several parameter curve actions */

parameter_curve param_curve.Timing ( in =
PRE_LINEAR, out = POST_LINEAR, cvs = (
parameter_vertex(1.0,0.0 , TAN_SMOOTH, ( -
0.27852, -0.96043 ), TAN_SMOOTH, (0.27852,0.96043)
),
parameter_vertex(30.0,30.0, TAN_SMOOTH, (-
0.27852,-0.96043 ), TAN_SMOOTH, (0.27852,0.96043) )
) );

parameter_curve param_curve.X_Scale ( in =
PRE_CONSTANT, out = POST_CONSTANT, cvs = (
parameter_vertex(1.0 , 1.0 , TAN_SMOOTH, (1.0
,0.0), TAN_SMOOTH, (1.0 , 0.0) ),
parameter_vertex( 30.0 , 4.0 , TAN_SMOOTH,
(1.0 ,0.0), TAN_SMOOTH, (1.0 , 0.0) )
) );

parameter_curve param_curve.Z_Rotate ( in =
PRE_CONSTANT, out = POST_CONSTANT, cvs = (
parameter_vertex(1.0 , 0.0, TAN_SMOOTH, (-1.0 ,
0.0), TAN_SMOOTH, (1.0 , 0.0) ),
parameter_vertex(30.0 ,360.0 , TAN_SMOOTH, (-
1.0 , 0.0 ), TAN_SMOOTH, (1.0, 0.0) )
) );

File Formats
21
Animation SDL
 parameter_curve timewarp ( in = PRE_IDENTITY, out
= POST_IDENTITY, cvs = (
parameter_vertex(1.0 , 1.0, TAN_SMOOTH, (-
0.70711,-0.70711 ), TAN_SMOOTH, (0.70711,0.70711)
),
parameter_vertex(30.0 ,30.0 ,TAN_SMOOTH, (-
0.70711,-0.70711 ),TAN_SMOOTH, (0.70711,0.70711) )
) );

parameter_curve param_curve.X_Position ( in =
PRE_CONSTANT, out = POST_CONSTANT, cvs = (
parameter_vertex(1.0 , -0.2612 , TAN_SMOOTH, (-
1.0 ,0.0), TAN_SMOOTH, (-1.0 ,0.0) ),
parameter_vertex( 30.0 , -0.18593, TAN_SMOOTH,
(-1.0 ,0.0), TAN_SMOOTH, (-1.0 ,0.0) )
) );

parameter_curve param_curve.Y_Position ( in =
PRE_CONSTANT, out = POST_CONSTANT, cvs = (
parameter_vertex(1.0 ,0.2612 , TAN_SMOOTH, (-
1.0 ,0.0 ), TAN_SMOOTH, (-1.0 ,0.0) ),
parameter_vertex( 30.0 , 0.58722, TAN_SMOOTH,
( -1.0 , 0.0 ), TAN_SMOOTH, (-1.0 ,0.0))
) );

parameter_curve param_curve.Z_Position ( in =
PRE_CONSTANT, out = POST_CONSTANT, cvs = (
parameter_vertex( 1.0 , 0.5 , TAN_SMOOTH, (
-1.0 , 0.0 ), TAN_SMOOTH, ( 1.0 , 0.0
) ),
parameter_vertex( 30.0, 0.90137, TAN_SMOOTH,
( -1.0 , 0.0 ), TAN_SMOOTH, (-1.0 ,0.0))
) );

HIERARCHY
{
type "Dag Node" ( cylinder );

/* The cylinder is moved along a motion path.

*/
/* Each channel is extracted from a motion path
*/
/* with one timing curve modifying all three.
*/
channel "X Translate" ( motion_path [X] (
param_curve.Timing ));
channel "Y Translate" ( motion_path [Y] (
param_curve.Timing ));
channel "Z Translate" ( motion_path [Z] (
param_curve.Timing ));

File Formats
22
Animation SDL
 /* The width of the cylinder is also animated.
*/
channel "X Scale" ( param_curve.X_Scale );
{
/* This is the first child of the top level */
/* of the cylinder. It spins around the Z */
/* axis. A timewarp has been applied. */
type "Dag Node" ( cyl_body );
channel "Z Rotate" ( param_curve.Z_Rotate (
timewarp ));
}
{
/* Cap A of the cylinder is not animated, */
/* nor are any of its CVs, but these braces */
/* are necessary to maintain to maintain the*/
/* hierarchy structure. */
/* If these braces were omitted Cap B's */
/* animation would be read onto Cap A. */
}
{
/* Cap B is not animated but one of its cvs */
/* is. */
{
type "Surface CV" ( 2, 4 );
/* Surface CV u = 2, v = 4 is animated. */
channel "X Position" ( param_curve.X_Position
);
channel "Y Position" ( param_curve.Y_Position
);
channel "Z Position" ( param_curve.Z_Position
);
}
}

File Formats
23
Animation SDL
 Maya IFF
Systems
Windows NT.
Studio for Windows NT can read Maya IFF files
and save them as TIFF or Alias pix files.
Description
IFF stands for Image File Format.
•The basic element of an IFF file is a block,
sometimes called a chunk.
•Each block has an identifier called a tag or ID
and a block length to allow it to be skipped (in
some cases the block length is missing and the
end of the block is indicated by a special
marker).
•Several grouping block types allow the file to
be structured as a hierarchy.

Basic file structure

The structure is based on the use of tags to identify
blocks of data called chunks or structures of chunks
called groups. Each tag is made up of four
characters and is immediately followed by the size
of the chunk or group that it describes coded on 4
bytes. Tags are handled as pseudo-character strings
and all other data is written in big-endian format.
Block type tags
The main tag types are FORM, CAT, LIST and
PROP.
They come in several flavors, such as FOR4, FOR8,
CAT4 and CAT8 to specify 4-byte or 8-byte
alignment boundaries.
•FORM defines a structure that is similar to a C
struct, that is, an ordered set of structured
data.
•CAT defines a concatenation of independent
objects with no order relation between them.
•LIST is used to group objects with similar
properties, avoiding redundancy as the
common properties can be defined before the

File Formats
24
Maya IFF
 list in a PROP block. A List has an extra tag
value to indicate what it is a list of.
•PROP further defines the properties of objects.
Groups
Four tags are used to arrange blocks into
groups: FORM, CAT, LIST, and PROP. The first
four characters following the size are used to
identify the type of the group.

The FORM defines a structure that is like a C struct.

FORM 38 TEXT
CHAR 6 "Times"
CHAR 12 "Hello World"
EOF

is like
struct Text t = {
char *f = "Times";
char *c = "Hello World";
};

The size of the group (38) equals the size of the data
it contains (6 plus 12) plus the size of the headers (4
for TEXT, 8 for CHAR 6 and 8 for CHAR 12). In this
case, the result is 6+12+4+8+8 = 38.
As in C structures you can nest groups; for
example:
FORM 52 TEXT
FORM 8 FONT
CHAR 6 "Times"
LONG 4 <12>
LONG 4 <0>
CHAR 12 "Hello World"
EOF

or in C terms:
struct Text t = {
struct Font f = {
char *n = "Times";
int s = 12;
int d = 0;
};
char *string = "Hello World";
};

This example may not show that blocks are not

File Formats
25
Maya IFF
 constrained to use a unique data type and may
contain the equivalent of a complete C structure.
The FORM tag separates independent blocks of
data that can be handled separately and specifies
the meaning of each subunit.
In the example above, the CHAR chunk in the
FONT FORM does not mean the same thing as the
CHAR chunk in the TEXT FORM. The FORM tag
determines how you interpret an ordered set of
data types.
The CAT tag defines a concatenation of
independent objects with no order relation between
them. Two typical uses of CATs are for libraries of
objects (pictures in Example 1) or clipboards
(Example 2).
Example 1:
CAT 3632 PICT
FORM 1234 PICT ...
FORM 2378 PICT ...
EOF

Example 2:
CAT 2130 CLIP
FORM 1234 PICT ...
FORM 876 DRAW ...
EOF

Searching through a structured file is generally

greatly accelerated, even in a CAT that has no order
amongst its members, through the knowledge of
the size of every group or chunk specified in the
header.
The LIST tag is used to group objects with similar
properties, avoiding redundancy. For example, a
sequence of equal-sized images might be
represented in the following way. One image
would have a structure like:
FORM .... PICT
IHDR 32 (image size info)
BODY ... (image data)
EOF

then a sequence of like sized images could be done

as follows, sharing the common header

File Formats
26
Maya IFF
 information:
LIST ... ANIM
PROP 44 PICT
IHDR 32 (common size info)
FORM ... PICT
BODY .... (data)
FORM ... PICT
BODY .... (data)
FORM ... PICT
BODY .... (data)
EOF

The information in a PROP construct is valid until

the end of the LIST. It can be redefined locally in a
FORM stastement. (In the above example the
common IHDR is valid in all PICTs that don’t
include an IHDR block of their own.)
Alignment
IFF blocks align to 2-byte boundaries. The size
specified in the header does not take padding into
account. Many computers typically align their
memory on 4-byte or 8-byte boundaries. Flib uses
eight extra TAGs to let you specify alignment
information:
•Thes four are used to align to 4-byte
boundaries: FOR4, CAT4, LIS4 and PRO4.
•These four are used to align to 8-byte
boundaries: FOR8, CAT8, LIS8 and PRO8.

File Formats
27
Maya IFF
 Particle file
Systems
IRIX, Solaris, Windows NT
Description
The Particle file format is a simple ASCII dump of
the current status of every particle in the system.
Rendering, mass, generator, and other information
is carried in the wire file or SDL file.
The file is all space separated:

Field Type Comments

<file_type> Integer Two possible values currently: 4 or 5
<num_blobs> Integer The number of particles in this file.

<blob_info> (See the following table. There are

'num_blobs' entries of this type.)

Normal particles
For type 4 particles (normal), information for each
blob is described below.
Field Type Comments
<start_x> Float X position of particle at start of frame.
<start_y> Float Y position of particle at start of frame.
<start_z> Float Z position of particle at start of frame.
<end_x> Float X position of particle at end of frame.
<end_y> Float Y position of particle at end of frame.
<end_z> Float Z position of particle at end of frame.
<R> Float Red color of particle in this frame.
<G> Float Green color of particle in this frame.
<B> Float Blue color of particle in frame.
<cycles_left> Integer Number of cycles left in the particle’s life.
<cycles_total> Integer Total number of cycles in the particle’s
life.

Diffusing gas particles

For type 5 particles (diffusing gas particles),

File Formats
28
Particle file
 information for each blob is described below.
Field Type Comments
<start_x> Float X position of particle at start of frame.
<start_y> Float Y position of particle at start of frame.
<start_z> Float Z position of particle at start of frame.
<end_x> Float X position of particle at end of frame.
<end_y> Float Y position of particle at end of frame.
<end_z> Float Z position of particle at end of frame.
<R> Float Red color of particle in this frame.
<G> Float Green color of particle in this frame.
<B> Float Blue color of particle in this frame.
<cycles_left> Integer Number of cycles left in the particle’s life.
<cycles_total> Integer Total number of cycles in the particle’s life.
<start_size> Float Size of particle at start of frame.
<end_size> Float Size of particle at end of frame.

File Formats
29
Particle file
 Bulge definition
Systems
IRIX, Solaris, Windows NT
Description
The character builder feature (found in the Windows
→ Deformation control, under Frame Type:
CHARACTER BUILDER) allows you to create muscle
bulges on the geometry around skeleton bones. The
shape of these muscle bulges can be freely defined
using the Section editor in the CHARACTER BUILDER
frame type of the deformation control window.
You can define any number of bulge shapes. The
bulge definition shapes are not stored in the wire
file, but in an ASCII file called bulge_types which
resides in your misc_data directory of your current
project. The advantage of storing these bulge
shapes in a separate file outside of your wire file is
that you can build a catalogue of bulge shapes, and
reuse them from wire file to wire file, and even
from project to project (you can copy the
bulge_types file from one project directory to
another).
Caution!
Be careful when you modify or delete bulge
definitions in the interactive package.
When you “assign attributes” to a skeleton joint,
one of the attributes is the bulge definition. The
skeleton joint does not store the whole bulge
definition, but rather the bulge definition code.
Thus if you have several wire files that use the
same bulge definition and you modify the bulge
definition in the interactive package, you are
actually modifying the bulge definition for all wire
files that reference that bulge code. In particular, if
you delete a bulge definition in Studio, you may be
deleting a bulge definition that is used not only by
a skeleton joint in your current Studio session, but
also in any other wire file you may have previously
saved that used that bulge code.
In Studio, if you start to delete a bulge definition, a
confirm box will appear warning you to this effect.

File Formats
30
Bulge definition
The bulge_types file format
Each bulge shown in the Bulge Definitions Lister in
the Deformation Control window is defined in the
bulge_types file in the misc_data directory.

If this file doesn't exist, Studio copies a default

version of the file to the misc_data directory.
A bulge definition consists of a sequence of
keywords (followed by a colon) followed by values
related to the keyword.
A bulge definition is complete when it contains one
“Initialization” section, at least one “Section
Definition” per Initialization, and at least two
“Keypoint Definitions” per Section Definition.
Any incomplete or poorly defined bulge definition
is omitted from the Bulge Definition Lister entries. The
errlog will contain a record of bulges not added to
the Lister.
Bulge Initialization
•The beginning of a bulge definition is marked
by a line containing two keywords: “bulge”
and “code”.
•>> bulge: “bulge name” code: unique_id
•The “bulge name” string must be enclosed in
double quotes. Bulge names may contain
spaces as well as most other standard
characters (ASCII range 32 to 126) except the
double quote.
•The unique_id value is an integer that
uniquely identifies this bulge in the
bulge_types file. If the bulge file contains a
definition that uses a bulge code already used
by another definition, a new and unique code
will be assigned to that bulge definition and a
message is appended to the errlog. The bulge
code must be an integer larger than or equal
to 0.
Section Definition
•The next part of the file defines how bulges
should appear at various locations or
“sections” around the bone.

File Formats
31
Bulge definition
 >> angle: 0

•The Section Definition contains the keyword

“angle” followed a degree value, locating the
profile curve (defined by the keypoint
definitions that follow) around the bone at the
given angle. The angle value must be an
integer between 0 and 360.
Note: A bulge must contain at least one Section
Definition.
Keypoint Definition
•The next lines of the section definition are
floating point triplets that locate “keypoints”
in the section's profile curve.
>> 0.000000 0.000000
0.000000
>> 0.291667 0.291667
0.012503
>> 0.629167 0.629167
0.120864
>> 1.000000 0.954167
0.012503

•The first value is the location of the keypoint

along the bone. In Alias, this is represented by
the circle icon. It is this value that determines
where the bulging clusters are positioned
along the length of the bone. A value of “0.0”
represents the upper endpoint of the bone
while a “1.0” represents the lower endpoint.
•The second and third values of a keypoint
determine the overall shape of the bulge. The
two values determine the direction and
amount of bulge contributed at that keypoint.
In Alias, these two values represent the (x, y)
co-ordinate of the X icon.
Note: If the first and second values of a keypoint
are not the same, you get bulging occurring
not only _away_ from the bone, but also
_along_ the bone.
RESTRICTIONS:
•A section must have at least two keypoint
definitions, one at “bone” location 0.0 and one
at “bone” 1.0.

File Formats
32
Bulge definition
•A keypoint definition's first two values must
be greater than the previous definition's
corresponding values, if any exist.
•A keypoint definition's first two values must
be between 0.0 and 1.0, inclusive.
•A keypoint definition's third value must be
between -0.5 and 0.5, inclusive.
Example
A sample bulge definition (from the default
bulge_types file) is as follows:
>> bulge: “Generic” code: 5
>> angle: 0
>> 0.000000 0.000000
0.008335
>> 0.500000 0.500000
0.250000
>> 1.000000 1.000000
0.000000
>>
>> angle: 180
>> 0.000000 0.000000
0.000000
>> 1.000000 1.000000
0.000000

Note: Sections in the same bulge definition do not

have to have the same number of Keypoint
Definitions.

File Formats
33
Bulge definition
 File Formats
34
Bulge definition
Index

A
ALIAS
camera depth file format, 9
depth map format, 9
file formats, 5
matte file format, 7
particles file format, 28
pix file format, 5
Alias pix 24
Animatable item types, 19
Animated
SDL files
example of, 21
Animation
parameters,
and Animation SDL files, 20
SDL files, 18
animation parameters, 20
Animation SDL files, 20

C
Channel statements 20
CVs
Curve, 19
surface, 19

D
DAG nodes, 19
Definition section
of Animation SDL file, 18
Depth
camera file format, 9
map format, 9

E
exporting
polygons 11, 14

F
File
> Export > Polygons 11, 14
file formats
polygons 11, 14

File Formats
35
Index
File formats, 5
camera depth files, 9
mask files, 7
matte files, 7
File formats, depth map, 9

H
Hierarchy section of Animation SDL file, 18

I
IFF files 24

L
Lights,
and Animation SDL files, 19

M
Mask
files,
format, 7
Matte
files,
format, 7
Maya files 24

O
object-separated quadrilateral format 14
object-separated triangle format 11

P
Pix
files,
format, 5
polygons
export format (quadrilateral) 14
export format (triangular) 11
exporting 11, 14

S
SDL
Animation files, 18
animation parameters, 20
example of, 21
SDL Animation files, 20
Shaders
and Animation SDL files, 19

File Formats
36
Index
Surface
CVs
and Animation SDL files, 19

T
Textures
and Animation SDL files, 19
TIFF 24
triangle file, how to read 13

Z
zero count objects 11

File Formats
37
Index