Proprietary 3D Format Reverse Engineering: What Could These Numbers And Matrices Represent?

Question

I'm trying to reverse engineer a model format from an older Russian game (Pathologic) with limited success. It is a proprietary model format not recognized by any converters/editing tools (believe me, I've tried! someone on the fan forums confirmed this with the person behind the engine, also). I'd like to be able to read the models into a potential open-source recreation of the original engine. The original game uses Direct3D and is from 2005, so I read up on relevant docs to get a start. Unfortunately, it's not the "x" model format.

What I've got so far (for a simple mesh):

• Texture file name/location
• Number of faces and vertices
• UV coordinates for each vertex
• Vertex buffer

Things I'm struggling to understand (least to most important)

• File header: what could it mean?

• "Arbitrary" padding in the file: what could determine its size?

• 12-element float matrices. Could be transformation matrices without the last row - to use with homogenous coordinate systems, but there's 6 of them in a mesh with 4 vertices and 2 faces - isn't that too many?

• Mysterious 4 bytes describing each vertex: some kind of a color format?

• Mysterious sets of 3 32-bit floats repeating multiple times - what could it be?

• Where could the vertex normals be stored?

Attached is a very simple mesh (way under 1kB) I'm studying before moving on to the more complex ones. I believe it to be a simple textured plane. I've started with a similar mesh that was in XY plane, this one seems to be oriented a bit more arbitrarily. Since it's a plane, I assume it has 4 vertices and 2 faces.

Simple Mesh

File's structure as far as I can understand it

• Header at 0x00.
• Texture Filename Length at 0x11 (16 characters here)
• 1 byte padding
• Texture filename (h2_door_DXT1.tex)
• 1 byte padding
• Number of vertices at 0x23 (4 vertices)
• Number of faces at 0x27 (2 faces)
• 12 bytes of recurring 3x 4-byte floats (first occurrence)
• Mysterious float
• 12 bytes of recurring 3x 4-byte floats (second occurrence)
• 12-element float matrix (transformation matrix?)
• 73 bytes of unknown data
• 12 bytes of recurring 3x 4-byte floats (third occurrence) at 0xC0
• Data for four vertices at 0xCC. For each vertex, there's 3x int16 for X,Y,Z coordinates, then, 4 mysterious bytes, finally, 2 32-bit floats for UV coordinates.
• Vertex buffer at 0x114. Two triangle descriptions, for each there's 3x int16 for the vertex IDs.

After that it becomes a mix of 12-element float matrices and the recurring 3x floats with some padding/magic numbers between them.

I'd appreciate any and all help with answering my questions/helping with the bullet points I'm struggling on. I could also provide other mesh examples as needed.

Answer 1

I'm giving up for good. If you say that there's 21 .mesh files for 21x the same object in the scene, then chances are good that there's a lot more non-mesh data in this file (as you said, baked shadow info, world pos, colliders, actor references, possibly animation data, ... Sounds unusual to me, but there's probably a reason to put all of this into one file).

I was able to find two zlib compressed streams in the actor file at 0x4B and 0x11C using binwalk, but that's about it. The mesh files are way more complex than they look at first glance...

You might get some more info out of the files by changing random values and observing the effects, but chances are slim that you find out how these files really work without debugging or reverse engineering the executable.