Star Trek: Armada is based on the Storm3D Engine which was introduced with Battlezone. As such it uses basically the same technology. Storm3D Object Definition files, or SODs for short, are Battlezone's/Armada's means of defining three dimensional objects, including their texture/material use, mesh definition and model hierarchy. In essence, they form the models of units, stations and other 3D objects of the game.

They are placed in SOD folder of the game installation folder. They do not come with the texture files included in themselves. Those are still placed in folder Textures\RGB in form for TGA files. But their names are referenced by the SODs. Together with sprites and emitters they form the full model, that can then be used by ODF Files.

The 3D mesh part of the model must be created/modified with some sort of 3D modeling tool, such as Storm3D Tool, Milkshape 3D or 3DS Max. But usually they require some sort of importer and exporter to make SODs usable. The application of textures is also very often done with the same tools, while the creation of such textures is done with graphics programs such as GIMP.

The node hierarchy is also applied by the modeling tools, but depending on which you use, you might need another one to get it working properly. (E.g. Milkshape 3D is not particularly well suited for the directing of nodes, but at least you can create and place them.) The sprites and emitters are described somewhere else, but must be made referenced by the hierarchy by name.

The following is taken from the document created by Steve Williams. You can find this original source in section Web Links.

SODs are for the most part binary content files. This article describes version 1.8 of the SOD format. To understand how SODs work, you need to know the following data types:

An SOD consists of five sections:

1. File header,
2. list of lighting materials
3. node hierarchy definition (recursively, starting with the root node).
4. animation channels and
5. animation references.

Every SOD starts with the ASCII string Storm3D_SW, followed by the version of the used format in form of one FLOAT value. So the header always has the length of 14 bytes. For Star Trek: Armada the version is 1.8, making the 4 version bytes always be 0x66 0x66 0xE6 0x3D.

The second section of an SOD contains the characteristics of the vertex lighting materials. To understand this, we need some more definitions.

The surface lighting can use Phong reflectivity model or Lambertian reflectance. The model used can be one of the following three:

LIGHTING_MODEL:

Each surface can use a lighting material, which is defined like this:

LIGHTING_MATERIAL:

The full list of lighting materials consists of the following information:

1. UINT16: The number of materials defined in the SOD.
2. LIGHTING_MATERIAL ARRAY(<number of materials>).

Note: Lighting materials are usually not unique to a specific SOD but used by multiple SODs. As this is the case, loading can be expedited considerably by not loading lighting materials anew for each SOD, but looking for already loaded materials from previously loaded SODs. One implication of that is, that the materials are consistent across SODs. One special aspect about this is the file Material.SOD, which contains a number of materials being loaded prior to most SODs, defining the most common materials.

The third section in an SOD are the nodes, which have various implications on the behavior of a unit or station, including things like firing direction, damage indicators, mesh referencing or LODs used. They come in five different types.

NODE_TYPE:

A node as such can be of the described type and may need additional information, depending on the type. But the general node definition looks somewhat like this:

NODE

This particular type has no additional data. It is solely used to mark locations and directions, e.g. for hardpoints and to function as grouping points for other child nodes making up the hierarchy.

Similar to Null nodes, this node has no data. It serves as a grouping node for child LOD nodes. Depending on distance and size of a mesh used for LODs, the corresponding mesh is used for display or not.

Those come in two flavors, actual sprites and particle emitters.

Actual sprite nodes do not have any actual data by themselves. The IDENTIFIER of the node itself contains the information. They serve as a localization means, including direction for sprites to face at. The actual sprite information comes from the sprite itself.

The emitters on the other hand need an additional IDENTIFIER for emitter sprites:

TYPE_SPECIFIC_DATA<PARTICLE_EMITTER>

These nodes tie the mesh to the hierarchy. Meshes consist of vertices, making up faces. Each face can have its own lighting properties.

The vertices in the SOD sense consist if two values, one for the actual mesh and one for the tied-to-it texture vertex. The coordinates are not stored directly but in form of the indices in the vertex arrays of mesh vertices and texture vertices. The combination of both makes it possible to map a texture onto a surface made up of faces very specifically.

FACE_VERTEX

A face is made up by three vertices. As such each face references three vertices:

FACE

The lighting of each face is basically a combination of all faces with the same lighting material tied with said material into one so-called lighting group.

VERTEX_LIGHTING_GROUP

A mesh is then made up of vertex positions as well as texture positions and the texture name itself, as well as the material. The number of said vertices and texture positions as well as the number of lighting groups is stored in a mesh information, along with a culling type (what happens if you look at a texture from the wrong side, is it removed when looking from the wrong side, or not).

TYPE_SPECIFIC_DATA<MESH>

The fourth section of an SOD contains the animation channels. An animation is basically the model altered in form and texture for each point in time, allowing for a series of meshes to be shown one after another, like in a movie, making up the animation/movement of said model. This gives a model the means of moving, for example a fan rotating instead of standing still.

Animation channels are basically the animation of the mesh itself. If the textures on the faces are supposed to change as well, those would be the Animation References.

An animation channel consists of the following data:

ANIMATION_CHANNEL

The entirety of animations is stored like this:

The fifth and last section contains the animation references. In contrast to the Animation Channels, animation references are used to animate the textures themselves. The textures used for this are basically sprites. So each step of the animation from a sprite is used during the animation sequence, but as part of a model.

The animation is made up as a list of animation references of this form:

ANIMATION_REFERENCE

The animation references are then stored as a list:

A texture material defines characteristics of a polygon rasterizer used to render the polygons of a given mesh. In case of Star Trek: Armada, there is a fixed set (hard coded) of allowed values:

• Storm3D Object Definition (SOD) File Format on Armada Files
• Storm3D Object Definition (SOD) File Format on DS-Servers
• Storm3D Object Definition (SOD) File Format on GameFront