OBD:M3GM: Difference between revisions

m
...
m (unfinished sentence)
m (...)
 
(6 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{OBD_File_Header | type=M3GM | prev=M3GA | next=Mtrl | name=Geometry | family=Generic | align=center}}
{{OBD_File_Header | type=M3GM | prev=M3GA | next=Mtrl | name=Geometry | family=General | align=center}}




Line 9: Line 9:
{{OBDtr|0x00|res_id  |FF0000|01 D7 00 00|215  | 00215-door_1_0.M3GM}}
{{OBDtr|0x00|res_id  |FF0000|01 D7 00 00|215  | 00215-door_1_0.M3GM}}
{{OBDtr|0x04|lev_id  |FFFF00|01 00 00 06|3    | level 3}}
{{OBDtr|0x04|lev_id  |FFFF00|01 00 00 06|3    | level 3}}
{{OBDtr|0x08|int32   |FFC8C8|00 00 00 00|0    | runtime only }}
{{OBDtr|0x08|uint32   |FFC8C8|00 00 00 00|0    | geometry flags; runtime only }}
{{OBDtr|0x0C|link    |FFFFC8|01 DA 00 00|218  | link to [[OBD:PNTA|00218-.PNTA]] (vertex XYZs) }}
{{OBDtr|0x0C|link    |FFFFC8|01 DA 00 00|218  | link to [[OBD:PNTA|00218-.PNTA]] (vertex XYZs) }}
{{OBDtr|0x10|link    |FFFFC8|01 F7 00 00|247  | link to [[OBD:VCRA|00247-.VCRA]] (vertex normals) }}
{{OBDtr|0x10|link    |FFFFC8|01 F7 00 00|247  | link to [[OBD:VCRA|00247-.VCRA]] (vertex normals) }}
Line 18: Line 18:
{{OBDtr|0x24|link    |FFFFC8|01 D8 00 00|216  | link to 00216-.[[OBD:TXMP|TXMP]] (texture) }}
{{OBDtr|0x24|link    |FFFFC8|01 D8 00 00|216  | link to 00216-.[[OBD:TXMP|TXMP]] (texture) }}
{{OBDtr|0x28|link    |C8FFC8|00 00 00 00|unused| obsolete GMAN (geometry animation) link; never used in Oni}}
{{OBDtr|0x28|link    |C8FFC8|00 00 00 00|unused| obsolete GMAN (geometry animation) link; never used in Oni}}
{{OBDtr|0x2C|char[20]|C8FFFF|AD DE      |dead  | unused}}
|}
|}


Line 50: Line 49:
{{OBDtr|0x00|res_id  |FF0000|01 63 00 00|99    | 00099-axes.M3GM}}
{{OBDtr|0x00|res_id  |FF0000|01 63 00 00|99    | 00099-axes.M3GM}}
{{OBDtr|0x04|lev_id  |FFFF00|01 00 00 00|0    | level 0}}
{{OBDtr|0x04|lev_id  |FFFF00|01 00 00 00|0    | level 0}}
{{OBDtr|0x08|int32   |FFC8C8|00 00 00 00|0    | runtime geometry flags (supposedly the same as for PC and Mac) }}
{{OBDtr|0x08|uint32   |FFC8C8|00 00 00 00|0    | runtime geometry flags (supposedly the same as for PC and Mac) }}
{{OBDtr|0x0C|int32   |FFC8C8|60 00 00 00|96    | number of faces (same as in second VCRA on PC and Mac) }}
{{OBDtr|0x0C|uint32   |FFC8C8|60 00 00 00|96    | number of faces (same as in second VCRA on PC and Mac) }}
{{OBDtr|0x10|int32   |FFFFC8|01 64 00 00|100  | link to [[OBD:PNTA|00100-.PNTA]] (vertex XYZs) }}
{{OBDtr|0x10|link   |FFFFC8|01 64 00 00|100  | link to [[OBD:PNTA|00100-.PNTA]] (vertex XYZs) }}
{{OBDtr|0x14|link    |FFFFC8|01 65 00 00|101  | link to [[OBD:TXCA|00101-.TXCA]] (vertex UVs) }}
{{OBDtr|0x14|link    |FFFFC8|01 65 00 00|101  | link to [[OBD:TXCA|00101-.TXCA]] (vertex UVs) }}
{{OBDtr|0x18|link    |FFFFC8|01 66 00 00|102  | link to [[OBD:IDXA_M3GM_1|00102-.IDXA]] (triangle strips) }}
{{OBDtr|0x18|link    |FFFFC8|01 66 00 00|102  | link to [[OBD:IDXA_M3GM_1|00102-.IDXA]] (triangle strips) }}
{{OBDtr|0x1C|int32   |FFC8C8|6C 00 00 00|108  | number of vertices (same as in PNTA and TXCA); also size of .raw part in bytes }}
{{OBDtr|0x1C|uint32   |FFC8C8|6C 00 00 00|108  | number of vertices (same as in PNTA and TXCA); also size of .raw part in bytes }}
{{OBDtr|0x20|offset  |FFFFC8|A0 8E 01 00| 0x00018EA0 | offset into the .raw file where the the 108 compressed vertex normals are stored:
{{OBDtr|0x20|offset  |FFFFC8|A0 8E 01 00| 0x00018EA0 | offset into the .raw file where the the 108 compressed vertex normals are stored:
  '''2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D F8 F8 C2 55'''
  '''2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D F8 F8 C2 55'''
Line 68: Line 67:
{{OBDtr|0x24|link    |FFFFC8|01 67 00 00|103  | texture link (to the empty 00103-_AXIS.[[OBD:TXMP|TXMP]]; the actually relevant 00104-_axis.TXMP is orphaned) }}
{{OBDtr|0x24|link    |FFFFC8|01 67 00 00|103  | texture link (to the empty 00103-_AXIS.[[OBD:TXMP|TXMP]]; the actually relevant 00104-_axis.TXMP is orphaned) }}
{{OBDtr|0x28|link    |C8FFC8|00 00 00 00|unused| supposedly the same GMAN link (geometry animation) as for PC and Mac }}
{{OBDtr|0x28|link    |C8FFC8|00 00 00 00|unused| supposedly the same GMAN link (geometry animation) as for PC and Mac }}
{{OBDtr|0x2C|char[20]|C8FFFF|AD DE      |dead  | unused}}
|}
|}
;OniBrowser being able to load PS2 M3GMs (a mystery of the modern times)
;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 with the first encountered instance of the matching type.
:Somehow OniBrowser is able to display M3GMs from PS2 instance files (except those with textures), even though all the links (PNТA, 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 with the first encountered instance of the matching type.
;Compressed vertex normals
;Compressed vertex normals
:It is somewhat uncommon to pack a normal vector into a single byte, but it turns out that there is a relatively straightforward way to subdivide the unit sphere into 256 sectors. One starts by splitting the sphere into four large quadrants (based on tetrahedral symmetry), and then each of the big "triangles" is subdivided into 4, then 16, then 64 smaller triangles, like [https://www.researchgate.net/publication/338662028/figure/fig8/AS:848495074349060@1579308398315/The-4-fold-tetrahedron-version-Discrete-Global-Grid-Systems-DGGSs-based-on-SACs-level_Q320.jpg this]. There is some distorsion near the four poles, but other than that it's a valid way to pack normals if space is an issue (if packing to 2 bytes or more, then one would typically work in plain spherical coordinates instead, i.e. azimuth and elevation).
[[Image:Four-fold tetrahedron.jpg|right|160px]]
:It is somewhat uncommon to pack a normal vector into a single byte, but it turns out that there is a relatively straightforward way to subdivide the unit sphere into 256 sectors. One starts by splitting the sphere into four large quadrants (based on tetrahedral symmetry), and then each of the big "triangles" is subdivided into 4, then 16, then 64 smaller triangles, like the picture to the right. There is some distortion near the four poles, but other than that it's a valid way to pack normals if space is an issue (if packing to 2 bytes or more, then one would typically work in plain spherical coordinates instead, i.e. azimuth and elevation).
:There isn't much of a point in giving a detailed description of the mapping here, but the basic idea would be to use the lowest 64 values for the first quadrant, the next 64 values for the second quadrant, etc. In actuality the PS2 implementation uses 63 for the first quadrant, 62 for the second, 63 for the third, and 68 for the last - for whatever reason. Within a quadrant the distribution isn't entirely regular, either. To be documented later if at all.
:There isn't much of a point in giving a detailed description of the mapping here, but the basic idea would be to use the lowest 64 values for the first quadrant, the next 64 values for the second quadrant, etc. In actuality the PS2 implementation uses 63 for the first quadrant, 62 for the second, 63 for the third, and 68 for the last - for whatever reason. Within a quadrant the distribution isn't entirely regular, either. To be documented later if at all.
;"Bad door lighting"
:When looking at the .raw part of the M3GM for some doors (level geometry), a striking observation is that there are only three distinct normal values (0xDE, 0x6A and 0x82), rather than the 6 normals that you'd expect for an axis-aligned box. Apparently half of those are bad, inward-pointing normals that no one ever bothered fixing. The regular VCRA normals for the same doors (on PC and Mac) are messed up in exactly the same way. Possibly this is related to the BSL variable '''door_pop_lighting''' ("uses bad door lighting").   
:When looking at the .raw part of the M3GM for some doors (level geometry), a striking observation is that there are only three distinct normal values (0xDE, 0x6A and 0x82), rather than the 6 normals that you'd expect for an axis-aligned box. Apparently half of those are bad, inward-pointing normals that no one ever bothered fixing. The regular VCRA normals for the same doors (on PC and Mac) are messed up in exactly the same way. Possibly this is related to the BSL variable '''door_pop_lighting''' ("uses bad door lighting").   




{{OBD_File_Footer | type=M3GM | prev=M3GA | next=Mtrl | name=Geometry | family=Generic | align=center}}
{{OBD_File_Footer | type=M3GM | prev=M3GA | next=Mtrl | name=Geometry | family=General | align=center}}


{{OBD}}
{{OBD}}
281

edits