3.1 Cell Type

The cell type value is a decimal integer value that indicates the type of cell definition that follows:

3.2 Cell Flags

This is a bit-field containing a number of different flags; each flag is a bit from the binary equivalent of the decimal integer value. Bits are numbered, starting from the least significant (i.e. right-most), consecutively beginning with 0. For example, the decimal value 21 is 1101 in binary, indicating that bits 0, 2, and 3 are set - all other bits are clear.

It is essential that these flags are scanned since they determine the subsequent formatting of the cell data.

3.3 Examples

Here are some sample cell headers to illustrate this section:

115 17

The above cell header defines a vector list (cell type 115). 17 is the decimal representation of the binary value 10001. Looking at the bits making up the value 17, we see that we need to set bits 0 (value 1) and bit 4 (value 16) and clear all the other bits; consequently, we can deduce that the vector list's attributes are present and that it inherits its color from its parent set.

700 5

This cell header defines a set (cell type 700) for which a set of attributes and geometry have been defined (5 decimal = 101 binary, therefore bits 0 and 2 are set).

4.1 Examples

Here is a sample bounding box record to help illustrate this section.

-100.0 100.0 -50.0 50.0 0.0 10.0

The bounding box for this cell extends 100 model units in both directions along the local X-axis and for 50.0 model units in each direction on the local Y-axis; it extends 10 model units above the origin on the local Z-axis.

5.1 Face & Edge Colors

Face colors are used for all 3D surfaces (solid graphics mode only) whereas edge colors are used for lines and wireframe graphics (both solid and wireframe graphics mode).

These fields are ignored if cell flag bit 4 is set; in this case, face and edge colors are inherited from the parent set. If the root set inherits from its parent, then the color is assigned elsewhere in AutoMod. For example, a vehicle may be assigned a color in a movement system; it's cell file's root set then inherits this color.

The color is encoded as a decimal integer value, whose meaning should be interpreted as follows:

Note that, as of V8.5, AutoMod allows the RGB (red-green-blue) settings for each color to be specified in the .asilibrc settings file. It is possible, for example, to change color 1 so that it appears blue, yellow, or some custom color. To accurately reproduce the content of a cell file's appearance, the .asilibrc file - if present - should also be processed; the format of this file is currently beyond the scope of this document. Also note that the .asilibrc file permits more than 16 colors to be defined; however, AutoMod does not appear to support colors with numbers outside the range of 0-15.

As of V10.0, AutoMod only uses the face color; edge colors are not supported by the OpenInventor scene graph and are ignored.

The default face and edge color is red (1).

5.2 Line Style

This is a decimal integer value that encodes line style, as defined in the table below. This attribute only affects lines and wireframe graphics (both solid and wireframe graphics mode) and does not affect the appearance of surfaces (solid graphics mode).

Note: ACE, as supplied with AutoMod V10.0, does not appear to honor line style information when reading cell files; all line styles are reset to solid as the cell file is read in. Furthermore, ACE only offers solid and dashed line styles when editing a cell.

This attribute has no effect on sets and is not inheritable.

The default line style is solid (0).

5.3 Line Width

5.4 Display Style

This is a decimal integer value that encodes how each cell is to be drawn:

Note: ACE includes a display style option called "invisible". However, the cell file format does not support invisible cells and therefore "invisible" cells become visible the next time the image is loaded. Strange, but true.

This attribute has no effect on sets and is not inheritable.

The default display style is solid (1).

5.5 Name

5.6 Examples

2 2 2 1 0 DashedLine

6.1 Joint Type

This field is a decimal integer value that encodes the joint type:

If the Joint Type is 0, then the TCF data present flag must be 1.

6.2 Joint Speed

6.3 Minimum, Maximum & Current Joint Values

6.4 TCF Data Present

6.5 Examples

Here are some example records to illustrate this section:

1
10.0 0.0 90.0 45.0 0
  0.0 0.0 0.0
0 0.0 0.0 0.0
  1.0 1.0 1.0
0

The above data defines a rotational, dynamic joint. The speed of the joint is 10 degrees per time unit, and motion is permitted between 0 and 90 degrees. The initial position of the joint is at 45 degrees. This is not a terminal set and so no TCF data is present. A default transformation (no translation, no rotation, and unit scaling) is applied to the joint, meaning that the joint's axes are oriented with the owning cell set's axes; rotation takes place around the cell's/joint's local Z-axis.

0
0.0 0.0 0.0 0.0 1
  0.0 0.0 0.0
0 0.0 0.0 0.0
  1.0 1.0 1.0
0
  0.0 0.0 0.0
0 0.0 0.0 0.0
  1.0 1.0 1.0

This example defines a terminal set with no dynamic joint data. Dummy joint data is present (which is ignored since the joint type is none) and the supplied TCF geometry data applies a default transformation (no translation, no rotation, and unit scaling) to the TCF transformations.

2
500.0 -2000.0 10000.0 0.0 1
  0.0 0.0 0.0
0 -90.0 0.0 0.0
  1.0 1.0 1.0
0
  0.0 0.0 0.0
0 0.0 0.0 0.0
  1.0 1.0 1.0

The above joint data defines a translational, dynamic joint which is also a terminal set. The speed of the joint is 500 distance units per time unit, with motion permitted in the range -2000.0 to 10,000.0 distance units. The initial position of the joint is at 0. The joint applies a transformation to rotate the joint -90.0 degrees about the X-axis. This aligns the joint's Z-axis with the owning cell's Y-axis, so that as the current joint value increases, the cell and its contents travel along the cell's Y-axis; the orientation of the cell and (in particular) its contents are unaffected by this transformation otherwise. Since this cell is also a terminal set, TCF data is appended. In this case, a default transformation is applied to the TCF.

8.1 Translation

This record consists of three fields: the translations along the local X, Y and Z axes, respectively. There is no standard convention for the appearance of this record, ACE seems to employ a slightly different format for each circumstance, but the most common is:

<spc><spc>XTran<spc>YTran<spc>ZTran<nl>

where XTran is a double containing the local X-axis translation, YTran is a double containing the local Y-axis translation, ZTran is a double containing the local Z-axis translation, <spc> is the space character and <nl> is the newline sequence.

Note the term "local" when referring to the translation along each axis; the translation is dependent upon the current orientation of the cell. Refer to the section on rotation for additional information. However, translations are applied before the rotation and scaling transformations from the same geometry record.

If geometry data is not present, then the translation values all default to 0.

8.2 Rotation

This record consists of four fields, of which the most common format is as follows:

XYZOrder<spc>Rot1<spc>Rot2<spc>Rot3<nl>

where XYZOrder is an integer indicating the XYZ rotation order (see below), and Rot1, Rot2 and Rot3 are all doubles identifying a rotation, in degrees, about a local axis; which axis is governed by XYZOrder. <spc> is the space character and <nl> is the newline sequence. Note that positive rotation values indicate counter-clockwise rotation, and negative values indicate clockwise rotation.

Note the term "local" when referring to the rotation about an axis; the rotation is dependent upon the current orientation of the cell. For example, if a cell's parent is rotated 90 degrees about the Z-axis, then the local X-axis of all child cells is aligned with the global Y-axis, and the local Y-axis of all child cells is aligned with the global negative X-axis. Note also that rotations are applied after any required translation, but before the scaling transformation, from the same geometry record.

XYZOrder has one of the following values, with the corresponding interpretation:

For example, if the XYZ order is 3, then a rotation of Rot1 is applied to the Y-axis, Rot2 to the Z-axis and Rot3 to the X-axis. These rotations are applied in the order indicated, with the cell's local orientation changing with each.

If geometry data is not present, then the XYZ order defaults to 0 (X, then Y, then Z) and the rotations all default to 0.0 degrees.

8.3 Scaling

This record consists of three fields, of which the most common format is as follows:

<spc><spc>XScale<spc>YScale<spc>ZScale<nl>

where XScale is a double containing the local X-axis scaling, YScale is a double containing the local Y-axis scaling, ZScale is a double containing the local Z-axis scaling, <spc> is the space character and <nl> is the newline sequence.

The specified scaling is applied, as a multiplier, to all dimensions along the corresponding local axis.

If geometry data is not present, then the scaling values all default to 1. Scaling transformations are applied after all translation and rotation transformations from the same geometry record.

8.4 Examples

In the following example, a cell is translated such that it's local origin occupies the global co-ordinates (3.5, -2.0, -10.0), rotated such that the local X-axis is aligned with the global Y-axis and scaled so that the length of the object is changed by a factor of 4.2 - assuming that no parent object applies any geometry translations.

  3.6 -2.0 -10.0
0 0.0 0.0 90.0
  4.2 1.0 1.0

9.1 Arcs & Circles

Arcs require the following parameters, typically formatted as follows:

Radius<spc>StartAngle<spc>EndAngle<nl>

where Radius is a double defining the radius of the arc, StartAngle is a double containing the angle, in degrees, between the local X-axis and the start of the arc, EndAngle is a double containing the angle, in degrees, between the local X-axis and the end of the arc, <spc> is the space character and <nl> is the newline sequence.

Arcs are drawn, counter-clockwise from the start angle to the end angle, on the local X-Y plane. In wireframe mode, an arc is drawn as a fragment of a circular circumference; in solid mode, an arc is drawn as a wedge (acute angles) or like a cheese round with a wedge cut out (obtuse angles). In both cases, the arc's local origin is at centre of the circle of which it is a fragment.

Arcs exist as either coarse arcs or fine arcs; the former are drawn with fewer triangles (or arc-sections, if drawn as a wireframe) than the latter. With the introduction of VR Graphics (using the OpenInventor scene graph rendering engine), ACE creates all new arcs as fine arcs and converts coarse arcs to fine arcs during the read process.

There is one special case: an arc that has a start angle of 0 and an end angle of 360 is a Circle.

9.2 Compiled Pictures

[FileLine<nl>
[...]]
#Inventor END<nl>

9.3 Cones

Cones require the following parameters, typically formatted as follows:

Radius<spc>Height<spc>XOffset<spc>YOffset<nl>

where Radius is a double defining the radius of the base of the cone, Height is a double defining the distance, measured along the local Z-axis, between the base and the tip of the cone, XOffset is a double containing an offset from the X-axis local origin for the tip of the cone, YOffset is a double containing an offset from the Y-axis local origin for the tip of the cone, <spc> is the space character and <nl> is the newline sequence.

Cones are drawn with their base on the local X-Y plane, with the cell origin used as the center of the base, and the cone extending up along the local Z-axis.

9.4 Cylinders

Cylinders require the following parameters, typically formatted as follows:

Radius<spc>Height<spc>XOffset<spc>YOffset<nl>

where Radius is a double defining the radius of the cylinder, Height is a double defining the distance, measured along the local Z-axis, between the base and the top of the cylinder, XOffset is a double containing an offset from the X-axis local origin for the top of the cylinder, YOffset is a double containing an offset from the Y-axis local origin for the top of the cylinder, <spc> is the space character and <nl> is the newline sequence.

Cylinders are drawn with their base on the local X-Y plane, with the cell origin used as the center of the base, and the cylinder extending up along the local Z-axis.

9.5 Definitions & Instances

FilePath<nl>

DefinitionName<nl>
[DefinitionCellDefinition]

9.6 Frustums

Conic frustums require the following parameters, typically formatted as follows:

BaseRadius<spc>TopRadius<spc>Height<spc>XOffset<spc>YOffset<nl>

where BaseRadius is a double defining the radius of the base of the frustum, TopRadius is a double defining the radius of the top of the frustum, Height is a double defining the distance, measured along the local Z-axis, between the base and the top of the frustum, XOffset is a double containing an offset from the X-axis local origin for the top of the frustum, YOffset is a double containing an offset from the Y-axis local origin for the top of the frustum, <spc> is the space character and <nl> is the newline sequence.

Frustums are drawn with their base on the local X-Y plane, with the cell origin used as the center of the base, and the frustum extending up along the local Z-axis.

9.7 Hemispheres

Hemispheres require the following parameters, typically formatted as follows:

Radius<nl>

where Radius is a double defining the radius of the hemisphere and <nl> is the newline sequence.

Hemispheres are drawn with their base on the local X-Y plane, with the cell origin used as the center of the base, and the hemisphere extending up along the local Z-axis.

9.8 Polyhedra

Polyhedra require the following parameters, typically formatted as follows:

NumVertices<nl>
[VertexX<spc>VertexY<spc>VertexZ<nl>
[...]]
NumFaces<nl>
[VerticesInFace[<spc>VertexIndex[<spc>...]]<nl>
[...]]

where NumVertices is an integer defining the number of vertices making up the polyhedron, VertexX is a double defining a local X co-ordinate for a vertex, VertexY is a double defining a local Y co-ordinate for a vertex, VertexZ is a double defining a local Z co-ordinate for a vertex, NumFaces is an integer defining the number of faces making up the polyhedron, VertexIndex is an integer identifying the index of a previously defined point, <spc> is the space character and <nl> is the newline sequence.

Each polyhedron is constructed from a number of faces. Each face is visible from a single side only, depending upon the face's normal vector, and is made up of three or more vertices. The constituent vertices must all lie in the same plane, although ACE does not object if they are not. Furthermore, the vertices must be listed in anti-clockwise order when viewing the intended visible side of the face.

Each vertex is defined as a point made up of an X, Y and Z co-ordinate. These are defined first and are numbered from 0 through to NumVertices - 1. The number of vertex definitions must match the NumVertices parameter. When defining each face, the number of vertices in that face is defined followed by that many vertex indices.

For example, the following defines the parameters for a square polyhedron that is visible from above and below (it requires two faces to do this):

4
0.0 0.0 0.0
1.0 0.0 0.0
1.0 1.0 0.0
0.0 1.0 0.0
2
4 0 1 2 3
4 0 3 2 1

All vertex co-ordinates are relative to the polyhedron's local axes.

9.9 Rectangles

Rectangles require the following parameters, typically formatted as follows:

Width<spc>Length<spc>XOffset<spc>YOffset<nl>

where Width is a double defining the width (local Y-axis dimension) of the rectangle, Length is a double defining the length (local X-axis dimension) of the rectangle, XOffset is a double that is required but ignored, YOffset is a double that is required but ignored, <spc> is the space character and <nl> is the newline sequence.

Note that ACE, for reasons unknown, generally mixes up the terms width and length, so that a cell's width is called its length and vice versa, confusing many users. In this document, at the risk of further confusion to ACE users, the terms width and height are used with their more natural definitions.

Rectangles are drawn on the local X-Y plane, with the cell origin used as the center of the rectangle. The rectangle has an upper and lower face and is visible from both sides.

9.10 Sets

Sets, and block definitions, require the following parameters, typically formatted as follows:

NumChildren<nl>
[ChildCellDefinition
[...]]

where NumChildren is an integer containing the number of child cells belonging to the set, ChildCellDefinition is a complete cell definition for a child cell and <nl> is the newline sequence.

The number of child cell definitions must match the NumChildren parameter.

Note that NumChildren excludes block definitions, file references and any children belonging to child sets.

Since sets contain the definitions of their child sets, and since child sets can themselves have child sets, it can be seen that the inclusion of sets gives cell files a hierarchical structure.

For a discussion of Root Sets and Main Sets, refer to the notes with the section on general file structure.

9.11 Tetrahedra

Tetrahedra require the following parameters, typically formatted as follows:

BaseLength<spc>TopLength<spc>Height<spc>XOffset<spc>YOffset<nl>

where BaseLength is a double defining the side length of the base equilateral triangle, TopLength is a double defining the side length of the top equilateral triangle, Height is a double defining the distance, measured along the local Z-axis, between the base and the top of the tetrahedron, XOffset is a double containing an offset from the X-axis local origin for the top of the tetrahedron, YOffset is a double containing an offset from the Y-axis local origin for the top of the tetrahedron, <spc> is the space character and <nl> is the newline sequence.

Tetrahedra are drawn with their base on the local X-Y plane, with the cell origin used as the center of the base, and each tetrahedron extending up along the local Z-axis.

9.12 Text

Text cells require the following parameters, which have to be formatted as follows:

Text<nl>

where Text is a text string containing the text to be displayed and <nl> is the newline sequence.

Text, which is delimited by the previous line's newline sequence and the newline sequence at the end of this text line (i.e. each text field must be on a line by itself), can contain spaces, but no other whitespace or control characters. Furthermore only 7-bit ASCII characters are processed; 8-bit characters have their 8th bit stripped during a read operation.

Note that the VR Graphics versions of ACE do not appear to support empty text fields.

There are a number of different types of text, as follows:

9.13 Text Lists

Note that Text Lists are not supported in VR Graphics versions of ACE; attempting to read a cell file containing a Text List primitive into such a version will result in errors. However, Text Lists are still supported by the Standard Graphics versions.

Since this feature now seems to be deprecated, and since it causes problems for newer versions, it is recommended that you avoid the use of Text Lists; use the Text primitive instead.

Text List cells require the following parameters, which have to be formatted as follows:

NumItems<nl>
[XTranslate<spc>YTranslate<spc>ZTranslate<nl>
Text<nl>
[...]]

where NumItems is an integer containing the number of items in the text list, XTranslate, YTranslate and ZTranslate are the X, Y and Z translations, for each item, applied after the cell's standard geometry, Text is a text string containing the text belonging to each item, <spc> and <nl> is the newline sequence.

Text, which is delimited by the newline sequence following each item's translation parameters and the newline sequence at the end of the text line (i.e. each text field must be on a line by itself), can contain spaces, but no other whitespace or control characters. Furthermore only 7-bit ASCII characters are processed; 8-bit characters have their 8th bit stripped during a read operation. It is not possible to have an empty text string!

There are a number of different types of text (see Text for more information), but all items in a text list are displayed in the same way.

9.14 Trapezoids & Boxes

Trapezoids require the following parameters, typically formatted as follows:

BaseWidth<spc>BaseLength<spc>TopWidth<spc>TopLength<spc>Height<spc>XOffset<spc>YOffset<nl>

where BaseWidth is a double defining the width (local Y-axis dimension) of the base of the trapezoid, BaseLength is a double defining the length (local X-axis dimension) of the base of the trapezoid, TopWidth is a double defining the width of the top of the trapezoid, TopLength is a double defining the length of the of top of the trapezoid, Height is a double defining the distance, measured along the local Z-axis, between the base and the top of the trapezoid, XOffset is a double containing an offset from the X-axis local origin for the top of the trapezoid, YOffset is a double containing an offset from the Y-axis local origin for the top of the trapezoid, <spc> is the space character and <nl> is the newline sequence.

Note that ACE, for reasons unknown, generally mixes up the terms width and length, so that a cell's width is called its length and vice versa, confusing many users. In this document, at the risk of further confusion to ACE users, the terms width and height are used with their more natural definitions.

Trapezoids are drawn with their base on the local X-Y plane, with the cell origin used as the center of the base, and each trapezoid extending up along the local Z-axis.

There is one special case: a trapezoid whose base and top lengths are equal, and whose base and top widths are equal, is a Box.

9.15 Triads

A triad, which merely displays the orientation of the local axes and the position of the local origin, has a single integer parameter whose purpose is unknown. This typically has the value 1 and is formatted as follows:

Unknown<nl>

where Unknown is an integer and <nl> is the newline sequence.

Current speculation on the purpose of Unknown is that it is a visibility flag: if the value is 0, then the triad is not displayed; any other value and it is displayed, with no noticeable change in appearance. Furthermore, any non-zero value is converted to 1 when ACE next writes the file.

9.16 Vector Lists

Vector lists require the following parameters, typically formatted as follows:

NumVertices<nl>
[VertexX<spc>VertexY<spc>VertexZ<spc>MoveDrawFlag<nl>
[...]]

where NumVertices is an integer defining the number of vertices making up the vector list, VertexX is a double defining a local X co-ordinate for a vertex, VertexY is a double defining a local Y co-ordinate for a vertex, VertexZ is a double defining a local Z co-ordinate for a vertex, MoveDrawFlag is an integer indicating whether a straight line should be drawn from the previous vertex to the current vertex (1) or not (0), <spc> is the space character and <nl> is the newline sequence.

Each vector list, analogous to a Polyline in AutoCAD, is made up of a number of vertices linked by straight lines.

Each vertex is defined as a point made up of an X, Y and Z co-ordinate and a move-draw flag. The MoveDrawFlag of the first vertex must be 0 (move). The number of vertices defined must match the value of the NumVerticesparameter.

For example, the following defines the parameters for a vector list that appears as a square:

5
0.0 0.0 0.0 0
1.0 0.0 0.0 1
1.0 1.0 0.0 1
0.0 1.0 0.0 1
0.0 0.0 0.0 1

All vertex co-ordinates are relative to the vector list's local axes.

9.17 Examples