| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| trs:meshes_models [2017/06/04 21:40] – [TR4-5 Entity Structure] zdimension | trs:meshes_models [2021/02/09 16:08] (current) – [Meshes] stohrendorf |
|---|
| | {{indexmenu_n>4}} |
| | |
| ====== Meshes and Models ====== | ====== Meshes and Models ====== |
| |
| { | { |
| tr_vertex Centre; | tr_vertex Centre; |
| int32_t CollRadius; | int16_t CollRadius; |
| | uint16_t Flags; // 0x01 for Flat Shaded, i.e. Normals should not affect lighting |
| |
| int16_t NumVertices; // Number of vertices in this mesh | int16_t NumVertices; // Number of vertices in this mesh |
| }; | }; |
| </code> | </code> |
| ''%%Centre%%'' is usually close to the mesh’s centroid, and appears to be the center of a sphere used for certain kinds of collision testing. | ''%%Centre%%'' is usually close to the mesh’s centroid, and is the center of a sphere used for certain kinds of collision testing. |
| |
| ''%%CollRadius%%'' appears to be the radius of that aforementioned collisional sphere. | ''%%CollRadius%%'' is the radius of that aforementioned collisional sphere. |
| |
| ''%%NumNormals%%'': If positive, it is a number of normals in this mesh. If negative, it is a number of vertex lighting elements (''%%abs%%'' value). | ''%%NumNormals%%'': If positive, it is a number of normals in this mesh. If negative, it is a number of vertex lighting elements (''%%abs%%'' value). |
| ''%%VisibilityBox%%'' and ''%%CollisionBox%%'' boundaries is always stay axis aligned even after applying tr_room_staticmesh::Rotation (always have 90 degrees step). Additionally, the test whether to rotate the box or not relies on the mesh’s rotation being an exact multiple of 0x4000 (aka 90 degrees). If this is not the case, the box is not rotated, which results in wrong collision checks. | ''%%VisibilityBox%%'' and ''%%CollisionBox%%'' boundaries is always stay axis aligned even after applying tr_room_staticmesh::Rotation (always have 90 degrees step). Additionally, the test whether to rotate the box or not relies on the mesh’s rotation being an exact multiple of 0x4000 (aka 90 degrees). If this is not the case, the box is not rotated, which results in wrong collision checks. |
| |
| {{:icons:tr1.png?nolink|TR1 only}}{{:icons:tr2.png?nolink|TR2 only}} ''%%Flags%%'' value is usually 2, and is 3 for static meshes //without collision//, like plants and lying skeletons. Since TR3, value is ignored, and no-collision mode is obtained using degenerate collision box (with all-zero or all-one coordinates). | {{:icons:tr1.png?nolink|TR1 only}}{{:icons:tr2.png?nolink|TR2 only}}{{:icons:tr3.png?nolink|TR3 only}} ''%%Flags%%'': |
| | * **Bit 0** (''0x0001''): no collision |
| | * **Bit 1** (''0x0002''): is visible |
| |
| ===== Models ===== | ===== Models ===== |
| struct tr_sprite_texture // 16 bytes | struct tr_sprite_texture // 16 bytes |
| { | { |
| uint16_t Tile; | uint16_t Atlas; |
| uint8_t x; | uint8_t x; |
| uint8_t y; | uint8_t y; |
| }; | }; |
| </code> | </code> |
| {{:icons:tr4.png?nolink|TR4 only}}{{:icons:tr5.png?nolink|TR5 only}} ''%%x%%'' and ''%%y%%'' values //are not used// in this version. Additionally, formula for ''%%Width%%'' and ''%%Height%%'' is changed: now it’s $(\text{ActualWidth} - 1) \times 256$ and $(\text{ActualHeight} - 1) \times 256$ respectively. | {{:icons:tr4.png?nolink|TR4 only}}{{:icons:tr5.png?nolink|TR5 only}} ''%%x%%'' and ''%%y%%'' values //are not used// in this version. Additionally, formula for ''%%Width%%'' and ''%%Height%%'' is changed: now it’s $(\text{ActualWidth} - 1) \cdot 256$ and $(\text{ActualHeight} - 1) \cdot 256$ respectively. |
| |
| ===== Sprite Sequences ===== | ===== Sprite Sequences ===== |
