Sonic Heroes/Collision Format
From Sonic Retro
Revision as of 13:28, 19 June 2017 by Igorseabra4 (talk | contribs)
| 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. They use a quadtree based system to optimize collision detection. 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.
Format is only partly known.
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 // UNKNOWN FIRST SECTION // This section is a list of triangles which comes right after the header. Its function is unknown. Not all triangles of the level are referenced here, but getting rid of this section makes the entire level unsolid. // 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) uint16 // right neighbour uint16 // left neighbour uint16 // bottom neighbour uint16 // top neighbour uint16 // ? uint16 // ? uint16 // ? uint16 // positioning offset value #1 (left/right) uint16 // positioning offset value #2 (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 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. // The quadtree is laid out from a top-down view of the level, (right side being towards positive X and bottom towards positive Z). Y values are ignored (including the one on the header) as the tree is 2-dimensional. // TRIANGLE SECTION // Triangle entry (0x20 bytes, repeats the amount of times set in the header): uint16 // vertex1 index uint16 // vertex2 index uint16 // vertex3 index uint16 // adjacent triangle 1 index uint16 // adjacent triangle 2 index uint16 // adjacent triangle 3 index float32 // probably vertex normals float32 // probably vertex normals float32 // probably vertex normals int8[4] // col flags int8[4] // col flags (2) // adjacent triangle 1: vertex1 of current triangle is vertex3 of adjacent; vertex2 of current triangle is vertex2 of adjacent // adjacent triangle 2: vertex2 of current triangle is vertex1 of adjacent; vertex3 of current triangle is vertex3 of adjacent // adjacent triangle 3: vertex1 of current triangle is vertex1 of adjacent; vertex3 of current triangle is vertex2 of adjacent // adjacent triangle index is FF FF if it doesn't exist // VERTEX SECTION // Vertex entry (0x0C bytes, repeats the amount of times set in the header): 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).