MDX Format (Vertex Data)

The .mdx format is a companion file that always pairs with a .mdl model. It holds lists of raw 3D coordinates (vertices), and every mesh in the .mdl carries an offset into it.

InputBinary::Reset copies the whole block into an OpenGL pool at load, and nothing afterwards reads it again. The rest of the reset chain is handed the pointer and never looks inside, which is what a straight upload leaves behind: no CPU-side code has to read a buffer already sitting in GL memory. Write it correctly. See what the trace covers.

At a Glance

File Layout

There is no index and no table of contents. An .mdx is one interleaved buffer: each vertex’s position, texture coordinates and normal sit next to each other in the stream, and the next vertex follows immediately. Which components a given mesh writes, and therefore how wide one vertex is, comes from the mesh node in the accompanying .mdl rather than from anything in this file.

That is the whole layout as far as reading goes. Writing needs three more rules, because a shipped .mdx is bigger than the vertex data alone and the extra bytes are structured rather than slack:

So the file size is the sum over meshes of vertex_count * stride, plus one stride per mesh, plus the alignment padding between them. A writer that emits only vertex data produces a file no community tool will match byte for byte.

The derivation of these rules, including how the sentinels were found and how the stride interacts with the alignment, is in the MDL & MDX deep dive.

Engine Audits & Decompilation

Deep Dive: For an exhaustive archive of the Ghidra decompilation notes detailing the exact byte-level layout of the binary MDL/MDX format and engine loading pipeline, refer to the MDL & MDX Deep Dive.

Read from InputBinary::Read (0x004a1230) and InputBinary::ResetMdlNode (0x004a0900) in swkotor.exe. Provenance: derived, not attested. The rows below have not been separately re-derived, so they sit on the reverse-engineering queue.

What the trace covers

InputBinary::Read loads the file into a buffer and hands it to InputBinary::Reset (0x004a1030), which performs the upload inline: GLRender::RequestPool for a pool sized by the model header’s +0xB0, LockPool, a memcpy of that many bytes out of the buffer starting at the offset in +0xAC, UnlockPool, and the handle registered for later freeing. Read then releases the CPU-side buffer, the pool having taken its copy.

Only after that does Reset pass the pointer down the rest of the chain, and nothing below it reads through the pointer: ResetTriMeshParts goes as far as overwriting its copy to reuse the register as a loop counter. That is traced through named functions, and Reset has exactly one call site, so this is the whole load path rather than one of several.

Three findings in the deep dive describe the same operation from other angles: +0xAC and +0xB0 are the copy’s source offset and length; binary models carry per-vertex bone weights nowhere but MDX, so a skinned character deforms on the strength of it; and the mesh header’s per-attribute offset slots are offsets into an MDX vertex record, with LightPartTriMesh and PartTriMesh reading at them.

Loading and Lifecycle

TriMesh Structural Addressing

There is no scan through the file block by block. Whatever reads it is driven by the MDL hierarchy, which supplies both the per-mesh offset and the record layout.

Note

Ghost Payload Sentinels During memory extraction, the engine implicitly pads geometric mesh payloads out to distinct 16-byte aligned boundaries using Terminator Rows. Any mesh vertex iteration falling slightly out of stride will be explicitly back-filled with ghost/sentinel float arrays ([0.0, 0.0, 0.0]) to ensure OpenGL buffer calculations remain strictly uniform without overflowing pointer indexes during hardware streaming.

Proposed Linter Rules (Rakata-Lint)

Incorrectly calculated .mdx offset spans or payload array lengths can cause the engine to read misaligned bytes or overflow data bounds. Providing a linter rule to validate these payload alignments helps prevent geometry corruption and potential engine/gpu crashes.

While rakata-lint currently only evaluates GFF formats and does not yet parse .mdx buffers dynamically, the engine behaviors above hint at the foundational requirements for .mdx stability:

Planned Lint Diagnostics:

1. Mesh Slice Verification: Enforces explicit iteration seeking. Validates .mdx vector boundaries by explicitly jumping pointers down the file according to individual mdx_data_offset assignments mapped on explicitly bound TriMesh headers, rather than assuming unverified sequential payload lengths.