01 — What is MOD?
Start with the completed DMC3 HD MOD reverse, the resource's role and the separation between reverse completeness and writer/original-game acceptance.
Devil May Cry 3 HD Collection · Evidence-first C++20 research
DMC3 MOD Format — DMC Rengine
The DMC3 HD MOD reverse is complete for the canonical project scope: serialized layout, runtime-facing behavior and preservation boundaries have terminal evidence states. Writer, retail NBZ and original-game acceptance remain separate capability gates.
What MOD research covers
- MOD is treated as a model-format research surface spanning structural records, mesh and vertex data, hierarchy or skinning information where canonical evidence supports those interpretations.
- The project keeps structural relationships separate from spatial, animation or rendering meanings that have not yet earned the same evidence level.
- Native Reader visibility is not used as shorthand for universal conversion or authoring support; those capabilities require their own proof and promotion gates.
Questions this entry point helps answer
- Which parts of a DMC3 MOD can be identified and represented without inventing semantics for unknown records?
- How are model hierarchy, mesh data and skinning-related structures separated in the canonical research model?
- Where should a tool or contributor check before claiming that a MOD field, transform or writer path is currently supported?
MOD reverse complete
- The DMC3 HD MOD reverse is complete for the canonical project scope: the serialized format, runtime-facing model contract and source-preservation boundaries all have terminal evidence states.
- Reverse complete does not mean every byte received a speculative artistic name. PRESERVED_UNDECODED, RESERVED_OBSERVED_ZERO and REJECTED are valid terminal outcomes where stronger semantics are not evidenced.
- The public MOD section therefore separates a completed reverse/reader contract from the still-bounded writer, archive reintegration and original-game acceptance programs.
Canonical MOD map
- The recovered contract covers the 0x40 document header, 0x40 object records, 0x50 mesh records, position/normal/fixed-point UV streams, blend indices, packed skin weights and topology control.
- Hierarchy/order, default-joint behavior, local/world transforms, inverse-rest/current-world skin palette construction, post-load relocation and generated topology workspace behavior are part of the canonical MOD runtime map.
- Texture-slot selection, GS CLAMP state, the external texture-companion/runtime-descriptor relationship, object runtime projection and the MOD-side MOT/CMotion boundary are also recovered without collapsing neighboring resource families into MOD.
Terminal preservation outcomes
- Header +0x14 is a runtime-carried u32 and the old universal decimal family/model/sub-index interpretation is rejected for MOD.
- BLENDINDICES.x remains a serialized ABI lane while the audited compiled shader path consumes Y/Z/W; source flag 0x00200000 is runtime-carried/restored without an invented artistic label.
- Mesh +0x38 is family-sensitive and inactive on the audited MOD path while its EFM homologue is live; mesh +0x0C/+0x4C and transform +0x1C retain explicit preservation contracts instead of being mislabeled as padding.
Writer and reintegration are separate gates
- Preserve-Layout Writer Gate 1 supports bounded fixed-size edits over an immutable source image, and the provenance-bound retail no-op corpus passes 38/38 files across 882,736 source bytes with exact byte parity and canonical reopen.
- One controlled retail bounding-radius edit changes exactly three authorized bytes, and the authored child has a provenance-bound real retail PNST reintegration receipt plus a synthetic MOD-to-NBZ overlay reopen gate.
- Typed-IR-only reflow, transform/skin/material/texture-companion authoring, provenance-bound retail NBZ acceptance and original dmc3.exe acceptance remain open authoring/integration work; they do not reopen the MOD reverse.
MOD at a glance
- Identifiers
- MOD
- Domain
- Geometry
Identity: EXE_CONFIRMEDPurpose: EXE_CONFIRMEDSchema: PARTIALProduct: recognized
MOD learning path
These lessons are the repository’s canonical learning material for this format. They follow the current reverse evidence rather than a simplified third-party schema.
02 — Document, objects and meshes
Walk through the canonical document/object/mesh contract, header boundaries, object state and preservation-aware mesh fields.
03 — Skeleton, hierarchy and transforms
Study parent/order topology, local/world transforms, inverse-rest relationships and the terminal preservation boundary for transform +0x1C.
04 — Skinning, topology and shader inputs
Follow packed influences and topology generation through the shader ABI, including BLENDINDICES Y/Z/W consumption and the preserved X lane.
05 — Textures and materials
Relate texture slots and companions to runtime material state and EXE-confirmed GS-facing selectors without inventing artistic categories.
06 — Animation and motion groups
Understand the recovered motion-group and MOD-side animation-binding boundary while keeping MOT/CMotion as its own authority.
07 — Related formats
Compare MOD with SCM, SHW, EFM, MOT, SO and texture companions so neighboring systems are not mistaken for unfinished MOD reverse.
08 — Evidence and terminal unknowns
Learn why preservation-only and rejected outcomes are valid terminal reverse states rather than invitations to invent semantics.
09 — Reverse workflow
Review the evidence workflow that closed MOD: raw bytes, executable evidence, corpus validation, hypothesis rejection, terminal classification and promotion.
10 — Exercises and debugging
Practice diagnosing offsets, counts, hierarchy relationships, transform mistakes and skin/topology problems using the completed canonical contract.
MOD glossary
Reference current MOD terminology, terminal evidence classes, runtime metadata, GS state selectors and skinning ABI.
MOD reference map
Jump from the completed MOD learning surface to canonical code, tests, research notes and evidence receipts.
Evidence boundary
A parser is not automatically a writer. A successful writer is not automatically equivalent to Capcom's offline tools. Synthetic validation does not establish original-game behavioral equivalence.
Use the current status for promoted capabilities and open proof gates.