Shameful double-post for exposure: I extracted a point cloud directly from the MDL file!
VIDEO LINKI read the bytes all wrong. Here's the first point definition bytes:
00 00 80 3F 00 00 00 00 00 00 A8 40 80 80 80 FF 00 24 00 2CInstead of reading them as integers, I had to read them as Little-endian Floats. I used
this page and got myself the following readout:
3F 80 00 00: 1
00 00 00 00: 0
40 A8 00 00: 5.25
FF 80 80 80: NaN
2C 00 24 00: 1.8209878e-12Now, obviously the last two doubles are incorrect, but the first three look totally reasonable. By interpreting them as x, y and z I got the first point of the cloud shown above.
EDIT EDIT:
I've got... some progress.
• All MDLs begin with the same word, 18 00, which is a pointer to where all the data begins.
• After that, there's 44 52 00 01 00 00 43 00, these are always the same too.
• After that, there's a word for object amount (OBJAM), then a word for texture amount (TEXAM), then a word that's always 02 00.
• Then comes the first pointer. Four bytes - the pointer to the object headers (OBHDR).
• Then comes the second pointer. Four bytes - the pointer to the texture definitions (TXPTR).
• Then comes a strange pattern. It's always 0x1608 bytes and appears to be 0x54 bytes wide. This is the same in every single MDL. I don't know what this means.
• After those bytes, we've arrived to the first object. Every object begins with a 0x14 byte subheader. The subheader has:
•• Four bytes for a pointer to where the point list begins
•• Four bytes for a pointer to an unknown array of 0x0C bytes
•• Two bytes for the amount of points in point list
•• Four unknown bytes
•• Two bytes for which texture to use for this object
•• Two unknown bytes
•• FF FF
After the subheader there's a varying amount of words. I don't know where the amount comes from. Sometimes it's 0x7E, sometimes it's 0x86... no idea
• But then we're at the point list as told by the subheader's first pointer. Its format is as follows:
•• Four bytes for x (float)
•• Four bytes for y (float)
•• Four bytes for z (float)
•• Four bytes for vertex shading (possibly unused!)
•• Four bytes for unknown
After the point list, there's the weird array of 0x0C bytes as told by the subheader's second pointer.
... Then, repeat the same thing again, x times. x being OBJAM.
• After all objects have been listed, we've arrived at the offset that OBHDR told us about. It's format is as follows:
•• Two bytes for the size of the object header
•• Two bytes for unknown
•• Two bytes for texture name pointer
•• 32 bytes for unknown
•• Two bytes for unique texture ID
•• Four bytes for unknown
Repeat this OBJAM times.
After those, we've arrived at the offset that TXPTR told us about. It's ASCII and says fb0-l05 fb0-l0d fb0-blkface. Those are the names of the texture files this level loads to its memory, and there's three of them because TEXAM is 03 00.
End of file. Note: what was between the texture definitions and the object headers were the ASCII names of the individual textures.
