Well that's interesting

[DeadHamster]

I was looking through the mod2.meta of a piece of scenery in hex, and noticed something that interested me quite a bit;

There's a good chunk of model information missing.

It's just...not there. Completely missing.

But that doesn't make any sense, it HAS to be there. Or maybe not, couldn't it be stored somewhere else? Because it obviously has to be somewhere.

Which leads me to that it must be stored elsewhere, maybe somewhere in the actual .map for example.

If anyone (conure/alt) could give me some insight as to where it, it'd be greatly appreciated. Much Thanks.

[bcnipod]

Modzy may be able to help you with this.

[botternub]

sounds like a mission for




HAMSTAAAAAAAA

[DeadHamster]

If anyone can help, please do. I wasnt solely asking conure or altimit, I just figured they would probably know.

[bcnipod]

Modzy, who rarely posts here knows lots about some stuff
He posted in the vote thread, so you can either PM him, or email him. If he can help, I am pretty sure he will.

[Andrew_b]

or catch him at macgamingmods.

[Altimit01]

All model data is stored in what we call the raw portion of the map. It exists after the BSP data but before the index data. Grenadiac's tutorials on the mapfile structure should give you a good starting point. (1, 2 & 3.)

The mod2 metas have information that talks about where in the raw data their model data is. (Sounds and bitmaps do this too if internalized.)

Let's see IIRC. In the mod2 meta at 0xd0 is the reflexive for geometries. Inside the chunks at local offset 0x24 is the "parts" reflexive. Local to the chunks of the parts is the data for where the indices and verts are. 0x48: indices count (uint32). 0x4C: indices offset1 (uint32). 0x50: indices offset2 (uint32). 0x58 vert count (uint32). 0x64 vert offset (uint32). Note that none of the offsets should be modified by magic. Now the tricky thing about offsets is how they are handled. In the map index is a value that gren calls ModelRawDataOffset. That is the literal location of the start of the vert data. Adding the vert offset stored in the meta to this value will give you the location of the vert data for that model. Similarly in the index is a value gren calls indices_offset. Adding that to the ModelRawDataOffset gives the start of the index data for models. Adding the indices offset (1 and 2 should be identical) to that offset gives you the location of the index data for that model. To recap:
ModelRawDataOffset + vert offset = vert data for given model
ModelRawDataOffset + indices_offset + indices offset1 or 2 = index data for given model

So that's the simple stuff done. Indices are in the form of shorts (int16s). The thing about indices are that they overlap. So in the data you might see 1 4 6 7 8 9. The first triangle (Halo only uses triangles btw) would be 1, 4, 6. The next would be 4, 6, 7 and so forth. I'm going to cheat a little bit and borrow from gren's sparkedit code for the verts. Here's the format for vert data.

Code: Select all

  float coord[3];
  float Normal[3];
  float Binormal[3];
  float Tangent[3];
  float u;
  float v;
  float unk2[3];

Hopefully that explains most of it.

[DeadHamster]

That did help a lot Alt, unfortunately it also really really sucks.

I was planning on a mod2 plugin very similar to the collision one (which I found oh so much joy in conure's being 1000x better. -_-), with the ability to edit vertice locations, so that you wouldn't have to export, find a model program that supports moving based on XYZ coordinates, edit each vert, and then reimport.

The latest version of MM3D does the coordinates, but of course, it doesn't save it right, and I have to open and save in an older version of MM3D in order for HMT to accept it and inject the model.

This also means that I have to use HMT, which I'm trying to distance myself from as much as possible, what with eschaton kicking ass and all.

I was just hoping to streamline the process a bit, and based on what you told me I cant do it with a plugin. Thanks for the information Alt.

[Modzy]

Modzy, who rarely posts here knows lots about some stuff
He posted in the vote thread, so you can either PM him, or email him. If he can help, I am pretty sure he will.

I see what you did there.

Alt got to before me, and he did explain it better then I ever explain anything.

Anyways. . . I'm sure Alt is going to add support for model injecting in future releases of Eschaton. Or I could, as a project, make one. But that depends on how lazy I am. >_>

I must go eat and contemplate why the box for entering text is so goddamn small on this site.

[DeadHamster]

There's support in existing programs, however it wasn't so much the importing and exporting as it was the editing without having to do so.

Building a map with a series of 8 vert boxes, it would be annoying to constantly export and import models, as opposed to clicking on it's tag, and entering a couple values for it's size.

That was the purpose, but apparently it won't be possible in plugin form.