1. What the available evidence establishes
.MEF is a chunked model file used by I.G.I. 2. The repository templates and native converter parser describe a 20-byte ILFF outer header with file type OCEM, followed by linked 16-byte chunk headers and payloads. Chunk order and offsets should be read from the file rather than assumed from this overview.
This guide separates layouts implemented by the parser/template from higher-level interpretations that remain unconfirmed against a supplied retail sample.
2. Container and chunk structure
Recognized chunk FourCCs include HSEM, XTRV, ECFC, and auxiliary records. A FourCC alone does not prove that a payload implements portal visibility, room adjacency, or a particular rendering feature.
3. Vertex and collision records
| Chunk / record | Parser/template representation | Confidence note |
|---|---|---|
XTRV, type 0 | 32 bytes: position, normal, UV0 (eight floats) | Template and native parser agree |
XTRV, type 1 | 40 bytes: position, normal, UV0, weight, local vertex ID, bone index | Template and native parser agree |
XTRV, type 3 | 28 bytes in the current IGI 2 template and native parser: position (12B), UV0 (8B), secondary UV (8B); parser supplies no normal from this record | Conflicts with longer project docs that state 32B. Retail-file verification remains outstanding. |
ECFC | 12 bytes: six uint16 values (a,b,c,mat,lmp,vrt) | Not a 32-bit lightmap ID. Meanings of final fields are not fully established. |
TROP | 20 bytes: five uint32 values | Field names in parser are offsets/counts/ID; portal/adjacency semantics unverified |
XVTP | 12-byte three-float vector | Parser representation |
CFTP | 12 bytes: three uint32 values | Parser representation; semantic interpretation unresolved |
PMTL | 16-byte record; parser reads first uint32 as material ID | Other fields’ meaning not asserted |
ATTA / XTVC | ATTA: 72 bytes; XTVC: 20 bytes | Template/parser record sizes |
4. IGI 1 comparison and open discrepancy
The IGI 1 parser/template describe type 3 vertices as 40 bytes; the IGI 2 parser/template describe them as 28 bytes. Some longer IGI 2 documentation instead reports 32 bytes. Because the checkout has no retail MEF sample available for this audit, the 28-byte value is reported as the implementation’s current read, not as a settled universal fact. The discrepancy should be checked against real assets before a definitive claim.
Evidence: Templates/IGI2/IGI2_MEF.bt, Templates/common/ILFF.bt, and the IGI 2 converter’s mef_native.cpp / mef_compiler.cpp. See About for source links and verification limits. No engine API, portal-culling algorithm, or material behavior is inferred from the record names alone.