Rigged Models Potential Solutions

[mmentc]

This might lead to some interesting finds. There's a pattern for NGP files that contain rigged models. Using Model Researcher, you can extract the models using the following parameters. The static meshes are short signed, and those that have moving parts (rigged) are floats. I've highlighted the important bits in the screenshot. This can be imported into your script to make things easier, but automating binary offsets are beyond me. Let me know if you discover anything else.

[mmentc]

Adding what the HEX editor looks like for clarity.

[JMcKiern]

Nice!

I looked for addresses that were pointing to the offsets you've used.
The vertices are pointed to by 0xB098. Faces are 0xB0B8. These are both relative pointers (dest_addr = val_addr + val). But I don't know how the data there is structured.

In #1 I described a "Model Header" which seemed to have most of the info related to each model including faces, vertices, texture and something like a normal map. However, the data around 0xB090 is not in the same format. Maybe these model headers are only for the static meshes?

Currently, the ngp_models.py script is pretty crude. It relies on detecting certain patterns from the model headers. I'll have to do a bit of work before I can add the rigged meshes to the script.

Great find though!

Any idea what the data in between each vertex might be?

[mmentc]

Awesome, sounds like we're on the right track. I'm almost positive that it's UV data or something similar. I wouldn't exactly ruling out normals as well. I'm currently going through and experimenting to see what I can find, but I'll have to dive in a bit later. Please let me know if you need any further information.

What I can say though is that every single model that isn't a static mesh can be extracted this way. I think this would be the way to extract an entire map in one sitting. The only thing left would be to find the bone structure, which I'm sure is at the very bottom of the files containing rigged models (characters, tanks, planes, etc.)

[JMcKiern]

Sound good.

I had another look at the data around 0xB090. It looks like this model header starts at 0xB074 and the next one starts at 0xB0D4. So, everything in between is likely useful. It actually looks fairly similar to the model header. And 0xB078 points to 0x6D77E4. There might be some interesting things around there.

Ideally we'd figure out the format of this data and then use this to extract it.

I don't really know how skeletons work but ajeep.ngp has a few mentions of "tire" at 0x26B0. Could that be the bone data?

Also, I guess I should probably change the output files to .dae. I don't think .obj files can handle rigged models.

[mmentc]

Amazing find! I think we're getting fairly close here, and I'm definitely looking into what this data could possibly be.

I would be very surprised if that jeep has bone data. It might just be the name of the asset for identification purposes. Tires shouldn't need a bone for rotation. The only thing I can think of is if it's for the jeep's suspension physics.

I think that's a good idea. I think we should maybe look into FBX files if possible. If we do get to the maps soon here, I think FBX would come in more handy, but it could just be preference on my end.

[JMcKiern]

What are bones actually for then? Just animations? I'm completely new to how 3d models work btw 😃

I actually ran the script on the archipelago ngp file. But even the terrain came out in a few different model files. I think you're right - a more complex file format needs to be used.

I started using OBJ files because the file format is very simple (see here). But it doesn't support stuff like skeletons, animations etc. Writing to an FBX would be possible through Autodesk's FBX Extension SDK. COLLADA (.dae) is an open source model format which is why I suggested that. There's a python library called pycollada that could be used for this. Another option would be to use the Blender API. This can do most of what a user can do and has the option of exporting the scene as various format. But I'm not sure how complicated this would get. It might be a bit overkill. I'll have to take a proper look at all these when I get a chance before I can decide on one.

[mmentc]

Good thing I'm well versed on the animation side :). Bones are usually used for animating body parts, physics, and the like. I'm certain some models have a parent bone, even the simple meshes like the knife. Those are just for ease of use in terms of animating, but it's not necessary (for example, you probably don't need a bone for glasses).

I'm all for open source, so Collada might be the way as you previously stated. I do agree that the Blender API might be a bit overkill.

I'm still scanning through the offsets you've listed above, but it's a bit tricky. There's an obvious pattern, but I'm not sure what it's for. I think a good idea is to compare the multi_frontend with the nemesis or warhawk ngp files. I think we might be able to find out what the animation data is if all else.

[Exentricity]

Any update on this? I'm working on a remake of warhawk and would love to use some actual game character models

[JMcKiern]

Nice! Is there somewhere I can watch your progress? I'd be interested to see how you get on

We never managed to get the bone positions reversed. I wanted it to be automatically done using a Python script but ultimately it was too much work. I moved on to other things. I might try again at another time.

Feel free to try yourself and let me know if you see something I may have missed.