Differences

This shows you the differences between two versions of the page.

--- en:games:star_trek_armada_1:modding:model_hierarchy [2025-03-29-16-40] – [Summary] 7saturn
+++ en:games:star_trek_armada_1:modding:model_hierarchy [2025-04-04-17-20] (current) – [Bot] 7saturn
@@ Line 7: / Line 7: @@
 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 models mesh groups or the number of hardpoints you give them.
-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//. They must not be used for anything else but their standard function.
+Depending on what tool you use, Node names may be prepended by node type prefixes. See [[#node_name_conventions|Node Name Conventions]] on an example for [[.:tools:Milkshape 3D]]. Some names are very specific, serving a unique purpose: //borg//, //crew//, //damage//, //engines//, //geometry//, //hardpoints//, //life//, //lights//, //root//, //sensors//, //shield// and //target//. They must not be used for anything else but their standard function. Others depend strictly on the contents of your model.
 ===== A Basic Hierarchy =====
 Here is an example structure of nodes derived from the [[.:..:Cube]] unit:
@@ Line 16: / Line 16: @@
   borg
   crew
-   s_crew1
+   crew1
   engines
-   e_plasmalrg
+   plasmalrg
   life
-   e_steamlrg
+   steamlrg
   sensors
-   s_sensor
+   sensor
   shield
   target
@@ Line 28: / Line 28: @@
   hp01
  geometry
-  m_bbattleglow1
+  bbattleglow1
   Lod0
-   m_Bbattle_2
+   Bbattle_2
   Lod1
-   m_Bbattle_1
+   Bbattle_1
   Lod2
-   m_Bbattle
+   Bbattle
 </code>
 The indentation represents the hierarchical structure. There are different types of nodes, some of which are mandatory.
@@ Line 47: / Line 47: @@
 Note that when adding multiple damage nodes for crew, the order in which they will start to appear is given by the tailing number in the sprite name, after //crew//. The higher the number, the later the sprite is being displayed (indicating more and more amount of crew damage taken). Higher order damage nodes are added as child node of lower level nodes (making the default sprite //crew16// always be the last and //crew1// always be the first in stock game models).
 ==== 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//. By itself it does not have any direction.
+The node //damage// is mandatory and has strictly a grouping function. It is parent element for the nodes //borg//, //crew//, //engines//, //life//, //sensors//, //shields// and //target//. The //damage// node is a child element of //root//. It does not have any direction and its location has no specific effect by itself.
 ==== 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).
+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). The location or direction of the //engines// node has no relevance by itself, but the location **and** direction of its child nodes does matter.
 ==== 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. [[#LOD Nodes|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_''.
+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 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. [[#LOD Nodes|LODs]] on the other hand are meant for representations of different details. See [[#Level of Display]] on the concept.
-==== 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 ''hp//xx//'', where ''//xx//'' is a unique, serialized number of two digits, beginning with ''01''.
+The //geometry// node should always house nodes with the names of all mesh parts to be visible either constantly or during animations. This specifically excludes //borg// node elements, that are only visible if the unit is occupied by a Borg faction.
+In case of mesh elements being visible only for certain levels of details (lod), the mesh elements must be child nodes of the corresponding lod node (//lod1// to //lod**n**//). In case of animation elements, they must be direct child elements to //geometry//.
+=== LOD Nodes ===
+LOD nodes reference parts of the model by naming convention. //Lod**x**// 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 of the mesh group to be shown for that level of detail. In the above example the sub model //Bbattle_2// if referenced by the most basic LOD, with the number 0. LODs are optional. They don't have any location or orientation.
+==== Hardpoint Nodes ====
+The //hardpoints// node is a grouping node with no direction and no effect of its location by itself. It houses two different types of nodes, actual hardpoints and bot nodes.
+=== Hardpoints ===
+Actual hardpoints are the locations from which weapons fire. They are children of the //hardpoints// element. Each hardpoint is named ''hp//xx//'', where ''//xx//'' is a unique, serialized number of two digits, beginning with ''01''. Their location is directly relevant as point of origin (when pulses, torpedoes, phasers or other originating weapons come from, when they are fired, including [[..:special weapons]]), but also their direction may make a difference in case of directed pulse weapons.
+=== Bot ===
+The //bot**x**// nodes are child elements of the //hardpoints// node. They define the location where the worker bees of [[en:games:star_trek_armada_1:constructor|constructors]] come from.
+=== Repair ===
+Child element of the //hardpoints// node can also be the //repair// node. It is the spot units will move to for repairing. It is found in yards. It is a node with location and direction. The y-direction together with its location is the line in 3-dimensional space units will line up at for repair queuing.
+=== Build ===
+The //build// node almost the same as the //repair// node, except it is used for construction of units, not repairs. It is as such part of yards and [[en:games:star_trek_armada_1:starbase|starbases]].
 ==== Life Node ====
-The //life// node is a child element of the //damage// hierarchy. It's children nodes are usually emitters, a special kind of [[sprites|sprite]]. The are named in the same way as animated SOD models, usually representing flares. See also [[en:games:star_trek_armada_1:modding:emitter_names#steam_and_fog_emitters|Steam and Fog Emitters]] on some commonly used ones for the //life// node. They are indicating the life support system being down. For ships without life support system (e.g. automated stations) it is not needed.
+The //life// node is a child element of the //damage// hierarchy. It's child nodes are usually emitters, a special kind of [[sprites|sprite]]. The are named in the same way as animated SOD models, usually representing flares. See also [[en:games:star_trek_armada_1:modding:emitter_names#steam_and_fog_emitters|Steam and Fog Emitters]] on some commonly used ones for the //life// node. They are indicating the life support system being down. For ships without life support system (e.g. automated stations) it is not needed. While the location and direction of the //life// node has no direct relevance, the location and direction of its child nodes are relevant. They mark the origin of the emitter animation, and the direction the emitter animation will take.
 ==== 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 [[sprite_names#weapon_sprite_names_for_star_trekarmada|Weapons Sprite Names]] article.
+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 [[sprite_names#weapon_sprite_names_for_star_trekarmada|Weapons Sprite Names]] article. The //lights// node itself has no direction and the location does not have an effect by itself. But the child elements locations and directions are both relevant.
-==== LOD Nodes ====
-LOD nodes reference parts of the model by naming convention. //Lod**x**// 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.
+The node named //root// is mandatory. It is parent of the nodes //damage//, //hardpoints//, //geometry// and //lights//. It serves strictly a grouping purpose. As such it has no orientation and its location is not relevant by itself.
 ==== Sensor Node ====
-This node is child of the //damage// node and has its own children.
+The //sensor// node is child node of the //damage// node. It has no orientation and its location is not relevant by itself. It serves as a grouping node for sprite nodes. These are in stock models animated sprites, that look like welding sparks. These sprites of course have an orientation and location.
 ==== 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_''.
+The node //shield// is child of //root//. It represents shield system damage. Child elements of it are referencing sprites shown when the shield generator is failing (red) but not when it is simply deactivated, like in a Cerulean Nebula (yellow). As always, sprite nodes have not only their location but also their direction as relevant information.
 ==== 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_''.
+The node hierarchy //target// is child of //damage// and sprite nodes. By itself it has no orientation and its location has no effect by itself. Its child nodes are the names of the sprites shown when the weapons are down.
+===== Node Names for Multiple Occurrences of the Same Name =====
+If you have to add a specific emitter or other node multiple times, the game will need you to specify different names for them, although of course e.g. an emitter like //plasmamed// still has only one name. The solution for this is adding a number at the end of such a node, e.g. like this: ''plasmamed_1'' and ''plasmamed_2''. The game will recognize that both times //plasmamed// is meant. So you can make both of your nacelles each have a plasma leak at the same time.
 ===== 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. [[.:tools:3DS Max]] and [[.:tools:Storm3D Tool]] do 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_''.
+Apparently //Milkshape// in conjunction with an SOD exporter requires the normally none-prefixed node names to be prefixed with indicators such as ''h_''. These prefixes indicate what type the node has. The different types are as follows:
+{{tablelayout?colwidth="90px,55px"}}
+^  Type  ^  Prefix  ^  Description  ^
+| //hardpoints// | ''h_'' | Some technical elements being part of the hierarchy, not necessarily having an artwork-like function (like applying a texture or giving a direction of something). This may include structuring nodes, like //borg//, but also nodes with special tasks, such as the bee-nodes //bot**x**//. Structuring nodes have a location that does not really matter by itself. The location of the child elements on the other hand may very much be relevant, e.g. for //hp// nodes (actual hardpoint nodes). Depending on the situation, some of the child elements may even have a direction, such as hard points (directed pulse weapons will only fire in the general direction the node points to). |
+| //sprite// | ''s_'' | A location **and** direction of a sprite texture being applied (e.g. crew damage indicators). |
+| //emitter// | ''e_'' | A 3D animated object with location **and** direction, usually damage indicators for life support and engines being down. |
+| //mesh// | ''m_'' | An actual 3D object, e.g. Borg modification indicators, that only appear, when a ship is commandeered by a Borg faction. These nodes don't have a direction and their location is arbitrary. The vertizes/faces of the mesh itself define where the mesh will appear and how it is oriented. |
+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 into Milkshape 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 nodes with the correct prefixes. Otherwise your model may not work (e.g. not show the meshes used or not exhibit certain behaviors, such as damage indicators).
+Here are some examples of what that may look like:
+^  Node Name  ^  Milkshape Node Name  ^
+| //Bconst// | //m_Bconst// |
+| //borg// | //h_borg// |
+| //bot1// | //h_bot1// |
+| //crew// | //h_crew// |
+| //crew1// | //s_crew1// |
+| //damage// | //h_damage// |
+| //engines// | //h_engines// |
+| //geometry// | //h_geometry// |
+| //hardpoints// | //h_hardpoints// |
+| //hp01// | //h_hp01// |
+| //life// | //h_life// |
+| //lod1// | //h_lod1// |
+| //lod2// | //h_lod2// |
+| //plasmamed// | //e_plasmamed// |
+| //poly1// | //m_poly// |
+| //root// | //h_root// |
+| //sensor// | //s_sensor// |
+| //sensors// | //h_sensors// |
+| //shield// | //h_shield// |
+| //steamlrg// | //e_steamlrg// |
+| //target// | //h_target// |
 {{page>footer&nofooter}}
 [\_[[..:modding|Back to Modding]]\_]