JMS File format questions

[SGWraith]

I've spent sometime looking at the script source file for TheGhost's JMS Exporter with some of CtrlAltDestroy's modifications and I think I got most of the JMS file format figured out but I still had some questions if anyone was willing to share their knowledge about it.

----------------------------------------------------------------
Here is the beginning of the JMS file including the node information.

8200 (? This bit is hard coded. Whats it for? If no one knows thats fine.)
3251 (A checksum. New versions allow this to be changed, was previously hard coded.)
1 (Total node count)
frame (A node name)
-1 (Index of node's first child)
-1 (Index of node's next sibling)
0.0 0.0 0.0 1.0 (Node rotation: XYZ W(?) - Whats that last digit for?)
2000.0 0.0 0.0 (Node Translation XYZ)


For this example JMS file I made a simple box and linked it to a frame. I presume that frame is the only node unless you are exporting a biped/vehicle/weapon? I'll come back to this later but I know that TheGhost's plugin sorts these but I've only ever worked with map geometry so I'm not sure what that part of the code does. I also noticed there are four node rotation numbers - xyzw - and I don't know what the w represents. Also, would I be correct in assuming that if a node index is -1, that means it is undefined?

BlueStreak JMS Exporter code that outputs the above shown below:

format "%\t%\t%\t" 8200 checksum node_count to:jms
for n = 1 to node_count do
(
format "%\t" node_array[n].name to:jms
format "%\t" (node_first_child_index[n] - 1) to:jms
format "%\t" (node_next_sibling_index[n] - 1) to:jms
format "%\t%\t%\t%\t" node_rotation[n].x node_rotation[n].y node_rotation[n].z node_rotation[n].w to:jms
format "%\t%\t%\n" node_translation[n].x node_translation[n].y node_translation[n].z to:jms
)

----------------------------------------------------------------
The next portion of the JMS covers the materials, markers, and regions.

2 (Material count)
example_tutorial_ground (A material name)
<none> (? - Hard coded)
+sky (Another material)
<none> (? - Hard coded)
0 (Marker count)
1 (Region count)
unnamed (? A region Name)


What are the <none> for? Every material gets one it seems but since its hard coded I presume this will never need to change. I'm also curious how it orders the materials because it seems to have ordered them from last to first since +sky was material 1.

BlueStreak JMS Exporter code that outputs the above shown below:

mat_count = geom_materials.count
format "%\t" mat_count to:jms
for m = 1 to mat_count do
(
format "%\t%\n" geom_materials[m].name "<none>" to:jms
)

marker_count = marker_array.count
format "%\t" marker_count to:jms
for m = 1 to marker_count do
(
format "%\t-1\t" (substring marker_array[m].name 2 -1) to:jms -- -1 = regions not supported for marker instances
format "%\t" (marker_parent_index[m] - 1) to:jms
format "%\t%\t%\t%\t" marker_rotation[m].x marker_rotation[m].y marker_rotation[m].z marker_rotation[m].w to:jms
format "%\t%\t%\t" marker_translation[m].x marker_translation[m].y marker_translation[m].z to:jms
format "%\n" marker_radius[m] to:jms
)

region_count = geom_regions.count
format "%\t" region_count to:jms
for r = 1 to region_count do
(
format "%\n" geom_regions[r] to:jms
)


I assume that whatever geom_regions[] contains are region names?

----------------------------------------------------------------
The next portion is for vertices, of which I only show one.

36 (Number of Verts)
0 (? - Comes from vert_node0index)
-990.0 1000.0 0.0 (Vert XYZ Position)
0.0 0.0 1.0 (Vert XYZ Normal)
-1 (? - Comes from vert_node1index)
0 (Vert Node1 weight)
0.0 (Tvert Pos X)
0.0 (Tvert Pos Y)
0 (?)


I looked up tverts and so I know what they are but I'm curious why there is a hard coded zero after the y coordinate instead of a tvert_pos[v].z in there.

BlueStreak JMS Exporter code that outputs the above shown below:

for v = 1 to numVerts do
(
format "%\t" vert_node0index[v] to:jms
format "%\t%\t%\t" vert_pos[v].x vert_pos[v].y vert_pos[v].z to:jms
format "%\t%\t%\t" vert_normal[v].x vert_normal[v].y vert_normal[v].z to:jms
format "%\t" vert_node1index[v] to:jms
format "%\t" vert_node1weight[v] to:jms
format "%\t" tvert_pos[v].x to:jms
format "%\t0\n" tvert_pos[v].y to:jms
)


----------------------------------------------------------------
And the last portion of the JMS which deals with faces, of which I show only the first 2

12 (Number of Faces)
0 (Face Region Index)
0 (Face Shader Index)
0 1 2 [c (c+1) (c+2)]
0
0
3 4 5

My only question here is what the incrementing numbers are for. Since the halo engine expects all faces to be triangles I am guessing these are numbered edges?

BlueStreak JMS Exporter code that outputs the above shown below:

format "%\t" numFaces to:jms

c = 0
for n = 1 to numFaces do
(
format "%\t" face_region_index[n] to:jms
format "%\t" face_shader_index[n] to:jms
format "%\t%\t%\n" c (c+1) (c+2) to:jms
c += 3
)


If it looks like I've mislabeled any of the parts, please let me know.

[klange]

Back when I was just a wee scrub, I came up with the following and had exported an entire map from my own application and got it all in-game (sans lightmaps, which failed to render; note that all the "hard-coded"s came from Chimp, as it was all written before TheGhost graced us with his BlueStreak):


'8200 -> absolutely no idea, but this
'3251 -> And quite a lot below it
'1 -> is all hard coded, so we'll keep it that way!
'Frame
'-1
'-1
'0.000000 0.000000 0.000000 1.000000 -> origin? And what's with the one....
'64.0 128.0 72.0 -> Actual frame location
'1 -> NUMBER OF TEXURES
'TEXTUREGOESHERETH -> Name of Texture
'<none> -> Hard Coded
'HERESANOTHERTEXTURE
'<none>
'0 -> Hard Coded
'1 -> Hard Coded
'unnamed -> Hard Coded
'3 -> I think this is number of vertecies...
'0 -> Hard Coded
'-3.0 9.0 5.0 -> ahh.. vertex numero uno!
'0.0 0.0 1.0 -> normals
'-1 -> No idea...
'0 -> More with normals? or could this have to do with UVing?
'0.0 -> U
'0.0 -> V
'0 -> Hard Coded
'------- NEXT VERTEX
'0 -> Hard Coded
'-3.0 -1.0 5.0 -> Vertex 2
'0.0 0.0 1.0
'-1 -> Hard Coded
'0 -> Hard Coded
'0.0 -> U
'0.0 -> V
'0 -> Hard Coded
'------- NEXT VERTEX
'0 -> Hard Coded
'9.0 9.0 5.0 -> Vertex 3
'0.0 0.0 1.0
'-1 -> Hard Coded
'0 -> Hard Coded
'0.0 -> U
'0.0 -> V
'0 -> Hard Coded
'1 -> ChimpFaces.count
'0 -> Hard Coded
'0 -> ChimpFaceIDs AKA the texture reference ?
'0 1 2 -> EDIT: Vertices that make up the face : )

[CtrlAltDestroy]

-version number (8200)
-node checksum (calculated by blitzkrieg, relatively useless)
-node count
--node name
--first child index (next node this node as its parent)
--next sibling index (next node with same parent as this one)
--rotation (quaternion: -i, -j, -k, w; basically take the inverse for the node's true rotation)
--translation (point3: x, y, z)
-material count
--material name
--material path (useless, other than to help tool locate shaders when you compile the jms)
-marker count
--marker name
--magic identifier (this is the only value i have trouble attributing a purpose for; just write 0)
--parent index
--rotation (quaternion: -i, -j, -k, w; as with nodes, take the inverse to get the true rotation)
--translation (point3: x, y, z)
--radius (used for physics models)
-region count
--region name
-vertex count
--node 0 index
--position (point3: x, y, z)
--normal (point3: x, y, z)
--node 1 index
--node 1 weight
--texture coordinates (point3: x, y, z; z is always 0)
-face count
--region index
--material index
--vertex indices (point3: v0, v1, v2)

all rotations and translations are parent-relative

[SGWraith]

I remember quaternion's now, guess I'll have some more reading to do.

Regarding the magic identifier, I've only heard of magic in relation to scripting but otherwise I don't have any clue why its there either. Perhaps its related to the ai deafening property, "&" which has no use for multiplayer maps, or for purposes of controlling ai magic awareness? Seems kinda useless though.

For the vertices, what are node 0 index and node 1 index for? For my example JMS with just map geometry those values never deviated from 0 and -1 respectively. However, if you're working with weapons, bipeds, or vehicles instead of map geometry are those likely to change or are they similarly "always" going to be 0 and -1?

Thanks for the input guys, much appreciated.

[Maniac]

http://www.caligari.com/
This here looks nice.

[SGWraith]

Looks interesting as a good all-around program. It supports Python for scripting so I'll take a look at it some time if there is anyone who actually uses it here.

[Maniac]

Yea, its free, has no restrictions and is a lot more powerful than Gmax and some other free programs. Without an exporter its useless though.
Has polydraw :)

[SGWraith]

I was intrigued by its claim of realtime feedback or something or other due to its use of dx9 display drivers inside the program. What is polydraw?

[Maniac]

A very efficient way of creating or cutting or adding ring loops,polys and such.
Polyboost for max has these tools and lots of users find them very useful.
There are some tuts on that site that show you some of its advantages.
I like that the opacity slider is handy too.

[SGWraith]

There are a lot of good programs out there, though it is hard to figure out what features they all have in common or which make them unique.