Yeah, I know, they're tricky... I will just play around with it and see, like for example, I'll remove all the lights and make them again, (all in one session) or somthing. If it's real annoying, I'll remove the whole tree and start over, like in post #27. Good luck!
1) You cannot use Milkshape for animated Armada models. 2) Be sure to read Major A Payne Milkshape tutorial. 3) The current sod importer only imports stock models. 4) Check and double check your hierarchy. 5) See information below pertaining to the Storm3D Object Definition (SOD) File Format as it will give you some additional insight.
Here’s the Storm3D Object Definition (SOD) File Format for those that are interested. If you’re a C++ coder this probably will make more sense.
Storm3D Object Definition (SOD) File Format =========================================== Author: Steve Williams Storm3D Graphics Engine Lead. Copyright (c) Activision 2000.
Modifications : Fixed node specification error.
Audience ======== This document is intended for use by experienced 3D tools programmers for the purposes of writing exporters, importers and conversion tools to/from the .SOD format. A good understanding of real time 3D graphics principles is assumed. The reader is expected to be familiar with real time 3D geometry concepts such as lighting, animation & scene graph hierarchies.
Introduction ============ The SOD file format is a binary file format describing the 3D directed scene graph hierarchies used by the Storm3D rendering engine. Each .SOD file describes one such hierarchy.
The SOD file format has evolved through several versions. This document describes the latest format, 1.8. Documentation of previous formats is not available at this time.
Datatypes used in this document =============================== UINT8 unsigned 8 bit integer UINT16 unsigned 16 bit integer UINT32 unsigned 32 bit integer FLOAT floating point (4 byte) value VECTOR2 {FLOAT u, FLOAT v} VECTOR3 {FLOAT x, FLOAT y, FLOAT z} MATRIX34 { VECTOR3 RIGHT, UP, FRONT, POSITION } MATRICES MUST BE ORTHOGONAL. COLOUR { FLOAT red, FLOAT green, FLOAT blue } Component range 0.0 - 1.0
Other local datatypes are defined where appropriate.
Additional Syntax ================= TYPE ARRAY(nentries) - A contiguous array of nentries of type TYPE
Identifiers ===========
IDENTIFIER { UINT16 strlen(string), string (8 bit ascii values) including terminating '\0' OR UINT16 0 - Indicates null string. }
File Structure ==============
Section 1 : File Header Section 2 : Lighting Materials Section 3 : Nodes - Written recursively from the root. Section 4 : Animation Channels Section 5 : Animation References
Section Description ===================
Section 1 : File Header =======================
HEADER Storm3D_SW File identification header (8 bit ascii values) - no strlen or terminating '\0'. FLOAT version Current version is 1.8, older formats are not described at this time.
Section 2 : Lighting Materials ============================== Defines the characteristics of the vertex lighting materials defined in this .SOD file.
UINT16 count - The number of lighting materials defined in this file.
LIGHTING_MATERIAL ARRAY(count) Array of lighting materials.
LIGHTING_MATERIAL { IDENTIFIER identifier Name of the lighting material. COLOUR ambient Real time lighting ambient component COLOUR diffuse Real time lighting diffue component COLOUR specular Real time lighting specular component (only used by the phong illumination model) FLOAT specular power Specular exponent, used to determine the 'shininess' of material using the phong illumination model. UINT8 lighting model (constant=0, lambert=1, phong=2) }
Section 3 : Nodes =================
The nodes consist of 5 types NULL, LOD_CONTROL, SPRITE, MESH and EMITTER which together form a scene graph which describes the object's hierarchy.
UINT16 count - The number of nodes in the hierarchy.
<Update: Note node_type & identifier order has been switched to correct error in initial specification.>
NODE { UINT16 node_type (0 - null, 1- mesh, 3 - sprite, 11 - LOD control node, 12 - emitter) DO NOT USE OTHER VALUES. IDENTIFIER identifier IDENTIFIER parent (which will be null for root node) MATRIX34 local transform TYPE_SPECIFIC_DATA<node_type> Type specific data field as defined below. }
Null Nodes ==========
TYPE_SPECIFIC_DATA<NULL> { No addtional data required. }
Null nodes are used for two purposes : 1. As 'glue' to stick the rest of the hierarchy together 2. To mark specific locations in the hierachy, for example, hardpoints.
LOD Control Nodes =================
TYPE_SPECIFIC_DATA<LOD_CONTROL> { No additional data required. }
Storm3D uses discrete (rather than dynamic) LODs for level of detail control. Each child of an LOD control node indicates a discrete LOD that the graphics engine may use when rendering this object. LOD selection is based on visible on-screen area.
Sprite Nodes ============
TYPE_SPECIFIC_DATA<SPRITE_NODE> { None: The appropriate sprite node definition to use is determined from the identifier. The sprite node definition is defined in the .spr files. }
Examples of sprite node usage include running lights in ST:Armada.
TYPE_SPECIFIC_DATA<PARTICLE_EMITTER> { IDENTIFIER Emitter used by this node as defined by an @emitter description in the .spr files. }
Polygon Mesh Nodes ==================
TYPE_SPECIFIC_DATA<MESH> { IDENTIFIER texture material (0 for default) - Defines the TEXTURE_MATERIAL to be used by this mesh. IDENTIFIER texture (0 if untextured) UINT16 nvertices : Number of vertices UINT16 number of texture coordinates (ntexcoords) UINT16 number of vertex lighting groups (ngroups)
ANIMATION_CHANNEL ARRAY(count) Array of animation channels.
ANIMATION_CHANNEL { IDENTIFIER node : The node to which this animation channel refers. UINT16 nkeyframes : The number of keyframes used by this channel. FLOAT channel_period : The length of time one loop of this channel lasts. UINT16 0 : Not currently used. Must be 0. MATRIX34 ARRAY(nkeyframes) keyframe_data : The actual animation transforms, evenly spaced over time 'channel_period'. }
Animation references are a way of linking texture (flipbook) animations defined in the .spr files to the geometry of a .SOD mesh node. An example of their usage is the flipbook animation applied to the geometry for the various shield effects in Armada.
ANIMATION_REFERENCE { UINT8 type : Must be 4 IDENTIFIER node : The node to which this animation applies. IDENTIFIER anim : The animation (as defined in .spr files) that is to be applied to this node. FLOAT playback_offset : Time offset in seconds to be applied to this animation reference. }
Additional Information ======================
Vertex Lighting Material Sharing ================================
Vertex lighting materials are shared between objects, when parsing a .SOD file, Storm3D searches for a match in all previously loaded files. If a match is found, that material is used. This prevents artists from having to ensure the material characteristics of commonly used materials are correct in each file, and also saves memory.
A 'palette' of commonly used materials can be found in materials.sod In Armada, this file is loaded prior to most other SOD files & so defines the characteristics of many common materials.
Hierarchy Structure (Armada Specific) ===================================== Armada uses various nodes in a Storm3D hierarchy for special purposes. These include hardpoints, damage nodes, running lights, borgification. When generating new artwork, the artist must pay careful attention to the structure of the hierarchy for the new object to function correctly in Armada. A definition of the hierarchy structure required by Armada is beyond the scope of this document. For the time being, existing artwork can be used as a reference.
TEXTURE_MATERIAL Definition =========================== A texture material defines the characteristics of the polygon rasterizer used to render the polygons in a given mesh. The texture materials are currently fixed and defined within the executable. Useful values are :
default - Standard material additive - Use additive blending translucent - Semi transparent alphathreshold - Use for objects using alpha channel 'cut outs' - alpha channels will have hard edged 'threshold' but objects will be drawn quickly. alpha - Uses entire alpha channel. Object will require sorting, so will have performance implications. wireframe - Use wireframe graphics.
1) You cannot use Milkshape for animated Armada models.
Good to know. Saves lots of long hours of pointless frustration.
Quote:
Originally Posted by pepperman
2) Be sure to read Major A Payne Milkshape tutorial.
Indeed. This also saves long hours...
Quote:
Originally Posted by pepperman
3) The current sod importer only imports stock models.
Probably to keep people frrom stealing others' work.
Quote:
Originally Posted by pepperman
4) Check and double check your hierarchy. 5) See information below pertaining to the Storm3D Object Definition (SOD) File Format as it will give you some additional insight.
Thanks for the info. I don't see myself writing a SOD importer or exporter, though. If I ever make a decent model, I'll consider myself accomplished.
What about emitters? I followed the instructions, but all I get is the "bug box from hell" in the game, which suggests a problem with the SOD file. If I go back to the model and remove the e_steamsml, and export again, the model shows up, just fine.
Last edited by Flash525; April 21st, 2006 at 07:12 AM.
Reason: Merged
2. Create root node at the x,y,z center.
==>h_root
3. Create hardpoint root node as a child of the root node at the x,y,z center (h_root)
==>h_hardpoints
4. Create each individual hardpoint as a child of the hardpoint root node (h_hardpoints) placing them at their respective location on the model.
====>h_hpXX where XX is a numerical sequence beginning with 01
5. Create mesh node for each mesh group you have as a child of the root node (h_root) at the x,y,z center
==>m_meshname where meshname is the actual name of the mesh group in the model
6. Create a damage node as a child of the root node at the x,y,z center (h_root)
==>h_damage
7. Create an engine node as a child of the damage node at the x,y,z center
==>h_engines
8. Create a sprite node as a child of the engines node placing it at its respective location on the model
Okay, at this point your hierarchy should look like this.
h_root
==>h_hardpoints
====>h_hp01
====>h_hp02
====>h_hpNN Where NN is the last node you used.
==>m_meshname1 ==>h_damage ====>h_engines ======>e_plasmasml
Now export the model using the sod exporter and see if the nodes are in the right place using the Storm 3D viewer. If this works for you try a similar process to add the life node with its respective children and the lights node and its respective children.
That's what I think I'm doing. At some point I kinda made it work, but I was venting plasma even when the ship was not damaged. That was not the idea. :-(
Typically, this is a sign the the hierarchy isn't quite right. The plasma may be venting because it is connected under the engines node which in turn is connect to the damage node. When it isn't connected in this manner it works outside of the damage instruction. Try exporting the model with the minimum. root node, mesh, damage-engine-plasma and see if you can get it to work.
I work delete the model from the sod directory before saving the new one as well as I have seen this make a difference.
I don't know enough about it, but I have heard MS3D+exporter don't support animation, so don't spend too much blood, sweat and tears over this, unless you have the software that would work for it.
Quote:
Originally Posted by pepperman
Typically, this is a sign the the hierarchy isn't quite right. The plasma may be venting because it is connected under the engines node which in turn is connect to the damage node. When it isn't connected in this manner it works outside of the damage instruction. Try exporting the model with the minimum. root node, mesh, damage-engine-plasma and see if you can get it to work.
I work delete the model from the sod directory before saving the new one as well as I have seen this make a difference.
Well, I had some success with it. I got the emitters to work at the right time, but the plasma/steam comes out of the wrong place, and if I try to add more than one emitter of the same kind, the SOD is "damaged."
Last edited by Flash525; April 21st, 2006 at 07:13 AM.
Reason: Merged
How on earth do you add more than one green / red light, or more tan one steam vent with MS3D? One would think you'd add "_1" afterwards (once you wish to get onto more than one) but it doesn't work...
How on earth do you add more than one green / red light, or more tan one steam vent with MS3D? One would think you'd add "_1" afterwards (once you wish to get onto more than one) but it doesn't work...
Anyone know why? And a way around it?
I have no problem adding more than one strobe by naming them _2, _3, but I could never add two or more steam or plasma emitters.
Isn't it strange, how we are using the same software and following the same steps, and getting different results?
Wait, do you name your strobes "redstrobe, redstrobe_1"? Or "redstrobe, redstrobe_2"? I don't use _1.
This site is part of the Defy Media Gaming network
The best serving of video game culture, since 2001. Whether you're looking for news, reviews, walkthroughs, or the biggest collection of PC gaming files on the planet, Game Front has you covered. We also make no illusions about gaming: it's supposed to be fun. Browse gaming galleries, humor lists, and honest, short-form reporting. Game on!
ST:A2 Problems, Errors and Help 
Re: Milkshape 3D 
Linear Mode
