User Tools

Site Tools


en:games:star_trek_armada_1:modding:model_hierarchy

Star Trek: Armada Model Hierarchy

Summary

Star Trek: Armada utilizes SOD files, that basically contain each units' structural definition, the mesh, as well as references to the textures to be applied to the faces defined by it.

Along with that come also the so-called node definitions. Each node has a specific role, like functioning as a point of origin from which weapons fire or from where damage-flares are emitted. A node has a vertex position and a direction in which it points. For certain types of nodes the direction has no effect. For others it has (e.g. directed pulse phasers or the orientation of damage indicator sprites).

The totality of the nodes is part of the node hierarchy of the model. Each node is tied to a parent node, except for the root node, which stands for itself. While the textures on the faces of the mesh are clearly visible, nodes serve as location points of other elements, so are by themselves not visible. The names of nodes are in part fixed, in part depend on your model.

Node names prepended by e_, s_, m_ or hp are reserved nodes. Some names are very specific, serving a unique purpose: borg, crew, damage, engines, geometry, hardpoints, life, lights, root, sensors, shield and target.

A Basic Hierarchy

Here is an example structure of nodes derived from the Cube unit:

root
 damage
  borg
  crew
   s_crew1
  engines
   e_plasmalrg
  life
   e_steamlrg
  sensors
   s_sensor
  shield
  target
 hardpoints
  hp01
 geometry
  m_bbattleglow1
  Lod0
   m_Bbattle_2
  Lod1
   m_Bbattle_1
  Lod2
   m_Bbattle

The indentation represents the hierarchical structure. There are different types of nodes, some of which are mandatory.

Node Types

Borg Node

Nodes of this type are simply named borg. Borg nodes are serving the task of parts of the model to be displayed, once it has been built or assimilated by a Borg faction. For all other factions the model referenced by them is invisible. The borg node is child node of damage and it is optional.

Crew Nodes

The crew node is child element of damage and the parent of further nodes that are displayed when the unit suffers crew losses. It is optional (e.g. crew-less units won't need it).

Damage Node

The node damage is mandatory and has strictly a grouping function. If is parent element for the nodes borg, crew, engines, life, sensors, shields and target. The damage node is a child element of root.

Engine Nodes

The node named engines is a child of the damage element. Child elements of engines are used as damage indicators, when the engines are down. They are optional (e.g. for stationary models it makes little sense to have them).

Geometry Nodes

The node with the name geometry is mandatory. It represents the actual unit's optical manifestation. Without it the model will not be visible. It is the child element of the root node and the parent of sub-parts of the geometry definition. Some are special in their function, such as the glow element. It makes the unit get the team color. LODs on the other hand are meant for representations of different details. See Level of Display on the concept. The general geometry defining node is the name of the mesh (or mesh group) prepended by m_.

Hardpoints

Hardpoints are the locations from which weapons fire. They are children of the hardpoints element, which in turn is child of root. Each hardpoint is named hpxx, where xx is a unique, serialized number of two digits, beginning with 01.

Life Node

The life node is a child element of the damage hierarchy. It's children nodes are named in the same way as animated SOD models, usually representing flares. They are indicating the life support system being down. For ships without life support system (e.g. automated stations) it is not needed.

Light Nodes

The root hierarchy may also contain the lights node. If used it holds elements, that are used for lighting, such as positioning lights. Child nodes of lights are named by sprite names that can be found in the file lights.spr in the Sprites directory of your Armada main directory or in the Weapons Sprite Names article.

LOD Nodes

LOD nodes reference parts of the model by naming convention. Lodx with x being a number, defines the level of detail. Each LOD node has a child node, that references the part of the model by name by being named in the same fashion, prepended with an m_. In the above example the sub model Bbattle_2 if referenced by the most basic LOD, with the number 0. LODs are optional.

Root Node

The node named root is mandatory. It is parent of the nodes damage, hardpoints, geometry and lights. It serves strictly a grouping purpose.

Sensor Node

This node is child of the damage node and has its own children.

Shield Nodes

The node shield is child of root. It represents shield damage. Child elements of it are named by sprites shown when certain levels of damage are reached. The names are prepended by s_.

Target Nodes

The node hierarchy target is child of damage and contains nodes, that are shown when the weapons are down. They are named by sprites to be shown and a prepended s_.

Stock Game Node Names

The names of nodes used in the stock game can be found in article Node Names.

Level of Display

The further away the view point of the player is from the unit, the less details a unit needs, in order to still look good. To facilitate this concept of dynamically shown models or model parts, Levels of Display (LOD). Parts of the mesh are named specifically, to be referenced by the hierarchy on form of LOD nodes.

Particle Emitters

Emitters are usually kind of flares (e.g. the fountain displayed when engines are down). Node names referencing them are prepended with e_.

Hierarchy Creation With Milkshape

Modelling

Milkshape is not particularly well suited when it comes to creating the node hierarchy. It does not know of the concept, somewhat. Instead of it, the joint concept usually used for animations, takes its place. This has the implication, that every joint does still have a direction (just like nodes) but the location of one joint is always depending on the location of its parent element. The parent element concept is basically the same as meant for nodes. But positioning a node is not as free as it is usually required. So creating the nodes in Milkshape is not advised. 3DS Max does a far better job.

Node Name Conventions

Apparently Milkshape in conjunction with an SOD exporter requires the normally none-prefixed node names to be prefixed with h_. So for example the damage node will not be named just damage but has to be named h_damage in order to work properly. SODs imported will already fit this naming convention. When you have a look at the interior of SOD files exported from Milkshape, the names will be set to normal (for our example, still be named damage), too. But when creating nodes yourself, you have to prepend the names of specific nodes given here with h_.

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
en/games/star_trek_armada_1/modding/model_hierarchy.txt · Last modified: 2024-01-16-22-41 by 7saturn

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki