-
Notifications
You must be signed in to change notification settings - Fork 43
Epic Mickey Display List format
Nif files from Epic Mickey for the Wii can contain NiMeshes that have their geometry data stored in a non-standard way.
Regular NiMeshes typically store the triangles in one datastream (either strips or loose triangles), and store the vertex information in one or more other datastreams, where there is an equal number of vertex positions, normals, vertex colors, UV coordinates or bone weights. So if there are 200 vertices, there are 200 position entries, 200 vertex normal entries, 200 color entries etc.
However, when there is a displaylist datastream (component semantics "DISPLAYLIST"), these are not guaranteed to be the same length and there is no triangle datastream. The displaylist datastream instead defines how each piece of information is linked and how the triangles are laid out. The displaylist is a series of bytes, which are all structured as command bytes followed by the associated information. Which commands are used and their content has two variations depending on whether the mesh is weighted or not.
Command (hex) / Component | Format | Explanation |
---|---|---|
0x90 | 90 CC CC | Triangles. The CC CC ushort defines the number of vertices, of which the format depends on the mesh. The triangles are defined in groups of three vertices. |
0x98 | 98 CC CC | Triangle Strip. The CC CC ushort defines the number of vertices, of which the format depends on the mesh. Note that, due to the format, every entry in this list is its own definition which can lead to shading problems (at least in Blender), because you can not detect degenerate triangles. In order to fix this, you can assume that every vertex which is defined the same refers to the same vertex. |
Vertex base info | AA [AA] BB [BB] CC [CC] DD [DD] | Indices into the various vertex-relevant information. These indices are all the same length (either byte or ushort). The best method so far to determine whether it is byte or ushort seems to be the length of the longest data array for vertex information. AA [AA] is an index into the position array. BB [BB] is an index into the normal array. CC [CC] is an index into the color array. DD [DD] is an index into the UV array. |
- Multiple 0x98 commands.
- Single 0x90 command.
Command (hex) / Component | Format | Explanation |
---|---|---|
Vertex | <Vertex base info> | A vertex here only contains indices into the base info. |
A weighted mesh seems to be divided into submeshes in the displaylist.
Multiple instances of the following structure:
- Up to 10 of the following structure:
- 0x20 command.
- 0xB0 command.
- 0x28 command.
- 0x84 command.
- Multiple 0x98 commands.
- Single 0x90 command.
Command (hex) / Component | Format | Explanation |
---|---|---|
0x20 | 20 AA AA | AA AA is likely a ushort index into the weights array of the owning NiMesh (NiMesh\Extra EM Data\Weights ). This is the same information as contained in the NiMesh\Extra EM Data\Partitions\Weight Indices . |
0xB0 | B0 AA | The meaning of AA is unknown. |
0x28 | 28 AA AA | AA AA is seemingly always the same as the preceding 0x20 command. |
0x84 | 84 AA | The meaning of AA is unknown. |
Vertex | AA BB <Vertex base info> | A vertex here contains both the base info, as well as two other fields preceding it. The AA and BB seem to always be the same. These appear to be indices into the (0x20, 0xB0, 0x28, 0x84) array, multiplied by 3. As such, they can be used to retrieve the weight (index). |