Difference between revisions of "Sonic Heroes/Collision Format"
From Sonic Retro
Igorseabra4 (talk | contribs) |
Igorseabra4 (talk | contribs) |
||
| Line 1: | Line 1: | ||
{{SCHG SH}} | {{SCHG SH}} | ||
| − | Level collision in Sonic Heroes is defined in big endian .cl files located in dvdroot/collisions in the PC version. These files are not RenderWare collision files and are the same between different versions of the game | + | Level collision in Sonic Heroes is defined in big endian .cl files located in dvdroot/collisions in the PC version. These files are not RenderWare collision files and are the same between different versions of the game. s*.cl files contain normal level collision, s*_xx.cl files contain collision for death boundaries and s*_wt.cl files contain water boundaries. The s*.cl file is required for the level to load but the others are not, and also they can be placed in levels which did not originally have them. |
| − | + | The game uses a [https://en.wikipedia.org/wiki/Quadtree quadtree] based system to optimize collision detection: a square plane is drawn over a top-down 2D projection of the stage (thus ignoring the Y axis). This square is subdivided into 4 squares of the same size. Each square which has a collidable mesh inside of it will be again subdivided into 4 same-sized children. This is repeated usually 9 or 10 times for most main level models (and 2 or 3 for xx and wt), thus creating a maximum of 4^9 or 4^10 squares (the actual number is much smaller as most squares don't have anything in them). Each quadtree node will reference a small list of triangles. When inside that node's range, the player and objects' position will be checked for collision only against those triangles, thus optimizing the collision detection. Not using the quadtree will slow down game performance by a large amount. Each triangle has individual collision flags and a normal unit vector. The maximum number of vertices, triangles and quadtree nodes is 0xFFFF each. | |
== File Format == | == File Format == | ||
| Line 20: | Line 20: | ||
// TRIANGLE LIST SECTION | // TRIANGLE LIST SECTION | ||
| − | // This section is a list of triangles which comes right after the header. Each entry is | + | // This section is a list of triangles which comes right after the header, starting at offset 0x28. Each entry is a word (0x02 bytes) long, containing zero-based indicies referencing the triangle section. This list is referenced by the quadtree by offset to know which triangles are inside each node. Due to that, there is no pointer/offset to this section in the header (and the amount of entries can pass 0xFFFF). |
// QUADTREE SECTION | // QUADTREE SECTION | ||
| Line 26: | Line 26: | ||
uint16 // index | uint16 // index | ||
uint16 // parent | uint16 // parent | ||
| − | uint16 // child (index of first child in the group of four) | + | uint16 // child (index of first child in the group of four, 0 if no child) |
| − | uint16 // right neighbour | + | uint16 // right neighbour, 0 if edge of level |
| − | uint16 // left neighbour | + | uint16 // left neighbour, 0 if edge of level |
| − | uint16 // bottom neighbour | + | uint16 // bottom neighbour, 0 if edge of level |
| − | uint16 // top neighbour | + | uint16 // top neighbour, 0 if edge of level |
uint16 // number of triangles in node | uint16 // number of triangles in node | ||
uint32 // offset to triangle list for this node (relative to start of file) | uint32 // offset to triangle list for this node (relative to start of file) | ||
| − | uint16 // positioning offset value | + | uint16 // positioning offset value (left/right) |
| − | uint16 // positioning offset value | + | uint16 // positioning offset value (top/bottom) |
uint8 // depth level (parent's depth level+1) | uint8 // depth level (parent's depth level+1) | ||
uint8 // null | uint8 // null | ||
| Line 41: | Line 41: | ||
// The nodes are laid out in groups of four; if a node has children, then it necessarily has four; the index in the parent's entry is the index of the first (top left) child. The order of the children is always top left, top right, bottom left, bottom right. | // The nodes are laid out in groups of four; if a node has children, then it necessarily has four; the index in the parent's entry is the index of the first (top left) child. The order of the children is always top left, top right, bottom left, bottom right. | ||
| − | // This is how positioning offset values work: all four nodes of the 4-sibling group take their values initially from their parent. Then, a factor of (0x2000/2^(depth level)) is added to the first value on the second and fourth nodes (which are the right ones), and the same factor is added to the second value on the third and fourth nodes (which are the bottom ones). Note that the first (top left) node keeps the same values from the parent. | + | // This is how positioning offset values work: all four nodes of the 4-sibling group take both their values initially from their parent. Then, a factor of (0x2000/2^(depth level)) is added to the first value on the second and fourth nodes (which are the right ones), and the same factor is added to the second value on the third and fourth nodes (which are the bottom ones). Note that the first (top left) node keeps the same values from the parent. |
| − | // | + | // Right side is towards positive X and bottom towards positive Z. Y values are ignored (including the one on the header) as the grid is 2-dimensional. |
// TRIANGLE SECTION | // TRIANGLE SECTION | ||
| − | // Triangle entry (0x20 bytes | + | // Triangle entry (0x20 bytes): |
| − | uint16 // | + | uint16[3] // vertex index 1, 2, 3 (counterclockwise) |
| − | + | uint16[3] // adjacent triangle index 1, 2, 3 | |
| − | + | float32[3] // normal unit vector X, Y, Z (can be calculated by doing [https://en.wikipedia.org/wiki/Cross_product cross product] of vectors vertex(2-1) and vertex(3-1) and then dividing each value by the vector's norm) | |
| − | uint16 // adjacent triangle 1 | + | int8[8] // col flags |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | int8[ | ||
| − | |||
| − | // adjacent triangle 1: vertex1 of current triangle is vertex3 of adjacent; vertex2 of current triangle is vertex2 of adjacent | + | // adjacent triangle 1: vertex1 of current triangle is vertex3 of adjacent; vertex2 of current triangle is vertex2 of adjacent (unsure) |
| − | // adjacent triangle 2: | + | // adjacent triangle 2: vertex3 of current triangle is vertex1 of adjacent; vertex2 of current triangle is vertex2 of adjacent (unsure) |
| − | // adjacent triangle 3: vertex1 of current triangle is vertex1 of adjacent; vertex3 of current triangle is vertex2 of adjacent | + | // adjacent triangle 3: vertex1 of current triangle is vertex1 of adjacent; vertex3 of current triangle is vertex2 of adjacent (unsure) |
// adjacent triangle index is FF FF if it doesn't exist | // adjacent triangle index is FF FF if it doesn't exist | ||
// VERTEX SECTION | // VERTEX SECTION | ||
| − | // Vertex entry (0x0C bytes | + | // Vertex entry (0x0C bytes): |
float32[3] // X, Y, Z position | float32[3] // X, Y, Z position | ||
Revision as of 00:43, 20 June 2017
| SCHG: Sonic Heroes |
|---|
| Main Article |
| Mechanic Editing |
|
DOL Editing |
| Model Editing |
| Collision Format Model Format |
| Level Editing |
|
Camera Editing |
| Particle Editing |
| Particle Editing |
| Sound Editing |
| Music List |
| SCHG How-Tos |
|
Custom Object Material Effect Tutorial |
Level collision in Sonic Heroes is defined in big endian .cl files located in dvdroot/collisions in the PC version. These files are not RenderWare collision files and are the same between different versions of the game. s*.cl files contain normal level collision, s*_xx.cl files contain collision for death boundaries and s*_wt.cl files contain water boundaries. The s*.cl file is required for the level to load but the others are not, and also they can be placed in levels which did not originally have them.
The game uses a quadtree based system to optimize collision detection: a square plane is drawn over a top-down 2D projection of the stage (thus ignoring the Y axis). This square is subdivided into 4 squares of the same size. Each square which has a collidable mesh inside of it will be again subdivided into 4 same-sized children. This is repeated usually 9 or 10 times for most main level models (and 2 or 3 for xx and wt), thus creating a maximum of 4^9 or 4^10 squares (the actual number is much smaller as most squares don't have anything in them). Each quadtree node will reference a small list of triangles. When inside that node's range, the player and objects' position will be checked for collision only against those triangles, thus optimizing the collision detection. Not using the quadtree will slow down game performance by a large amount. Each triangle has individual collision flags and a normal unit vector. The maximum number of vertices, triangles and quadtree nodes is 0xFFFF each.
File Format
// HEADER (0x28 bytes) uint32 // total number of bytes in file uint32 // quadtree section offset uint32 // triangle section offset uint32 // vertex section offset float32[3] // X, Y, Z center of quadtree float32 // size of quadtree uint16 // unknown // 0x01 for xx/wt, 0x0C or Ox0D for stages uint16 // number of triangles uint16 // number of vertices uint16 // number of quadtree nodes // TRIANGLE LIST SECTION // This section is a list of triangles which comes right after the header, starting at offset 0x28. Each entry is a word (0x02 bytes) long, containing zero-based indicies referencing the triangle section. This list is referenced by the quadtree by offset to know which triangles are inside each node. Due to that, there is no pointer/offset to this section in the header (and the amount of entries can pass 0xFFFF). // QUADTREE SECTION // This section is a list of quadtree nodes. Each entry is 0x20 bytes long and the amount of entries is set in the header. uint16 // index uint16 // parent uint16 // child (index of first child in the group of four, 0 if no child) uint16 // right neighbour, 0 if edge of level uint16 // left neighbour, 0 if edge of level uint16 // bottom neighbour, 0 if edge of level uint16 // top neighbour, 0 if edge of level uint16 // number of triangles in node uint32 // offset to triangle list for this node (relative to start of file) uint16 // positioning offset value (left/right) uint16 // positioning offset value (top/bottom) uint8 // depth level (parent's depth level+1) uint8 // null uint16 // null uint32 // null
// The nodes are laid out in groups of four; if a node has children, then it necessarily has four; the index in the parent's entry is the index of the first (top left) child. The order of the children is always top left, top right, bottom left, bottom right. // This is how positioning offset values work: all four nodes of the 4-sibling group take both their values initially from their parent. Then, a factor of (0x2000/2^(depth level)) is added to the first value on the second and fourth nodes (which are the right ones), and the same factor is added to the second value on the third and fourth nodes (which are the bottom ones). Note that the first (top left) node keeps the same values from the parent. // Right side is towards positive X and bottom towards positive Z. Y values are ignored (including the one on the header) as the grid is 2-dimensional. // TRIANGLE SECTION // Triangle entry (0x20 bytes): uint16[3] // vertex index 1, 2, 3 (counterclockwise) uint16[3] // adjacent triangle index 1, 2, 3 float32[3] // normal unit vector X, Y, Z (can be calculated by doing cross product of vectors vertex(2-1) and vertex(3-1) and then dividing each value by the vector's norm) int8[8] // col flags // adjacent triangle 1: vertex1 of current triangle is vertex3 of adjacent; vertex2 of current triangle is vertex2 of adjacent (unsure) // adjacent triangle 2: vertex3 of current triangle is vertex1 of adjacent; vertex2 of current triangle is vertex2 of adjacent (unsure) // adjacent triangle 3: vertex1 of current triangle is vertex1 of adjacent; vertex3 of current triangle is vertex2 of adjacent (unsure) // adjacent triangle index is FF FF if it doesn't exist // VERTEX SECTION // Vertex entry (0x0C bytes): float32[3] // X, Y, Z position
Collision Flags
These are probably set at bit level, each byte with a different meaning, but here they are presented as 4 bytes. They are guesses and the list might be wrong and incomplete.
- 00 00 00 00 - Floor (normal)
- 00 00 00 01 - Floor (grass offroad)
- 00 00 00 02 - Water boundary
- 00 00 00 10 - Floor (sand)
- 00 00 00 20 - Floor (grass road)
- 00 00 00 80 - Floor (rock)
- 00 00 01 00 - Wall
- 00 00 01 80 - Wall (rock)
- 00 00 04 00 - Floor (carpet staircase)
- 00 00 80 00 - Wall (invisible barriers)
- 00 01 00 00 - Death boundary
- 00 04 00 80 - Wall (pinball table and bingo slide)
- 00 08 00 00 - Wall
- 40 00 00 00 - Bingo slide
- 80 00 00 00 - Pinball table
Remember this is still a Sonic game, so these types of surfaces probably help the physics engine decide what to do, but of course you can walk on walls given you have enough speed. Same applies to vertical floors being the same as walls (all of Test Level's collision model is type 00 00 00 00).