3ds Max SOD Import/Export Script -1 reply

Please wait...

RMcC

A plain, simple tailor

50 XP

23rd January 2009

0 Uploads

10 Posts

0 Threads

#1 10 years ago

Hey A2 modders!

I've been lurking around these parts for a long while. I recently decided to dust off my copy of A2 and set about tooling around under the hood. I've messed around with the MilkShape workflow (recompiling the Assimsoft Importer and Exporter from the ground up), but I find MilkShape to be really limiting.

Because the SOD reference doc appears to exist, and since Assimsoft was awesome enough to release the source code for their MilkShape plugins, I thought I'd take a crack at writing an SOD import/export MaxScript that could run in any (well, any recent) version of 3ds Max.

Would anyone be interested in such an animal, or is everyone pretty much happy using MilkShape? Or does something like this already exist that I haven't seen?

Cheers!




Achilles

I stole fire from the lighter!

50 XP

13th January 2003

0 Uploads

1,596 Posts

0 Threads

#2 10 years ago

I'd give you my first born child for a working exporter for max 8/9... not some child I preoduce specifically either... a real keeper I mean.




Fireball_VI

I follow teh Moo!

50 XP

6th June 2008

0 Uploads

626 Posts

0 Threads

#3 10 years ago

I definatley wouldnt mind this...i've been using old max 5 since the beginning of time...this would be great....for many many reasons... I too suggest we all donate our children to this man...:p




Icewolf132

Only Slightly Insane

50 XP

1st June 2007

0 Uploads

182 Posts

0 Threads

#4 10 years ago

Even though I don't use 3DS Max myself (This one has been meaning to learn how to use it, but never really got around to it o.0), but...pweeeeeeease! Don't make me set the Puppy Eyes to stun!




RMcC

A plain, simple tailor

50 XP

23rd January 2009

0 Uploads

10 Posts

0 Threads

#5 10 years ago

I guess there's an interest in it, then. :) I thought there might be.

I started working on it tonight anyway after running into far more troubles than I cared to with Maya -> FBX -> MilkShape -> SOD conversions :banghead: It will probably take me a few days of back and forth troubleshooting to get it anywhere near presentable. I've built myself a little Miranda model to use as a reference.

Some general thoughts/goals from where I am right now:

  • Hard points/nodes will be any kind of helper object, rather than joints/bones. Joints/bones never made sense to me for this sort of thing; there's no skinning involved. Point helpers are particularly usefule for their position and color-coding.
  • The nodes will more or less follow the MilkShape naming conventions, with the omission of the prefix (i.e. no more h_hp01). The script will be smart enough to figure out what kind of node it's dealing with based on hierarchy.
  • Scenes should be modeled at real scale (i.e. if your ship is 243 meters long, you should model it to be that long in Max). The script will handle reducing it to Armada-proper scale at export time.

More updates as I have them. :)




Guest

I didn't make it!

0 XP

 
#6 10 years ago

What SOD info do you need? I think I've got about everything that the internet has. I was trying to find some one to update the Milkshape importer/exporter to improve the functionality closer to the old 3dsmax one but I will gladly help anyone looking to update the 3dsmax one.




Amateur

beginner on armada2files

50 XP

23rd April 2005

0 Uploads

398 Posts

0 Threads

#7 10 years ago

I completely agree with Achilles... :nodding: Max 8 is so much better than Milkshape for modelling. It'd be great to stop using that old thing once and for all. Good luck!




RMcC

A plain, simple tailor

50 XP

23rd January 2009

0 Uploads

10 Posts

0 Threads

#8 10 years ago
starfox1701;4783806What SOD info do you need? I think I've got about everything that the internet has. I was trying to find some one to update the Milkshape importer/exporter to improve the functionality closer to the old 3dsmax one but I will gladly help anyone looking to update the 3dsmax one.

At the moment, I think I'm all set. I have Chris Graham's SOD reference document, the C++ source code for the MilkShape plugins that I can use as reference, and a Binary/Hex reader to look at existing SODs for structure data. Assuming both the reference doc and the C++ code are correct, it's just a matter of slogging through and writing the script that outputs the binary values of the model in the proper format. Right now, I anticipate an importer being more difficult than an exporter, but that may not end up being the case at all. I'll still make both. One just may come sooner than the other. We'll see!

I spent most of last night converting my Miranda FBX from Maya into something a little more Max-friendly, largely following the conventions I laid out in my previous post with respect to Point Helpers over Bones. I'll probably end up including a number of support scripts, too, depending on how the process goes.

I should have a good chunk of time to work on this tonight. Depends on whether or not the Significant Other wants to work on her own projects, or if she wants to do something together. You are all at her mercy. ;)

As an aside, I'm glad to see a gamut of different Max versions in use out there. That will make testing version differences a little easier. I'm writing for Max 2008, but I don't think I'll need to use anything that wasn't in Max 9. Max 8 is a bigger question mark, since Autodesk typically changes the SDK every odd version. It'll be good to see if that has an impact. I don't think it will, but y'never know...

For those familiar with the "old" Max plugin (which I've seen, but never used), this will not be a Max plug-in -- it will be a script, with all that that implies. You'll be able to edit the script yourselves if you're dissatisfied with how it works/looks (even if I require that people ask permission to change it, I can't really enforce that ;)), and it will be slower than a compiled plug-in. The upshot is that it should scale across different versions of Max, whereas plug-ins do not.




pepperman

Cloaked in the Neutral Zone

50 XP

5th February 2004

0 Uploads

742 Posts

0 Threads

#9 10 years ago

As you work on it, I would encourage you to consider both version of Armada as I know A1 folks would be intertested as well. Steve William's SOD file format is provided below as well. Also, keep in mind as you look at the Graham's source code that the Milkshape exporter could not handle animations due to limitation of the Milkshape software. 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.




RMcC

A plain, simple tailor

50 XP

23rd January 2009

0 Uploads

10 Posts

0 Threads

#10 10 years ago
pepperman;4784164As you work on it, I would encourege you to consider both version of Armada as I know A1 folks would be intertested as well.

Absolutely. The MilkShape C++ code calls out all the differences between the A1 and A2 formats (A1 is basically simpler). My first effort is going to be focusing on getting a functional A2 export, then an A2 import. From there, I'll wrap a GUI around it and then add support for A1. That's the general plan, anyway. :)

Also, keep in mind as you look at the Graham's source code that the Milkshape exporter could not handle animations due to limitation of the Milkshape software.

Yeah, animations are what worry me the most, since I don't have any basis of comparison for implementation method. Tack on "Add Animation Support" to the end of my above plan. ;)