Hello! You were all extremely helpful pointing me to ModelFinder PC last time. I've tried everything I can think of to find the face indices for the models in the PS3 version of the game I'm currently working on REing with some other fans of its franchise.

This low LOD penguin has basically acted like a Rosetta stone for me figuring out where the verts, UVs, etc. are in the different console versions of this Krome Studios game. However, for this PS3 version, the face indices are eluding me viciously! The Merkury engine tools available are all for older versions of the engine, so no luck there. 

I've included the following samples:
A "pmc" file which is a combination of two other files, an "MDG" and an "MGV". You can see where each one begins based on its header. I had to combine them like this to make them one cohesive file programs like Hex2Obj and ModelResearcher could read. The MDG contained things like the float vertices and what our research suggests is normals inserted between those vertices and something involved in bones/skinweighting in the repeating sequences of "FF000000 00000000". The MGV contains half-float UVs interwoven with what we believe are related to the terms "ambient occlusion" and "colorset". The float vertices and the half-float UVs have been tested and confirmed, but we can't test anything else until we figure out the face indices.

An "ast.ads" file which seems to be related to animations.

Other files I have looked at and easily disqualified:
An "mdlb" file for the low LOD penguin, which contains too little data for any index sequences.

A "lod.bin" file for both the high and low LOD models. Most of the data was just readable ASCII strings naming the two LOD models and the LOD file's own type. What remained could not be indices.

Anything else in the files mentioning "penguin": Mostly sound files and textures and things related to lighting. Nothing relevant to finding the face index block of a 3D model.

Some notes:

I compared the "ast.ads" files across the Wii, X360, and PS3 for this model and they looked generally the same save for an occasional byte difference here or there I noticed. There weren't any blocks added on or swapped out for something noticeably different. I highly doubt that they would bury two separate LOD meshes' indices in there, but it's the largest and least understood file, so maybe you will all see a pattern of them in there where I can't.

The sections towards the bottom of the MDG starting with 041804 or 030C03 are in the MDG files for both the low and high detail penguins, and are almost exactly the same except for a single byte difference between them, so I'm almost certain it's not those. 

The XBOX was just short-int tri indices, a single short for all indexed values since there was an equal number of all them: 22. Each of the points down the midline of the penguin were actually two unmerged verts.

The Wii used tristrips starting with a byte of "98" and a two-byte value equal to the number of ten-byte segments of five shorts in that tristrip. The shorts would be a vertex index, a normal index to go with it (which matched it), an ambient occlusion index, a colorset index (which matched the ambO), and the UV index unmatched by anything. Then it would do the second of each of those values over another ten bytes. The Wii version technically had 15 verts, but I only counted it as having 14 for the mesh since the last of those verts was a repeat of the one at the bottom of the belly centerline, and the indices never referenced it. It was likely an artifact of an automated program to scale down the models for the Wii, as all of those other points along the midline that were two "left and right" merged verts were suddenly united into one vert each - except for the one mistake with the 15th vert.

The PS3 splits up its files into an "mdg" an "mgv" like the Wii, but it has the same vertex count as the XBOX, the data is separated into those two files differently from the Wii, and the number of UVs, theoretical normals, and ambO/colorset values appear to all be equal so they would likely use just one set of indices like the XBOX did.

The image I'm attaching was a mockup of the penguin I made in Blender so I could first mark down the indices on each vertex and check if any of the patterns I was testing in the Wii data would make any sense. The cyan indices are the Wii indices, the green ones are the PS3 ones (unless it gets split into two submeshes). The yellow lines are the background tristrip from the Wii, the blue lines are the foreground one. Thick lines are on the main "zigzag" connecting the indices that make up the tristrip and thin lines are the lines drawn between alternating points on the tristrip. If there's an "X" over the middle of the thick line, that line is doubled back over by the main zigzag - either immediately or to unite the beginning and end of the strip. 

If the PS3 version used the same triangles as the XBOX, then the "00 01 02" triangle from the very start of the XBOX indices would be "05 01 00" or "05 01 12" instead.

If it used the tristrips from the Wii, and the overlapping central verts were cleanly separated so the first half of them was used with the left half of the bird and the second half with the right half, this pattern would be used:

02, 01, 03, 01, 04, 05, 06, 05, 07, 08, 0A, 08, 09, 08, 00, 01, 02

15, 14, 13, 0E, 0C, 0D, 0C, 0B, 0F, 10, 0F, 11, 0F, 12, 13, 15

(Yes the Wii mesh doubled up weirdly around the tail for the left half of the penguin)

I would greatly appreciate any help you can offer! I've been wracking my brain over this last version of our rosetta-penguin for well over a week now.

penguinsamps 2.zip

Hi, bad idea to describe 3D formats by pure text. (No one will read it, usually.)

Better use tables with offset addresses and short descriptions, for example. (Just my 2 cents.)

It might be useful to say which specific game it is you're looking into, as game engines can evolve over time - and also add the game to your topic title in case others may have already looked into it.

I can't see anything specific regarding face data in there either.  Maybe a few more larger samples would be helpful in determining the data format.

 

Ah, sorry about taking so long to respond! Let me try to rewrite things more concisely. Alright, so for the files above...

"PMC" file: combined "MDG" and "MGV" files, so data is all in one place for using MRPro/Hex2Obj.

Known offsets/counts, confirmed with testing: 

Verts: 0xA0, 22 count. Floats. 12 bytes for one set, then 12 bytes padding of other data before next set.

UVs: 0x460, 22 count. Half-floats. 4 bytes for one set, then 8 bytes padding of other data before next set.

Table of key offsets/counts: 0x3F0 until the FFFFFFFF parts. I've managed to find what sections ALMOST all of these match up to. "80" and "20" are offset and count of one unknown block before vertices and "30" and "B0" are offset and count of block before that. "A0" and "210" are the verts in the MDG, "10" and "108" are the UVs in the MGV, so on and so forth. The only offset/count I haven't been able to pin down are "0580" and "78" - all the penguin-related files are either too small for "0580" to be a count OR an address, or don't have a consistent data pattern with the corresponding offsets in penguin_01.

Offset/counts with unconfirmed but suspected purpose:

Normals? 0xAC, 22 count. Floats?. 12 bytes for one set, then 12 bytes padding of confirmed vertex data before next set. Can't test these until face indices are found.

Something related to bone data?: 0x2B0, 22 count. 8 bytes reading "FF000000 00000000", repeated 22 times. Offsets in other console versions were found pointing to certain data as "skin indices/skin weights" that looked like this.

"Ambient occlusion"/"colorset": 0x464. 8 bytes of data following pattern of "L?L?L?FF, L?L?L?FF", where L is letter, ? can be letter OR number, and FF is always FF. 22 instances of this, spaced apart by 4 bytes padding of confirmed half-float UVs. Files in other console versions specifically point to data that looks identical to these values as "ambientOcclusion"/"colorSet1". 

Completely unknown purpose:

Starting at 0x30, 80 bytes: The offsets/counts block marks this as important, purpose unclear. Includes section with "112233445566778899AABBCC" found in other files.

Starting at 0x80, 20 bytes: Another one marked as important by offsets/counts, purpose still unclear.

Sequences at 0x360, 0x390, 0x3C0, measuring 48, 48, & 32 bytes: Not clear, but other than 1 byte change, exactly matches a section in higher LOD/vert count penguin model, and all attempts to find pattern of face indices have resulted in values too high to be valid.

Starting at 0x424, 8 bytes: The only unidentified offset & count. I have searched every file specific to penguin_02 and none are large enough for "0580" to be a valid offset/count. The only shared file with penguin_01 large enough for it to fit in is the "ast.ads" file, but then the corresponding value "2300" in the penguin_01 mdg is too large for the ast.ads.

If anyone can put their eyes to this challenge and find the indices, I would greatly appreciate it.

23 hours ago, DKDave said:

It might be useful to say which specific game it is you're looking into, as game engines can evolve over time - and also add the game to your topic title in case others may have already looked into it.

I can't see anything specific regarding face data in there either.  Maybe a few more larger samples would be helpful in determining the data format.

 

Sorry about that! This is "Legend of the Guardians: The Owls of Ga'Hoole" on PS3. 
I would add larger samples, but I thought based on the rules I had already reached my limit for this game since the "pmc" file is technically two official game files in one.

Edited January 14Jan 14 by gryphongirl

Thanks!

So a penguin sample with 22 vertices is all we have?

I'm so sorry. I was a noob to this whole process and I didn't think of the fact a larger one would be helpful. Am I allowed to post any more samples? I would do so if I could, though I worry about grabbing the completely wrong file and wasting that chance.

The closest I've come to success in my searching since these posts is that I found a ".hindex" file that seems to be specifically for level geometry/height map face indices. I'm now checking to see if I can find any files like that for creatures/characters...

Thank you all for your help so far.

51 minutes ago, gryphongirl said:

I'm so sorry. I was a noob to this whole process and I didn't think of the fact a larger one would be helpful. Am I allowed to post any more samples? I would do so if I could, though I worry about grabbing the completely wrong file and wasting that chance.

The closest I've come to success in my searching since these posts is that I found a ".hindex" file that seems to be specifically for level geometry/height map face indices. I'm now checking to see if I can find any files like that for creatures/characters...

Thank you all for your help so far.

Other samples are good for reference.  However, I have checked some other ones from the game that I found, and they're much the same format.  Just to add some info on the section at 0x2b0 in your example.  It is the bone weights and indices - they are interleaved, so you get weight/index/weight/index etc. 8 bytes = 4 per vertex.

 

36 minutes ago, DKDave said:

Other samples are good for reference.  However, I have checked some other ones from the game that I found, and they're much the same format.  Just to add some info on the section at 0x2b0 in your example.  It is the bone weights and indices - they are interleaved, so you get weight/index/weight/index etc. 8 bytes = 4 per vertex.

 

Thank you so much for confirming that! I've been hoping to try rigging some of the skeletons in the future and this information will help. We've been managing to reconstruct an unused character from the game who came from the book series, and if we can fully rig her that would be amazing.

That "terrain.i16.hindex" file still remains the closest thing I can find to any face indices, but it definitely doesn't work with characters/creatures.

Alright, haven't decided on other files to include yet, in case I waste all the chances to share samples from this game. But I HAVE managed to find some instances of what are almost certainly face indices, but only for environmental prop geometry... and it seems to be random which ones will have them. If I have any more leads or can narrow down the samples to share, I'll come back here to share.

4 hours ago, gryphongirl said:

Alright, haven't decided on other files to include yet, in case I waste all the chances to share samples from this game. But I HAVE managed to find some instances of what are almost certainly face indices, but only for environmental prop geometry... and it seems to be random which ones will have them. If I have any more leads or can narrow down the samples to share, I'll come back here to share.

I've seen a few mdg files where there appear to be normal face index values at the start of the file.

I suspect that the face indices in most files are using the compressed Edge format, which is probably the data at the start of each vertex block.  I haven't dealt with these much at all, so I'm not 100% sure if this is the case, or how to properly decompress them.

Apart from that, it seems fairly logical that all the main mesh info is in the mdg/mdlb files.  The mdlb has definite offsets to each mesh part in the mdg file.

 

 

On 1/15/2026 at 12:22 PM, DKDave said:

I've seen a few mdg files where there appear to be normal face index values at the start of the file.

I suspect that the face indices in most files are using the compressed Edge format, which is probably the data at the start of each vertex block.  I haven't dealt with these much at all, so I'm not 100% sure if this is the case, or how to properly decompress them.

Apart from that, it seems fairly logical that all the main mesh info is in the mdg/mdlb files.  The mdlb has definite offsets to each mesh part in the mdg file.

 

 

A compressed Edge format? Okay that's VERY interesting, and it would explain why I was seeing indices at that beginning key offset in some level geometry files but not in others like character files. I'm going to work on researching those today to see if I can reverse them somehow, but I definitely would not protest if you had time to provide some links to info on this here in the meantime.

While your explanation of it being odd compressed formatting makes sense, I'm still going to also keep my "small model method" handy as a backup method with a new model in case it doesn't pan out. A friend made me a  python script that can search all files in a directory for a sequence of byte values in hexcode form. The tricky part with penguin_02 is that given some of the oddities left over by what seems to be Krome's use of a mesh decimator (they zipped together the two halves of the penguin_02 mesh so the centerline verts only have one index each, except vert 0x15 which is a duplicate of the bottom center belly and never gets referenced by the indices) I couldn't feel certain which of the two indices for a centerline point the PS3 version would actually use for a given triangle - and there were no triangles that DIDN'T use centerline points for an easier search.

I've RE'd and exported another low vert count creature model from the XBOX version with MRPro - owlet_02, which is basically just a potato-shaped lump that gets a texture mapped onto it - and last night worked on mapping the XBOX indices onto it, then started mapping the PS3 ones to match. It has some tris that don't touch the doubled-up centerline, so if it IS just plain face indices stored in a weird file, I can search possible sequences of three indices for one of those tris and see if I get any hits.

On 1/15/2026 at 12:22 PM, DKDave said:

I suspect that the face indices in most files are using the compressed Edge format, which is probably the data at the start of each vertex block.  I haven't dealt with these much at all, so I'm not 100% sure if this is the case, or how to properly decompress them.

Apologies, I just realized you said you don't know how to decompress them. I also realized that during a previous attempt to reverse engineer a piece of level geometry with what looked like plain face indices, it didn't seem to work... I wonder if it may be possible that those were also edge indices, just uncompressed!

Update: Got my hands on a Blender addon that allows me to see the indices of the edges and faces. I'm looking at the XBOX version of these small models to see what logic edge indices follow in this game, since similar logic might carry over to the PS3 version even if the vertex indices it derives results from are different. The only documentation on how edge indices are ordered with respect to vert indices that I could make heads or tails of without this was an example image of a basic cube that looked like it was drawn for a math textbook. The logic from that image was hard to apply with any certainty to these meshes because 1) that was handling only 8 vertices, not 22 or more, and 2) that diagram was effectively using quads while I'm using tris. 

Tried using my physical PS3 copy of the game with an emulator and NinjaRipper to get one of the small models I'd been studying, owlet_02, and see if I can export it to Blender to understand the order of the edge and face indices in relation to the vert indices. (I would go for my familiar friend penguin_02, but that's WAY farther into the game and I don't have access to a PS3 version save file that can already access the Northern Kingdoms level). Unfortunately, NinjaRipper only wants to pay attention to the Windows EXE version of RPCS3, not the Mac APP one, and RPCS3 either doesn't run nicely through Crossover in general or through NinjaRipper THROUGH Crossover in particular. I'm either going to have to hope VMware Fusion can run the two-program setup well enough to get stuff from it, or go back to the drawing board studying the raw code with no other assistance.

In weirder news: I looked at some other character models to see if I could recognize a more obvious pattern, and for some reason one of them had a bunch of repeated bytes of "FF" and "77" in nonsensical patterns in the areas I was so far suspecting of being the data I need. I also haven't been able to pin down the order the PS3 indices would be in based on the XBOX ones - the pattern of tris from verts breaks down at the third XBOX tri "4, 5, 0", which doesn't exist in the PS3 version. Not sure if there's a steady set of rules for how these are generally ordered...