Sonic Heroes/Collision Format
From Sonic Retro
|SCHG: Sonic Heroes|
::::Object Parameter Data
Relocatable Editing (PC)
Texture Animation Editing
|Custom Object Material Effect Tutorial|
Level Editing 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, 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.
// HEADER (0x28 bytes) uint32 // total number of bytes in file uint32 // quadtree section offset uint32 // triangle section offset uint32 // vertex section offset float32 // X, Y, Z center of quadtree float32 // size of quadtree uint16 // base power (see quadtree section) 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. // All neighbours of a node must be of the same depth level, or higher in case the neighbouring node is not subdivided. // 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 2^(base power-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 number for the base power is set in the file header, and the depth level is set in each quadtree node entry. // The exception is the root node with depth level 0, which has 0 for both positioning offset values. // 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 // vertex index 1, 2, 3 (counterclockwise) uint16 // adjacent triangle index 1, 2, 3 float32 // 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 // col flags // adjacent triangles share 2 of their vertices. If it doesn't have all 3, index is 0xFFFF // VERTEX SECTION // Vertex entry (0x0C bytes): float32 // X, Y, Z position
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).