[WIP] .render_model exporter (First custom model ingame!)

[jahrain]

Ok well its been REALLY hard work considering I can't edit or even open these tags, figuring out the tag structure mostly in nothing but hex. But finally i got my exporter to get a model that will load and not crash sapien or fail to read it. I know its a bit early, but I want to keep everyone posted on this. Right now, my approach is to make a .gbxmodel -> .render_model exporter to save myself allot of work as the 2 formats are similar, and I can easily get nodes, markers, etc. But I may create a direct exporter/ model compiler from a source format like .JMS sooner or later.

I still have LOTs of bugs to work out, but I finally got something that works and loads ingame.

http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2602-36-14-21.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2602-37-18-15.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2602-47-56-42.jpg
Props to anyone who can identify these 2 custom models of mine. Sorry that they currently look so ugly ingame. :P
Right now I just have it attached to a scenery model. I still have to sort out the ordering of indices strips, which is why the polygons and texture coords look garbled. Took me quite a bit of time to figure it out with the lightmap geometry model data.

I plan on adding an option to edit the tag data before exporting such as what shaders to use, what sections belong to which LOD, marker tweaking, etc... Or maybe someone might find it in their hearts to be kind enough to release a patch for guerrilla to unlock some of the tag editing restrictions. Until then, I'm going to continue to find small work arounds for users to getting custom content ingame. After I complete this and get it polished off, I'm going to attack the collision tags next. As of now, these just have box based collision.

I'l be sure to keep you all posted!



UPDATE!!!!
Fixed some stuff! See post #52 for details
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2621-33-32-59.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2621-34-15-12.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2702-18-38-88.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2703-53-19-72.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2703-54-35-19.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2703-28-54-84.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2703-28-59-57.jpg

[Choking Victim]

Amazing work, i know the first ones your custom spartan but im not sure what the other is.

Edit: are vertex weights also being injected?

[Love De Lux]

First model : your H3CE biped
Second Model : Joanna Dark for this mod (http://www.pdark-mod.com/)

Congrats with this exporter !

[DaneO'Roo]

yet another thing I love you for :P

Fucking awesome work. This community and its current situation would be fucked without this. So many mods and projects have been given a shred of hope. Thanks for the hard work, Jah :D

[jahrain]

Amazing work, i know the first ones your custom spartan but im not sure what the other is.

Edit: are vertex weights also being injected?
Node weights are also going to be supported. That won't be much of a challenge compared to some other things. But only just a maximum of 2 weights per vertex as .gbxmodel only supports 2 when .render_model supports 4. When I create my own model exporter pluggin, I will have it support 4 node weights

About everything that is supported with .gbxmodel is planned to be supported in the .render_model with my exported when completed.

[Limited]

Woah, great work jahrain :)

[jahrain]

First model : your H3CE biped
Second Model : Joanna Dark for this mod (http://www.pdark-mod.com/)

Congrats with this exporter !
1) correct.
2) Close!!! but WRONG! :P
I did however, model some of the pd source's bipeds.

[DaneO'Roo]

^ whoa i didnt know that o_O


Dam 3d whores :(

[FireScythe]

Very nice work! The first is obviously your spartan biped from Prime, and i think the second is the woman you modelled in this thread (http://gbxforums.gearboxsoftware.com/showthread.php?t=46841) but i don't think the pictures work anymore so i can't be sure:p.

Just had a quick look at the render_model tag and it seems they used a varient of the JMS format in Halo 2 so maybe an altered version of bluestreak would give you the information to compile, rather than the gbxmodel - render_model route.

[Roostervier]

Hey, some progress! Nice job jahrain!

[jahrain]

Very nice work! The first is obviously your spartan biped from Prime, and i think the second is the woman you modelled in this thread (http://gbxforums.gearboxsoftware.com/showthread.php?t=46841) but i don't think the pictures work anymore so i can't be sure:p.DING DING DING! We have a winrar! Congrats! Here take this cake, you will need it.
http://www.myhomecooking.net/german-chocolate-cake/images/chocolate-cake-with-slice-out-of-it.jpg


Just had a quick look at the render_model tag and it seems they used a varient of the JMS format in Halo 2 so maybe an altered version of bluestreak would give you the information to compile, rather than the gbxmodel - render_model route.

Actually, I was planning on using .jms at first. An altered version of bluestreak would only need to export 4 node weights instead of 2. My only problem is just computing what the binormals and tangents are and also figuring out how to convert node and marker relative positioning and converting from 3d euler angles to 4d quaternion vectors. Its just bound for trouble and problems, so making a .gbxmodel -> .render_model just makes things simpler as it already compiled all that information.

[Roostervier]

... Sounds about like it =p. That looks hard to understand, at least for someone as slow as me D:

[Snaver]

Great start jahrain.

[teh lag]

That's awesome, you are awesome too.

[FireScythe]

Hooray Cake!:D I've had a look at Euler > Quarternion calulations and its not too hard, i've made a quick code that does it. Binormals and tangents look to be quite complex though (or at least the terminology is :p).

[jahrain]

Hooray Cake!:D I've had a look at Euler > Quarternion calulations and its not too hard, i've made a quick code that does it. Binormals and tangents look to be quite complex though (or at least the terminology is :p).I made some old vb code that does it as well long ago, but from quaternion to euler, not euler to quaternion. The problem is the angles are relative to each other. So say you have one node pointing one particular angle, and another node attached to it pointing in another angle that is relative to the first node node's angle. What you would have to do is figure out what the angle is in the world from the relative angles and convert that to a quaternion. Just figuring out relative 3d angles and transformations is mind boggling.

[FireScythe]

Ah i see, bit more complex than expected :p.

[jahrain]

Well, I could do it, but why bother when theres a simpler solution that would work better?

Also, another issues is triangle stripping.

I realized that the index data consists of triangle strips, not just triangles as I have assumed which is why the polygons look so garbled. In the gbxmodels, the triangles seem to be in triangle strip format as well since it can be seen with the intentional degenerate triangles in the tags. Usually with triangle strips, a degenerate triangle, usually contains 2 of the same vertex coords indicies. You will see many of those in the gbxmodel tags's triangle block, which is why I assume it also uses triangle strips.

Converting a model into a series of triangle strips is definitely something that seems challenging as it involves some graph theory.

[thehoodedsmack]

Yay! Another reason to get this game! Jahrain FTW!

[bitterbanana]

Yikes, graph theory? I thought vertices were already grouped in 3's. If they aren't, I'd just group them by proximity, not graph theory!! Anyway, this isn't my field, good luck to you Jahrain with finishing this. Seems liike a fun project.

[SuperSunny]

Good work Jahrain! I wish you luck in further development!

[TheGhost]

Just had a quick look at the render_model tag and it seems they used a varient of the JMS format in Halo 2 so maybe an altered version of bluestreak would give you the information to compile, rather than the gbxmodel - render_model route.

The JMS format for Halo 2 is almost exactly the same as Halo 1 JMS. So, you can expect a BlueStreak exporter in the near future.

[Kornman00]

I cannot be held responsible for my actions :-3

man, can't a gangsta (http://www.tomorrowsnobody.com/toons/cantagangsta.html) post a pic when hes finally got somewhere in this white white world...and yet those pics are with black bipeds :|

honkies

[Masterz1337]

Thank you jahrain and friends :)

[TheGhost]

Also, another issues is triangle stripping.

I realized that the index data consists of triangle strips, not just triangles as I have assumed which is why the polygons look so garbled. In the gbxmodels, the triangles seem to be in triangle strip format as well since it can be seen with the intentional degenerate triangles in the tags. Usually with triangle strips, a degenerate triangle, usually contains 2 of the same vertex coords indicies. You will see many of those in the gbxmodel tags's triangle block, which is why I assume it also uses triangle strips.

Converting a model into a series of triangle strips is definitely something that seems challenging as it involves some graph theory.

Are you serious? That has nothing to do with anything.

The reason that you get degenerate triangles is because of the way the JMS was imported in Halo 1. The post-processing done in Tool created degens, which the game ignores. In Halo 2, the processing done by the exporter breaks down verts along smoothing groups so the compiler doesn't have to distinguish. Undoing the process in the gbxmodel tag isn't that hard. How else do you think I made a gbxmodel importer (http://ghost.halomaps.org/bluestreak/gbxmodel/)?



triangle_vertices = (geometry_part_triangle_blocks[g][p] * 3)
for t = 1 to triangle_vertices do
(
append vertex_order ((readShortB "#signed") + 1)
)

vo_count = vertex_order.count
if vertex_order[vo_count] == 0 do deleteItem vertex_order (vo_count)
if vertex_order[vo_count-1] == 0 do deleteItem vertex_order (vo_count-1)

for w = 1 to (vertex_order.count - 2) do
(
triangles[w] = [vertex_order[w],vertex_order[w+1],vertex_order[w+2]]
)

for r = 1 to triangles.count by 2 do
(
a = triangles[r][1]
triangles[r][1] = triangles[r][3]
triangles[r][3] = a
)

for d = triangles.count to 1 by -1 do
(
if (triangles[d][1] == triangles[d][2]) or (triangles[d][2] == triangles[d][3]) or (triangles[d][1] == triangles[d][3]) then
(
deleteItem triangles d
)
)


I'll translate that to English for you...

There are 4 for-loops, each has a purpose:


Read the vertex order from the tag
Create triangles from every 3 vertices
Reverse the vertex indices
Remove degenerate triangles

Voila, your model no longer looks like crap. :p

[SMASH]

^_^ Ghosty's awesome!

[JDMFSeanP]

I really don't know anything about this but could you guys talk to the halo 2 xbox boys that import new models and stuff for some tips? They have figured out how to do it.

[Kornman00]

Those xbox boyos are in a totally different mind set compared to a HEK vet like le ghost

[Con]

This is awesome Jahrain, one step closer to the original HEK now ;)

[Elite Killa]

The North Star has shown us to Bethlehem! Nice work!

[jahrain]

Are you serious? That has nothing to do with anything.

The reason that you get degenerate triangles is because of the way the JMS was imported in Halo 1. The post-processing done in Tool created degens, which the game ignores. In Halo 2, the processing done by the exporter breaks down verts along smoothing groups so the compiler doesn't have to distinguish. Undoing the process in the gbxmodel tag isn't that hard. How else do you think I made a gbxmodel importer (http://ghost.halomaps.org/bluestreak/gbxmodel/)?

I know the degenerate triangles get ignored, its how and why the tool creates them in post processing I need to figure out. The reason I assumed they were created for triangle stripping is because if you read up on this (http://en.wikipedia.org/wiki/Triangle_strip) you will find out that in triangle stripping, the degen triangles that the game ignores are created to be used to jump around the model to start and end strips of triangles. Undoing the process is not something I have to do, its the process that I have to do, not undo.




triangle_vertices = (geometry_part_triangle_blocks[g][p] * 3)
for t = 1 to triangle_vertices do
(
append vertex_order ((readShortB "#signed") + 1)
)

vo_count = vertex_order.count
if vertex_order[vo_count] == 0 do deleteItem vertex_order (vo_count)
if vertex_order[vo_count-1] == 0 do deleteItem vertex_order (vo_count-1)

for w = 1 to (vertex_order.count - 2) do
(
triangles[w] = [vertex_order[w],vertex_order[w+1],vertex_order[w+2]]
)

for r = 1 to triangles.count by 2 do
(
a = triangles[r][1]
triangles[r][1] = triangles[r][3]
triangles[r][3] = a
)

for d = triangles.count to 1 by -1 do
(
if (triangles[d][1] == triangles[d][2]) or (triangles[d][2] == triangles[d][3]) or (triangles[d][1] == triangles[d][3]) then
(
deleteItem triangles d
)
)
I'll translate that to English for you...

There are 4 for-loops, each has a purpose:
Read the vertex order from the tag
Create triangles from every 3 vertices
Reverse the vertex indices
Remove degenerate trianglesVoila, your model no longer looks like crap. :p
That code is very similar to what I had to do to extract the lightmap BSP model data from halo 2. Thanks.

[the1]

... just out of curiosity but wouldn't it be easier to create a app or program that compiles *.ass files??? cause as far as i am awear the new *.jms format and the *.ass format are identicle...
*.ass exports Markers, Frames and im pritty sure physics otherwise it would be impossible for sapien to build a havoc representation for things like the level unless it wasn't incorporated into the *.ass file and just uses the level model for the havoc physics with the way everything interacts with the level. but knowing me i could be waay off and the havoc physics files were exported seperately in there own jms file or something. clarity is my friend but its nearly impossible with everything locked and no jms exporter to compare the same model exported in jms format and ass format

[jahrain]

I don't think .ass does node weights afaik. As far as the .render_models, bungie used a .jms format. The tags contain logs of the .jms files that were compiled which is why I'm pretty sure.

Edit: nvm, actually, it does do weights. I don't really know whats the difference between the .ass and what ever .jms format bungie used.

[CtrlAltDestroy]

They just changed the extension to mock us, IMO. :eyesroll:

[Kirby_422]

Right now, my approach is to make a .gbxmodel -> .render_model exporter to save myself allot of work as the 2 formats are similar
could you also do a H2 to H1 after?

[CtrlAltDestroy]

What would be the point of that?

If what you want is to convert Halo 2 models to Halo 1, you can already do that with conventional modding tools.

[TheGhost]

No, JMS and ASS are not the same.

Also, tool has code to re-compile JMS models.

[the1]

fair enough. but why bother using 2 different formats for models.
has bungie gon insane or crazy?... rofl its more work for everyone if nothing is shared. like collision geometry and physics spheres in ce.

[Kirby_422]

What would be the point of that?

If what you want is to convert Halo 2 models to Halo 1, you can already do that with conventional modding tools.
there is a H2V map editor that can do that already?

[CtrlAltDestroy]

No, Halo 2 Xbox.

[the1]

i have an idea. wouldn't it be easier to work in reverse?
say go back from a render model to a max model
then just reverse the process to make a render model export from max?
that and wouldn't it be more accurate because you know what its suppost to look like when importing. and you can work out how weights, reigons and permutations are worked out. then go back and do the opposit? call me crazy but i thought it would be alot easier to go back from something solid than to go forward from nothing to something when you arn't entirely sure how to go about it...

im pritty sure by the order that bluestreek was made that thats how TheGhost went about it...

[Kornman00]

There are quite a few differences b/w the ASS and JMS formats, they are not crazy

[TheGhost]

ASS is specifically for level design. It can do things like instance geometry. It also leaves a lot of stuff out that isn't needed for levels. I think it's a pretty decent idea.


im pritty sure by the order that bluestreek was made that thats how TheGhost went about it...

Exactly. I'd make a render_model importer before the exporter. It would get me familiar with the file format and be useful for something at the same time.

[jahrain]

I could make a .render_model exporter easily with what I already have mapped out. I just need to print out the vertex and index data to a .obj file as my application already stores that data in a couple of arrays. I had to as my program doesn't create a .render_model from scratch yet. It just opens up an existing one, and replaces all the geometry data. Btw, how do you guys know what the .jms files are like? No halo 2 jms file exporter was released that I know about...

[SuperSunny]

I could make a .render_model exporter easily with what I already have mapped out. I just need to print out the vertex and index data to a .obj file as my application already stores that data in a couple of arrays. I had to as my program doesn't create a .render_model from scratch yet. It just opens up an existing one, and replaces all the geometry data. Btw, how do you guys know what the .jms files are like? No halo 2 jms file exporter was released that I know about...

I believe they are relating Halo 1 JMS structure and Halo 2 ASS structure (or the .render_model compilation, which I think is not .ass originally but a JMS file compiled much like a .gbxmodel or a .model)

[the1]

Exactly. I'd make a render_model importer before the exporter. It would get me familiar with the file format and be useful for something at the same time.

Logic wins again...
wish i knew enough about max script to make my own exporters for things...
but i guess im better off learning a real programming language before i try anything with max script.

[TheGhost]

Btw, how do you guys know what the .jms files are like? No halo 2 jms file exporter was released that I know about...


I believe they are relating Halo 1 JMS structure and Halo 2 ASS structure (or the .render_model compilation, which I think is not .ass originally but a JMS file compiled much like a .gbxmodel or a .model)

No, there is JMS data in the EK if you look hard enough...

[jahrain]

No, there is JMS data in the EK if you look hard enough...
Where might I find this? In the .render_model tags, I can see logs of the .jms imports. But thats about it. Care to start sharing some information?:)

[ejburke]

I've looked at the ASS file spec and as far as I can tell, it's robust enough to support non-BSP models. It supports object hierarchy, so joints shouldn't be a problem. And vertices have weight and influence parameters. What is it missing?

[Nick]

Where might I find this? In the .render_model tags, I can see logs of the .jms imports. But thats about it. Care to start sharing some information?:)
Care to start looking harder? It's really not that hard to find.

Nick

[the1]

rofl. anyone want to give any hints away publically or privately about the ek and how to start hacking it?
i hit a dead end when i couldn't alter data...
and i don't think its the right data to change anyway... and im not sure if its just straight hex or if its dissassembly. or decompileing (any hints with a decent decompiler appreciated too btw if thats the problem)

[jahrain]

UPDATE!!!!
Great news! I finished mapping out the .gbxmodel tags and finished writting import classes for them and I have confirmed my assumptions about the .gbxmodel tags and the similarities with the .render_model tags. I was able to pass though the data 100% un-processed to the .render_model tag and it works perfectly in halo 2. Before I was using .jms files from h1ek and was getting the ugly garbled polygons, no matter how much I tried to pre-process the triangle data. Now with the .gbxmodels converted to .render_models, with no processing done what so ever, they look perfect!
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2621-33-32-59.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2621-34-15-12.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2702-18-38-88.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2703-53-19-72.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2703-54-35-19.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2703-28-54-84.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-06-2703-28-59-57.jpg
Normals, smoothing groups, texture coords, all with no problems.

The only slight issue I have ran into is certain models for some reason get imported with flipped triangle orientation. Its kinda rare, but is easily fixed by pre-flipping them before exporting them from max. I'l try figuring out what causes it. But now I can start work on markers, nodes, shaders and multiple permutation/LODs support so that I can release a beta.

I'l also be looking into h2 .jms support once I find out more about it. Still can't find any h2 .jms models included with the h2ek...


Care to start looking harder? It's really not that hard to find.

NickYeah, like you would know. Thanks for the not help.

[DaneO'Roo]

:win:


also, if your intending to put the bulldog ingame, make normal maps for it D:

[Limited]

ah right, so right n ow you are editing previous gbxmodel tags that that render tag thingy? Have you tried to make a new one or dont you have the capable guerilla?

[Chronos]

Awesome.
Very nice Jahrain!!

[Skyline]

Sweet. The visor on that biped looks like the polygons are all messed there.

[SgtBotley]

i might actually buy Halo 2 Vista now - you legend

[klange]

When can we expect some pics of the Bulldog with proper textures?

[Roostervier]

When can we expect some pics of the Bulldog with proper textures?
Not until he gets an unlocked EK.

[TheGhost]

I was able to pass though the data 100% un-processed to the .render_model tag and it works perfectly in halo 2. Before I was using .jms files from h1ek and was getting the ugly garbled polygons, no matter how much I tried to pre-process the triangle data.

lol

[Nick]

lol
We've found the definition of hack and guesswork, all in one place :D

Still though, I do have to say good job jahrain; regardless of elegance, you did make it work and that puts you in the 90th percentile.

Nick

[TheGhost]

No, I just find it amusing that he only recently realized that it would require no post-processing? I thought that was your entire plan in going from gbxmodel --> render_model, because you couldn't calculate binormals, tangents, centroids, etc. All of a sudden you're saying something about JMS and that leading to your scrambled bipeds...? I smell a cover-up.

[SuperSunny]

No, I just find it amusing that he only recently realized that it would require no post-processing? I thought that was your entire plan in going from gbxmodel --> render_model, because you couldn't calculate binormals, tangents, centroids, etc. All of a sudden you're saying something about JMS and that leading to your scrambled bipeds...? I smell a cover-up.

Let it go. There is no sense in stretching it. He accomplished what he needed to do.

[jahrain]

No, I just find it amusing that he only recently realized that it would require no post-processing? I thought that was your entire plan in going from gbxmodel --> render_model, because you couldn't calculate binormals, tangents, centroids, etc. All of a sudden you're saying something about JMS and that leading to your scrambled bipeds...? I smell a cover-up.
Yes it was my plan but as I mensioned, but it was all under heavy assumption that I could do it without having to process the vertex and triangle data. I have only recently confirmed that my assumption was correct. Those first couple pics I posted was from just directly from a modified h1 .jms file that had nothing but vertecies and the indices in it due to me not completely mapping out the .gbxmodel structure yet. I realized the reasons it was scrambled is because it did require those degens as I mentioned earlier which where created by post processing with tool.

Theres no cover up, I'm trying to be honest and open about this, I don't know why you would think otherwise. I'm trying to explain what all I did and how I did it so that I could get better feedback, and perhaps someone might do a better job at it than I can instead of what, say what some others would do which would be just show off pics and keep all the information of how to do it to himself for the purpose of fame and glory.

[TheGhost]

If you hadn't mapped out the gbxmodel tag yet you could have asked me. Obviously I know the format very well as I've had to parse every byte of it and know what it corresponded to.

[jahrain]

If you hadn't mapped out the gbxmodel tag yet you could have asked me. Obviously I know the format very well as I've had to parse every byte of it and know what it corresponded to.
Well, I wasn't sure you or anyone else would be willing to help me. Besides, I like the fun of mapping out a model file structure. But maybe you could help by correcting any mistakes I might have made in this.

Key:
int16S: 16 bit integer byte swapped
float32S: 32 bit floating point byte swapped
longS: 32 bit long integer byte swapped
byte: 8 bit byte
string32: 32 byte length string
0x : relative offset in bytes


gbxModel struct
main size = 296
0x236 = markerCount longS
0x248 = nodeCount longS
0x260 = regionCount longS
0x272 = geometryCount longS
0x284 = shaderCount longS
markersBlock
size = 64
0x0 = nameString string32
0x32 = magicIdentifier int16S
0x52 = markerInstanceCount longS
markerInstanceBlock
size = 32
0x0 = regionIndex byte
0x1 = permutationIndex byte
0x2 = nodeIndex byte
0x4 = positionX float32S
0x8 = positionY float32S
0x12 = positionZ float32S
0x16 = rotationI float32S
0x20 = rotationJ float32S
0x24 = rotationK float32S
0x28 = ratationW float32S
nodeBlock
size = 156
0x0 nameString string32
0x32 = nextSiblingNodeIndex int16S
0x34 = firstChildNodeIndex int16S
0x36 = parentNodeIndex int16S
0x40 = positionX float32S
0x44 = positionY float32S
0x48 = positionZ float32S
0x52 = rotationI float32S
0x56 = rotationJ float32S
0x60 = rotationK float32S
0x64 = rotationW float32S
0x68 = nodeDistance float32S
regionBlock
size = 76
0x0 = nameString string32
0x64 = permutationCount longS
permutationsBlock
size = 88
0x0 = nameString string32
0x64 = superLowGeometryIndex int16S
0x66 = lowGeometryIndex int16S
0x68 = mediumGeometryIndex int16S
0x70 = highGeometryIndex int16S
0x72 = superHighGeometryIndex int16S
0x76 = markersCount longS
markersBlock
size = 80
0x0 = markerName string32
0x32 = nodeIndex int16S
0x36 = rotationI float32S
0x40 = rotationJ float32S
0x44 = rotationK float32S
0x48 = rotationW float32S
0x52 = positionX float32S
0x56 = positionY float32S
0x60 = positionZ float32S
geometriesBlock
size = 48
0x36 = partsCount longS
partsBlock
size = 132
0x4 = shaderIndex int16S
0x20 = centroidX float32S
0x24 = centroidY float32S
0x28 = centroidZ float32S
0x32 = vertexCount longS
0x44 = compressedVertexCount longS
0x56 = triangleCount longS

uncompressedVerteciesBlock
size = 68
0x0 = positionX float32S
0x4 = positionY float32S
0x8 = positionZ float32S
0x12 = normalI float32S
0x16 = normalJ float32S
0x20 = normalK float32S
0x24 = biNormalI float32S
0x28 = biNormalJ float32S
0x32 = biNormalk float32S
0x36 = tangentI float32S
0x40 = tangentJ float32S
0x44 = tangentK float32S
0x48 = texCoordX float32S
0x52 = texCoordY float32S
0x56 = node0Index int16S
0x58 = node1Index int16S
0x60 = node0weight float32S
0x64 = node1weight float32S

compressedVertexBlock
size = 32

triangleBlock
size = 6
0x0 = indexA int16S
0x2 = indexB int16S
0x4 = indexC int16S
shaderBlock
size = 32
0x10 = shaderTagRegSize
shaderTagRefsBlock

[TheGhost]

Post the render_model one as well for fun.

[jahrain]

Post the render_model one as well for fun.Oh its pretty ugly and not very legible yet. I'l post it once I clean it up and format it a bit.

[jahrain]

ZOMG UPDATE!!!11one

First of all, The project has been renamed to GBXModel Upgrader. Because that is precisely what it does. It will upgrade your .gbxmodel tags to h2's .render_model tags. Heres a screen shot of the current working GUI.

http://i193.photobucket.com/albums/z11/jahrain00/UIsample.jpg
It was quickly thrown together, and I may polish it off a bit before release. Still a few more geometry options I need to add in, such as the option to support compressed model, setting specific tag flags and such.

I fixed most of the geometry problems, except the flipping faces problem still has me befuddled. Right now my work around is to just set each shader to be double sided and the problem goes away. Until then, I have added the option to flip each face for each individual geometry part. Also shaders, markers and node blocks are now fully supported and transfer just about flawlessly. UVWs are all correct, vertex weighting is correct, (for bipeds), and so on.

Right now, the current build has the ability for you to create custom scenery, skyboxes crates, weapons, bipeds, vehicles etc that all use the same collision, animations and physics models of existing tags. I haven't fully tested all of these yet, since I'm limited with guerrilla atm but I'm quite certain that the upgraded models should work pretty flawlessly ingame.

compared with the original tag:
http://i193.photobucket.com/albums/z11/jahrain00/comparison2.jpg


And heres a model that went ingame smoothly with shaders and texture applied.
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-07-0615-21-03-58.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-07-0615-22-25-06.jpg
http://i193.photobucket.com/albums/z11/jahrain00/h2sapien2007-07-0615-21-21-25.jpg

Yes thats my sexy custom biped I modeled about a year ago. Its been a fine test subject. Right now, its just a piece of scenery however.

Still just a few things to polish up and a few bugs to fix before I make my first release.

[Skyline]

Oh shi. The best model I've seen in halo 2. :woot:

[thehoodedsmack]

Sweet Ever-loving Fark...

Congratulations, Jahrain. You have won The Internet.

[Ki11a_FTW]

:hyper:
BEUTIFLE


+ reputation

[Masterz1337]

Great job! Props to you and whoever helped you.

[korori]

WOW. I really cant wait for this. Great job.

[StankBacon]

very fucking nice jah, you are damn talented.

[p0lar_bear]

DAY-UMMMMMMMN!

This is a step in the right direction. Hope you can figure out the normals issue, simply out of performance concerns; wouldn't it take a bit more processing time to render a double-sided face? If so, is it negligible?

Again, bravo. It's accomplishments like this that make me put faith into this community. I just hope Microsoft doesn't get its panties in a wad and ban anyone who has a map with custom render_models. :/

[DaneO'Roo]

oh SNAP.


ftw

[Bodzilla]

that is awesome. keep up the great work bro

+imaginary rep (<3 the rep system)

[jahrain]

Thanks guys for the positive feedback.

DAY-UMMMMMMMN!

This is a step in the right direction. Hope you can figure out the normals issue, simply out of performance concerns; wouldn't it take a bit more processing time to render a double-sided face? If so, is it negligible? Well it does eat up more memory as the polygon count is doubled, but as far as performance wise, double sided faces really doesn't impact frame rates that noticeably since either way, the video hardware culls the back sides of the faces during render time.

I have added options to manually flip the individual geometry section parts as the flipped polygons are random but uniform for each different part. Basically, if you load your model into the game, and you notice a certain part of the geometry has flipped triangles, you can go back to the upgrader and set that piece of geometry to have it's faces flipped. A model is divided up into parts based on which shader they used and which LOD they belong to so finding which geometry needs to be flipped isn't hard. So the problem has 2 optional work arounds until I figure out what causes the flipping of the polygons. I want to get a usable beta out as soon as possible and I won't let this problem halt it's release forever if I can't figure it out.



Again, bravo. It's accomplishments like this that make me put faith into this community. I just hope Microsoft doesn't get its panties in a wad and ban anyone who has a map with custom render_models. :/Well they have banned people from halo 2 xbox with such mods, but I doubt theres seriously a way for live to detect if a custom map is using a custom model or not. We will see.


Also, I'm planning on making an obj exporter for .render_model tags for referencing models, nodes, markers etc. Also as i promised, for anyone else who wants to make a importing script for 3ds max, this might help.


render_model structure

main
size = 264
0x83 = nameStringSize byte
0x104 = compressionInfoBlockCount int32
0x116 = regionBlockCount int32
0x128 = sectionCount int32
0x140 = invalidSectionPairBitCount int32
0x152 = sectionGroupCount int32
0x176 = nodeCount int32
0x200 = markerCount int32
0x212 = shaderCount int32
nameString string(Size = nameStringSize)

ImportDataBlock
size = 596

CompressedJMSFilesBlock
size = 540
0x392 = CompressedJMSFilesBlockSize int32

ZippedJMSDataBlock(s)

compressionInfoBlock
size = 56
0x0 = positionBoundsMinX float32
0x4 = positionBoundsMaxX float32
0x8 = positionBoundsMinY float32
0x12 = positionBoundsMaxY float32
0x16 = positionBoundsMinZ float32
0x20 = positionBoundsMaxZ float32
0x24 = texCoordsBoundsMinX float32
0x28 = texCoordsBoundMaxX float32
0x32 = texCoordsBoundsMinY float32
0x36 = texCoordsBoundMaxY float32



regionsBlock
size = 20
0x3 regionNameStringLenght byte
0x8 = permutationCount int32

permutationBlock
size = 16
0x3 = permNameStringLenght byte
0x4 = L1SectionIndex int16
0x6 = L2SectionIndex int16
0x8 = L3SectionIndex int16
0x10 = L4SectionIndex int16
0x12 = L5SectionIndex int16
0x14 = L6SectionIndex int16
permNameString string(permNameStringLenght)

regionNameString string(regionNameStringLenght)

sectionBlock
size = 104
0x4 = totalVertexCount int16
0x6 = totalTriangleCount int16
0x8 = totalPartCount int16
0x10 = shadowTriangleCount int16
0x12 = shadowPartCount int16
0x14 opPointCount int16
0x16 = opVertexCount int16
0x18 = opPartCount int16
0x22 = shadowRigidTriangleCount int16
0x26 = compressFlags 8bitBinary

compressBoundsBlock
size = 56
0x0 = positionBoundsMinX float32
0x4 = positionBoundsMaxX float32
0x8 = positionBoundsMinY float32
0x12 = positionBoundsMaxY float32
0x16 = positionBoundsMinZ float32
0x20 = positionBoundsMaxZ float32
0x24 = texCoordsBoundsMinX float32
0x28 = texCoordsBoundMaxX float32
0x32 = texCoordsBoundsMinY float32
0x36 = texCoordsBoundMaxY float32

sectionDataBlock
size = 180
0x0 = partsBlockCount int32
0x36 = vertexBlockCount int32
0x48 = stripIndexcount int32
0x164 = nodeMapCount int32


partsBlock
size = 72
0x6 = stripIndexStartIndex int16
0x8 = stripIndexLenght int16
0x14 = maxNodesPerVertex int16
0x16 = centroidX float32
0x20 = centroidY float32
0x24 = centriodZ float32

rawVertexBlock
size = 196
0x0 = vertexX float32
0x4 = vertexY float32
0x8 = vertexZ float32
0x28 = node0Weight float32
0x32 = node1weight float32
0x36 = node2weight float32
0x40 = node3weight float32
0x44 = node0index int32
0x48 = node1index int32
0x52 = node2index int32
0x56 = node3index int32
0x68 = texCoordx float32
0x72 = texCoordy float32
0x76 = normalI float32
0x80 = normalJ float32
0x84 = normalk float32
0x88 = binormalI float32
0x92 = binormalJ float32
0x96 = binormalK float32
0x100 = tangentI float32
0x104 = tangentJ float32
0x108 = tangentk float32

stripIndexBlock
size = 2
0x0 = vertexIndex int16

nodeMapBlock
size = 1
0x0 = nodeIndex byte
sectionGroupBlock
size = 16

nodeBlock
size = 96
0x3 = nodeNameStringLength byte
0x4 = parentNodeIndex int16
0x6 = firstChildNodeIndex int16
0x8 = nextSibblingNodeIndex int16
0x10 = importNodeIndex int16
0x12 = translationX float32
0x16 = translationY float32
0x20 = translationZ float32
0x24 = rotationI float32
0x28 = rotationJ float32
0x32 = rotationK float32
0x36 = rotationW float32
0x40 = inverseForwardI float32
0x44 = inverseForwardK float32
0x48 = inverseForwardJ float32
0x52 = inverseLeftI float32
0x56 = inverseLeftJ float32
0x60 = inverseLeftK float32
0x64 = inverseUpI float32
0x68 = inverseUpJ float32
0x72 = inverseUpK float32
0x76 = inversePositionX float32
0x80 = inversePositionY float32
0x84 = inversePositionZ float32
0x88 = inverseScale float32
0x92 = distanceFromParent float32
markerGroupBlock
size = 16
0x3 = markerNameString
0x4 = markerInstanceCount int32
markersBlock
size = 36
0x1 = regionIndex byte
0x2 = permutationIndex byte
0x3 = nodeIndex byte
0x4 = translationX float32
0x8 = translationY float32
0x12 = translationZ float32
0x16 = rotationI float32
0x20 = rotationJ float32
0x24 = rotationK float32
0x28 = rotationW float32
0x32 = scale float32
MarkerNameString string

shaderBlock
size = 52

0x24 = shaderStringLength byte

shaderStrings string(shaderStringLength)




That is what I managed to map out for the the structure of the model just to be able to export it, so allot of data block and offset definitions are missing if one is to make an importer from it. But its a good start. It might also help anyone who wants to take a shot of making their own .render_model compiler/exporter. There are a few things that might be incorrect with it, but so far it work for me.

[jahrain]

On another note, Heres my first success with the first none h2 weapon model ingame. Btw, ignore 10 second job shaders.

http://i193.photobucket.com/albums/z11/jahrain00/halo22007-07-0706-42-43-16.jpg
http://i193.photobucket.com/albums/z11/jahrain00/halo22007-07-0706-42-34-50.jpg

[Lightning]

Hah, nice.

I was talking to Nitro about this, and unfortunatly, he said we would be needing to make our own model importer because tool lacked the needed things.

I honestl'y don't see why they would ban.

"OSHI HE HAS A FRAKING CUSTOM TREE BAHNN"

[LlamaMaster]

Wow dude, you are godly. And that chick model was just.....wow. I may just have to get h2v soon!

[TheGhost]

Nice work, jah.

[leorimolo]

Very nice jharin, also so when is the eta?

BTW ghost you have 777 post on the 7-7-7

[dcemuser]

Nooo! Ghost: post quickly! You're in the mind control range for Bungie; they'll force you to work in coal mines to power their offices (or knowing your skills, they'll force you to build a better coal mine).

P.S. Jahrain wins 4 Internets. Keep up the great work!

[jahrain]

Hah, nice.

I was talking to Nitro about this, and unfortunatly, he said we would be needing to make our own model importer because tool lacked the needed things.

I honestl'y don't see why they would ban.

"OSHI HE HAS A FRAKING CUSTOM TREE BAHNN"
Meh, tool doesn't lack the needed things, they were disabled and removed by them.

However, they might be like, OSHI! HE HAS A FREKING MODDED WARTHOG! BANT!" You know, h2x style.

[Kornman00]

Why, they don't even track your stinkin' stats, and if MS is that protective over achievements then...ugh, I'd be at loss for words

I really don't see them banning unless it somehow breaks regular gameplay (I could have sworn they did checksums on the stuffs, but I could be wrong)

[jahrain]

Why, they don't even track your stinkin' stats, and if MS is that protective over achievements then...ugh, I'd be at loss for words

I really don't see them banning unless it somehow breaks regular gameplay (I could have sworn they did checksums on the stuffs, but I could be wrong)Achievements is one of the very few major thing they really got to offer to Gold users of live in halo 2, I guess they would naturally be over protective of it.

[p0lar_bear]

It's just a technicality thing, really.

IIRC, it was pointed out that a specific statement in Halo 2 for Windows Vista's EULA says that users may not "work around technical limitations of the SOFTWARE PRODUCT," or something to that effect.

Not that it'll stop the dedicated modders, I'm just concerned over the possible aftermath. It's all up to where the G4WL team will choose to draw the line, and I hope they won't get anal-retentive about it.

[SMASH]

I agree with Polar. I hope that they allow soft modding, like actually constructive mods, but get rid of those nooby mods. They may actually be able to help us rid the place of crappy mods.

[Lightning]

Meh, tool doesn't lack the needed things, they were disabled and removed by them.

However, they might be like, OSHI! HE HAS A FREKING MODDED WARTHOG! BANT!" You know, h2x style.

(The functions of the H2tool we got was completely stripped of it.)

Well, honestly, if it involves making something to do something that was originally intended to do (like making a device machine/control lightbridge in Mp) I would be willing to risk it, because I know that is the only way the content would be at it's best.

What I'm saying is, even if there is software limitations, why not try your damn hardest to use the full potential of the software to tap the limitless ideas, knowledge, and dedication that the community has to offer?

That's one reason I stopped all progress on all of my H2V (sans BG) maps. I was, for the past 8 or so months, so anxious to get my maps in the new engine. Then finally when the day arrived, nothing that I had worked so hard for in CE would work in vista.

No lifts. No lightbridges. No little cutscene flash with the map name, no visually enhanced weapons, no unique lighting effects/particles, no Civihog/Transhog/Snowhog/Junglehog, hell, no spinning orb/hologram animated scenery.

Not even a single tree.

So what if we're 'crossing the line'. To me, dedication to my own work is more than worth the risk.

[DaneO'Roo]

^ TBH

Not even a frigin tree. How sad.

[jahrain]

Just a small minor update. I managed to finish the options panel, which allows some settings to manually, yet easily fix any upgrade issues as well as added some tool tips for each option. I also cleaned up the code a bit and optimized it a bit for speed. What was once about 2000 lines of code has been cut down to about 600 lines of code. I haven't set any fixed release date, but I'm hoping to at least get a public beta out by some time this week. Only a public beta well help me find out what sort of issues various users may run into and maybe pinpoint exactly what causes some of the upgrade issues as well as take suggestions on what to improve on or add in for a finalized release.

I also have some other features planned for a later version which includes automatic shader and bitmap upgrading. But I like to get things out to the public as soon as possible and add things in as I go along so no one has to sit and wait forever.

[Choking Victim]

Nice work jahrain, but i'm eager to ask if regions and permutations is a feature that you've included? Many times i've seen people create apps without these two aspects in mind. Anyhow keep up the great work.

[Nick]

Meh, tool doesn't lack the needed things, they were disabled and removed by them.Thus it lacks the needed things, since they are not present in the build we have.

http://i15.tinypic.com/62i8nzn.jpg

Nick

[DaneO'Roo]

LMFAO

[LlamaMaster]

:win post: +rep

[jahrain]

I lol every time nick tries to correct my sarcasm. :P


Nice work jahrain, but i'm eager to ask if regions and permutations is a feature that you've included? Many times i've seen people create apps without these two aspects in mind. Anyhow keep up the great work. Permutations are fully supported, as well as LODs. Right now it just transfers the first region block due to some issues it was causing with the markers, but I can assure you it will be sorted out before a final release, its just a matter of adding several more painfully tedious nested for loops.

[Choking Victim]

Awesome, thanks for the reassurance, i just thought id ask since your vertex weight injector didn't support lods or permutations and rec0s didn't support regions at first. Even theghosts jms exporter doesn't support regions :(

[p0lar_bear]

Awesome, thanks for the reassurance, i just thought id ask since your vertex weight injector didn't support lods or permutations and rec0s didn't support regions at first. Even theghosts jms exporter doesn't support regions :(

I thought it did; didn't it inject the vertex weights into each JMS file?

[Choking Victim]

I thought it did; didn't it inject the vertex weights into each JMS file?
jahrains injected the verts into the gbxmodel, rec0s injected them into each jms but the first release didn't support regions (the second release did).

[Kornman00]

you may be out of a job here soon jahrain :-3

[et_cg]

you may be out of a job here soon jahrain :-3

As the prophecy begins?

Well, good job so far Jahrain. It looks like you're doing a good job, so I'll at least say so.

[dg]

Well I'm pleasantly surprised to come back and see amazing things being done. Nice work.

[UXB]

IIRC, it was pointed out that a specific statement in Halo 2 for Windows Vista's EULA says that users may not "work around technical limitations of the SOFTWARE PRODUCT," or something to that effect.


C:\Program Files\Microsoft Games\Halo 2\eula\EULA.htm

6. SCOPE OF LICENSE. The software is licensed, not sold. This agreement only gives you some rights to use the software. Microsoft reserves all other rights. Unless applicable law gives you more rights despite this limitation, you may use the software only as expressly permitted in this agreement. In doing so, you must comply with any technical limitations in the software that only allow you to use it in certain ways. You may not

work around any technical limitations in the software;
reverse engineer, decompile or disassemble the software, except and only to the extent that applicable law expressly permits, despite this limitation;
make more copies of the software than specified in this agreement or allowed by applicable law, despite this limitation;
publish the software for others to copy;
rent, lease or lend the software; or
use the software for commercial software hosting services.

[p0lar_bear]

You may not

reverse engineer, decompile or disassemble the software, except and only to the extent that applicable law expressly permits, despite this limitation;

I wonder if korn's hax fall into that little grey area. >.>

[jahrain]

jahrains injected the verts into the gbxmodel, rec0s injected them into each jms but the first release didn't support regions (the second release did).
That is bass ackwords! Mine injected into the JMS file. I tried to convince rec0 into making his do it but he was too lazy so i made one myself that injects into the jms file. Plus, mine did support regions as it left the original JMS file untouched except with each vertex weighted, and as for permutations and LODs, that was the purpose of making it inject into the JMS file instead of the gbxmodel as far as I can recall. http://hce.halomaps.org/index.cfm?pg=3&fid=1956


you may be out of a job here soon jahrain :-3
Hope that means good news! :D

[Choking Victim]

^ I think that was the one you released around the same time as rec0's. I dont think i've used that one yet.

[jahrain]

^ I think that was the one you released around the same time as rec0's. I dont think i've used that one yet.His was out for a year before I made and released mine.

[SMASH]

After this is it onto collision models jahrain? They can't be that different.

[jahrain]

After this is it onto collision models jahrain? They can't be that different.I will definitely look into it. As well as animations too. I don't know how much they differ yet, its hard to tell just by reading hex.

[SMASH]

Yea, hopefully I can understand this stuff in due time and give a helping hand.