Joint/Hardpoint Tree Structure Tool -1 reply

Please wait...

Guest

I didn't make it!

0 XP

 
#1 10 years ago

I create tools, for Legacy modding, but Armada shares a fairly common setup in the Hardpoint/Joint area for models in Milkshape. I've recently been working on a tool to aid in the creation of the structure of the Joint/Hardpoint tree for use with Milkshape. I was thinking it might be of use to some of the moders here.

It's a stand alone program that allows building of a "joint tree". This tree doesn't contain any position or rotation data, it's just the joints and their links. Also I added support for Joint Comments which Legacy uses on the Light joints for alteration of strobe patterns and coloration/intensity.

Once a tree is made it is saved to the Milkshape 3d ASCII txt file format and imported using the Milkshape 3d ASCII Text importer. After importing it you just have to relocate the weapon, subsytem, sprites, emitter joints, etc to the appropriate locations.

It can import Mesh Group names to speed entry of the m_ joints via a customized Milkshape Exporter that goes with the tool. I'm going to be working on importing of existing joints along with their position, rotation and comment data at a later time.

Here is a shot of the current interface. jtp2a.jpg

I can't currently make alternate interface options as I don't "know the differences" for A, A2, and Fleet Ops compared to Legacy. Dejavu sent me some things, but it's not exactly what I need to sort it out properly. If someone can fill me in with the data I need, I can make the alternate interfaces, otherwise it will just stay rigged for Legacy as I don't have time to do a lot of hunting.

If you want to look at more data on the tool the main thread for the tool is here: http://forums.filefront.com/stl-modding-mapping-editing/427983-joint-tree-builder-structure-only.html




Freyr Advanced Member

A2Files Staff

46,877 XP

5th February 2005

11 Uploads

4,275 Posts

0 Threads

#2 10 years ago

Muldrf;5395997I create tools, for Legacy modding, but Armada shares a fairly common setup in the Hardpoint/Joint area for models in Milkshape. I've recently been working on a tool to aid in the creation of the structure of the Joint/Hardpoint tree for use with Milkshape. I was thinking it might be of use to some of the moders here.[/QUOTE]

Very probably, thanks for the heads up. I don't model myself, but i'm sure someone that does will drop a message in here in the near future.

Muldrf;5395997 I can't currently make alternate interface options as I don't "know the differences" for A, A2, and Fleet Ops compared to Legacy. Dejavu sent me some things, but it's not exactly what I need to sort it out properly. If someone can fill me in with the data I need, I can make the alternate interfaces, otherwise it will just stay rigged for Legacy as I don't have time to do a lot of hunting.

I'm afraid I don't mod legacy, so i'm not sure of the differences myself. I do happen to have a copy of this though, which probably contains everything you want to know. If not, please ask away. I probably won't know the answer, but I can usually remember where to get the information. =p

Spoiler: Show

[quote=The Storm 3D Lead Developer] 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. color { 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. color ambient Real time lighting ambient component color diffuse Real time lighting diffue component color 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.

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 Type specific data field as defined below. }

Null Nodes ==========

TYPE_SPECIFIC_DATA { 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 { No addtional 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 { 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 { IDENTIFIER Emitter used by this node as defined by an @emitter description in the .spr files. }

Polygon Mesh Nodes ==================

TYPE_SPECIFIC_DATA { 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)

VECTOR3 ARRAY vertex positions (nvertices entries) VECTOR2 ARRAY texture coordinates (ntexcoords entries)

VERTEX_LIGHTING_GROUP ARRAY (ngroups entries)

UINT8 cull type (0 - no cull, 1- (backface cull)

UINT16 0 - unused must be 0. }

VERTEX_LIGHTING_GROUP { UINT16 num_faces (all faces are triangles) IDENTIFIER lighting_material (0=default) FACE ARRAY (num_faces entries) }

FACE_VERTEX { UINT16 index into mesh vertex positions array UINT16 index into mesh texture coordinate array }

FACE { FACE_VERTEX ARRAY(3) 3 entries describing a triangular face. }

Section 4 : Animation Channels (Defines transform animation) ============================================================

UINT16 count // Number of animation channels

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'. }

Section 5 : Animation References (Defines texture animation) ============================================================

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.

UINT16 num_animation_references

ANIMATION_REFERENCE ARRAY(num_animation_references)

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.




Guest

I didn't make it!

0 XP

 
#3 10 years ago

Actually what I am looking for is something like this: 188821-muldrf-albums-porting-picture7112-m3djoints-sample-fr_marauder-model.png

That's the basic Legacy joint tree structure. I need the same type of thing for A, A2 and FleetOps.

The other thing I'm looking for is a list of the various possible sprites for A, A2 and Fleet Ops. That would include "light" sprites and "emitter" sprites and if there are any other type. Also if the naming is different than Legacy "m_" "h_" "s_" For example "whiteconst", "greenstrobe", "plasmasml".

If the trees and options are different for each of those three I may make 3 specific interface setups for them.




Freyr Advanced Member

A2Files Staff

46,877 XP

5th February 2005

11 Uploads

4,275 Posts

0 Threads

#4 10 years ago

Muldrf;5396221Actually what I am looking for is something like this:

That's the basic Legacy joint tree structure. I need the same type of thing for A, A2 and FleetOps.[/QUOTE]

I think that Westworld's Big Book of Modding contains most of this info. The BBOM is the original "bible" that was complied around the time the game was released to explain points to people. I don't know what changes have been made by fleetops.

Westworld's BIG Book of Modding

[QUOTE=Muldrf;5396221] The other thing I'm looking for is a list of the various possible sprites for A, A2 and Fleet Ops. That would include "light" sprites and "emitter" sprites and if there are any other type. Also if the naming is different than Legacy "m_" "h_" "s_" For example "whiteconst", "greenstrobe", "plasmasml".

If the trees and options are different for each of those three I may make 3 specific interface setups for them.

These are the possible emitters for A2:-

Spoiler: Show
@emitter rift @emitter riftcloud @emitter firecomet @emitter icecomet @emitter chunk1_disabled @emitter latinum_spray @emitter test_cloud @emitter smoke @emitter plasmasml @emitter plasmamed @emitter plasmalrg @emitter plasmaxl @emitter steamtiny @emitter steamsml @emitter steammed @emitter steamlrg @emitter steamxl @emitter borgbore_beam @emitter override @emitter microorg @emitter psiondis @emitter microor2 @emitter crpulsar @emitter gemini @emitter contrail @emitter rocket @emitter neb1 @emitter neb2 @emitter premgate @emitter worm @emitter swneb1 @emitter swneb2 @emitter swneb3 @emitter swneb4 @emitter swneb5



Guest

I didn't make it!

0 XP

 
#5 10 years ago

That book does look like it contains the A2 and info on the A1 trees. I'll have to look at it closer. For one there are command nodes "c_". I'll also need to know the valid sprite entries to populate the dropdown boxes to make them easy to use, that might be somewhere else in the book.

That would leave FleetOps, which I take is some addon that uses additional sprites options and maybe some other changes.

Anyway no rush I still have plenty of work to do on the tool before I'd look at starting the alternate interfaces.




Guest

I didn't make it!

0 XP

 
#6 10 years ago

For FO stuff you will need to go talk to the Devs on their site. Modeling for FO is in its infancy since the changed the SOD version and FO models won't work in A2 without being back converted.

The tool sounds very usefull. looking forward to it.




pepperman

Cloaked in the Neutral Zone

50 XP

4th February 2004

0 Uploads

742 Posts

0 Threads

#7 10 years ago

Would it be helpful to get a Milkshape model of a stock ship from A1 and A2? THey would have the hierarchies that you need.

If your tool is primarily for Milkshape I don't think spending a lot of time on command nodes "c_" will matter as I don't thinkl Milklshape supported them anyways. I beleive MAX is needed for those.




Guest

I didn't make it!

0 XP

 
#8 10 years ago

The tool is only for milkshape unless there happens to be a milkshape 3d ascii text importer for MAX. Unless you bring the file into milkshape, then save it to a format the MAX can import that support joints.

I looked at that Modding book quickly and with how the MAX hardpointing is done, I am doubtful that such a process would be worthwhile. I've been told hardpointing is alot better to do in MAX than Milkshape to begin with, but I only use milkshape.

Dejavu sent me some joint trees from A, A2 and Fleetops. They will be helpful once I write up the Joint Import Code, but it's not been done yet. That probably won't be for a couple weeks as I'm finishing up the XI pack for Legacy first.




Guest

I didn't make it!

0 XP

 
#9 10 years ago

Well I figured and update was due.

I have finally gotten to implement the ability to import existing joint trees into the tool from milkshape. With the examples that Dejavu sent I don't see the need for any serious modifications to the utility for use with the Armada series.

I don't yet have a list of valid emitters (e_) or sprite (s_) joints to populate those dropdown boxes, but beyond that it shouldn't take much. The Armada version would also be a stand alone tool without the other interfaces that the LMTools include as they are Legacy only functions generally. Basically I'm not building the Armada Tool into a Legacy Modding Utility, I doubt that would be found helpful by you guys (and gals) or vice versa.

I figure it's best to not create a branched off copy until I'm sure it's in good operating order, or I will have an awful mess updating both versions as I fix things. So it will still be awhile until I get to this as I know the tool needs a fair bit of work yet. If anyone wanted to use the existing version for Armada I don't see any reason it wouldn't work for you, it just won't be quite as convenient as an Armada version of the tool. I haven't released the version that imported existing joints yet though, as it's still in testing.




Guest

I didn't make it!

0 XP

 
#10 10 years ago

This should help

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. color { 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. color ambient Real time lighting ambient component color diffuse Real time lighting diffue component color 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. 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 Type specific data field as defined below. } Null Nodes ========== TYPE_SPECIFIC_DATA { 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 { No addtional 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 { 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 { IDENTIFIER Emitter used by this node as defined by an @emitter description in the .spr files. } Polygon Mesh Nodes ================== TYPE_SPECIFIC_DATA { 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) VECTOR3 ARRAY vertex positions (nvertices entries) VECTOR2 ARRAY texture coordinates (ntexcoords entries) VERTEX_LIGHTING_GROUP ARRAY (ngroups entries) UINT8 cull type (0 - no cull, 1- (backface cull) UINT16 0 - unused must be 0. } VERTEX_LIGHTING_GROUP { UINT16 num_faces (all faces are triangles) IDENTIFIER lighting_material (0=default) FACE ARRAY (num_faces entries) } FACE_VERTEX { UINT16 index into mesh vertex positions array UINT16 index into mesh texture coordinate array } FACE { FACE_VERTEX ARRAY(3) 3 entries describing a triangular face. } Section 4 : Animation Channels (Defines transform animation) ============================================================ UINT16 count // Number of animation channels 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'. } Section 5 : Animation References (Defines texture animation) ============================================================ 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. UINT16 num_animation_references ANIMATION_REFERENCE ARRAY(num_animation_references) 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.

and this

Command Nodes: Command nodes are special nodes the modify the export behavior of their parent mesh. The are any node whose name begins "c_". Specifically, they are: "c_tm_[name]" Use the texture material [name]. "c_anim_[identifier]_[playback_offset]_nn" Texture animation. "c_borg_[texture]" specify a borg assimilation texture for the parent node.