2

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.

File's preliminary map in a hex editor

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.

8
  • 1
    Am I reading these correctly? pastebin.com/4qLcryW8 Jul 30 at 19:52
  • @mindoverflow almost, but not exactly. Between the "mat?" float array and list 3 float array there's 73 bytes of data I cannot identify. List 3 should start at 0xC0 (alternatively, offset +192). That would place vertex 0's X coordinate at 0xCC. 0xCC is 7D, 0xCD is 00, giving us 125 (a word, Little Endian). I've added the way I mapped the file out in a hex editor to the original post, I didn't know I could attach images before.
    – Xtal44
    Jul 30 at 23:43
  • 1
    I accidentally read 4-byte uint16s, which is nonsense. This should be correct: pastebin.com/bYjjerNR I'm afraid I can't help you any further here due to my limited knowledge of 3D formats, I'd suggest parsing a lot of headers and looking for correlations. Aug 1 at 9:48
  • @mindoverflow thank you for trying your hand at it!
    – Xtal44
    Aug 1 at 21:33
  • 1
    I had an idea just now and tried to verify it. It's a bit off rouding-wise, but the "matrices" could actually be lists of normalized surface normals. That would make a lot more sense than the transformation matrices, too. Either way, could you upload a model that has some more tris? Aug 4 at 9:16
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.

1
  • Thank you very much for your efforts! I will look into the zlib compressed streams, also. Reverse engineering the executable is not out of the question - I'm already doing so to figure out the proprietary script format (which also appears to be compiled to some kind of a proprietary assembly language, with C++ classes for each instruction in the main engine DLL) the game uses. Thanks for the suggestions.
    – Xtal44
    Aug 9 at 23:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.