OBD:M3GM: Difference between revisions
Jump to navigation
Jump to search
(fixing up a few things; investigation ongoing) |
mNo edit summary |
||
| Line 39: | Line 39: | ||
:Geometry animation worked in a way similar to texture animation, by picking M3GMs from an array (GMAN) and displaying them at a specified frame rate, optionally with randomization. | :Geometry animation worked in a way similar to texture animation, by picking M3GMs from an array (GMAN) and displaying them at a specified frame rate, optionally with randomization. | ||
---- | |||
;PS2 implementation | ;PS2 implementation | ||
:PS2 M3GMs have the same data size as PC and Mac ones (0x24 bytes of actual data, 0x2C if counting the instance and level IDs), but the layout is different. Normals aren't stored at all, hence both VCRA and the second IDXA are simply missing. Instead the M3GM explicitly stores the number of vertices (i.e., the array size common to PNTA and TXCA), as well as another vertex count (not fully understood). There is also a mysterious .raw part (also not documented yet). | :PS2 M3GMs have the same data size as PC and Mac ones (0x24 bytes of actual data, 0x2C if counting the instance and level IDs), but the layout is different. Normals aren't stored at all, hence both VCRA and the second IDXA are simply missing. Instead the M3GM explicitly stores the number of vertices (i.e., the array size common to PNTA and TXCA), as well as another vertex count (not fully understood). There is also a mysterious .raw part (also not documented yet). | ||
Revision as of 13:03, 16 November 2022
|
|
| Offset | Type | Raw Hex | Value | Description |
|---|---|---|---|---|
| 0x00 | res_id | 01 D7 00 00 | 215 | 00215-door_1_0.M3GM |
| 0x04 | lev_id | 01 00 00 06 | 3 | level 3 |
| 0x08 | int32 | 00 00 00 00 | 0 | runtime only |
| 0x0C | link | 01 DA 00 00 | 218 | link to 00218-.PNTA (vertex XYZs) |
| 0x10 | link | 01 F7 00 00 | 247 | link to 00247-.VCRA (vertex normals) |
| 0x14 | link | 01 F0 00 00 | 240 | link to 00240-.VCRA (face normals) |
| 0x18 | link | 01 ED 00 00 | 237 | link to 00237-.TXCA (vertex UVs) |
| 0x1C | link | 01 0C 01 00 | 268 | link to 00268-.IDXA (triangle strips) |
| 0x20 | link | 01 11 01 00 | 273 | link to 00273-.IDXA (face normal assignment) |
| 0x24 | link | 01 D8 00 00 | 216 | link to 00216-.TXMP (texture) |
| 0x28 | link | 00 00 00 00 | unused | obsolete GMAN (geometry animation) link; never used in Oni |
| 0x2C | char[20] | AD DE | dead | unused |
- Vertices
- XYZ and UV coordinates are stored in parallel (same number of entries in PNTA and TXCA).
- Vertex normals
- The first VCRA stores the normals for every vertex (same entries as in PNTA and TXCA).
- Vertex normals are used by Gouraud shading (directional lighting).
- Face normals
- The second VCRA stores the normals for every face (groups defined by the second IDXA).
- Face normals are used for backface culling.
- Triangle strips
- The first IDXA lists the triangles as strips. The IDs are the ones in PNTA and IDXA.
- The start of a new strip is signaled by a high bit in the ID of its first vertex.
- Strips are more optimal for rendering, they are generated when authoring an M3GM.
- Face groupings
- The second IDXA groups the triangles into faces (oriented by the second VCRA).
- Geometry animation
- Geometry animation worked in a way similar to texture animation, by picking M3GMs from an array (GMAN) and displaying them at a specified frame rate, optionally with randomization.
- PS2 implementation
- PS2 M3GMs have the same data size as PC and Mac ones (0x24 bytes of actual data, 0x2C if counting the instance and level IDs), but the layout is different. Normals aren't stored at all, hence both VCRA and the second IDXA are simply missing. Instead the M3GM explicitly stores the number of vertices (i.e., the array size common to PNTA and TXCA), as well as another vertex count (not fully understood). There is also a mysterious .raw part (also not documented yet).
- An an example, consider M3GMaxes of level0_Final.
| Offset | Type | Raw Hex | Value | Description |
|---|---|---|---|---|
| 0x00 | res_id | 01 63 00 00 | 99 | 00099-axes.M3GM |
| 0x04 | lev_id | 01 00 00 00 | 0 | level 0 |
| 0x08 | int32 | 00 00 00 00 | 0 | runtime geometry flags (supposedly the same as for PC and Mac) |
| 0x0C | int32 | 60 00 00 00 | 96 | number of actual vertices? (see discussion below) |
| 0x10 | int32 | 01 64 00 00 | 100 | link to 00100-.PNTA (vertex XYZs) |
| 0x14 | link | 01 65 00 00 | 101 | link to 00101-.TXCA (vertex UVs) |
| 0x18 | link | 01 66 00 00 | 102 | link to 00102-.IDXA (triangle strips) |
| 0x1C | int32 | 6C 00 00 00 | 108 | number of vertices (same as in PNTA and TXCA); also size of .raw part in bytes |
| 0x20 | offset | A0 8E 01 00 | 0x00018EA0 | offset into the .raw file, purpose unknown (first 108 bytes shown in bold)
2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D F8 F8 C2 55 40 40 10 D4 D4 09 C2 5F 6B 6B 6B 6B 6B 6B 6B 6B 6B 82 82 D9 16 E3 E3 00 EB EB 6D 6D 6D 6D 6D 6D 6D 6D 6D 6D AB AB EB 80 52 FC 95 30 30 EA EA EA EA EA A7 A7 24 EA EA EA EA 24 02 02 02 A7 A7 A7 A7 EF EA EA EA EA 02 02 02 02 24 24 24 24 F8 2D 2D 2D 2D A7 A7 A7 A7 EA EA EA EA 16 02 02 02 02 After looking at PS2's implementation of TXMP, it is a fair assumption that they are color indices, but then it is unclear what palette is referenced (grayscale?)
|
| 0x24 | link | 01 67 00 00 | 103 | texture link (to the empty 00103-_AXIS.TXMP; the actually relevant 00104-_axis.TXMP is orphaned) |
| 0x28 | link | 00 00 00 00 | unused | supposedly the same GMAN link (geometry animation) as for PC and Mac |
| 0x2C | char[20] | AD DE | dead | unused |
Even without a full understanding of the .raw part, the handling of normals and the vertex count at 0x0C, the current knowledge is sufficient to extract M3GM data from PS2 resources and even to export it to other formats (with missing or autogenerated normals).
- OniBrowser being able to load PS2 M3GMs (a mystery of the modern times)
- Somehow OniBrowser is able to display M3GMs from PS2 instance files (except those with textures), even though all the links (PTNA, TXCA, IDXA) are in the wrong positions. Apparently, in the case of M3GM, OniBrowser reads in all the fields past 0x0C as a bunch of non-typed instance links, then identifies their types and populates the PNTA, VCRA, TXCA and IDXA references as soon (or as late) as a matching type is encountered.
- Number of actual vertices (0x0C)
- For low-poly meshes this vertex count corresponds to the number or individual XYZ coordinate meshes, i.e., the number of "actual" vertices or "control points", regardless of texture coordinates on adjacent faces. Thus this number is systematically 8 for cube-like meshes, 12, for a two-segment square tube, etc. However, for higher-poly meshes (e.g., character body parts), the vertex count at 0x0C actually exceeds the PNTA/TXCA count, possibly indicating that vertices with split normals (at sharp edges) are counted several times. This number isn't directly tied to other resources, so its meaning can only be deduced from a more careful/massive analysis of meshes.
- Packed normals?
- Regarding the bytes in the .raw file and how they could be packed normals (e.g., in spherical coordinates) - these days normals are packed into no less that 2 bytes, but Oni's lighting is lackluster overall, so maybe drastically compressed normals were deemed sufficient. The analysis of box-like door meshes M3GMsphere (and maybe some pipes from a level's "furniture") should be able to clarify the format completely.
| ONI BINARY DATA |
|---|
| M3GA << Other file types >> Mtrl |
| M3GM : Geometry |
| Generic file |