Dreamcast Grave robbing Geist Force
- Thread starter Sifting
- Start date
- Thread Author
- #22
Warning: nerd stuff ahead!
I've learnt some more neat things about how geometry was stored. Models are broken down into meshes, each mesh has one material. Each mesh is composed of one or more triangle strips, which are sorted by increasing order. The highbit is set on the final vertex to denote the end of a strip. Each vertex references a point in an array stored at the end of the model file, and also defines UV and colour data. For some reason, it appears colour data is stored in both argb8888 and float32 formats, on the same vertex:
Unsure why they did this. It does pad out each vertex to a nice 32 bytes though.
After the vertices, a list of what I presume are per face normals follows, as the count is the same as the number of faces in the mesh, then a list of vertex normals follows after that. The fact the normals are written separately when they could have been placed where the float32 colour values exist, is quite bizarre!
That all said, I haven't really found any bounding volumes. The models have what looks like one at the end of the file, but they're always set to +/- 10000, which can't be right. So unless they're hidden somewhere else, or generated at run time, then it's fair to speculate that the game might use per polygon hit detection, which would explain why they write out per face normals. It would also mean the game might not do any frustum culling on objects... both taken together would account for a lot of the speed problems.
Another unfortunate decision goes back to how the triangle strips themselves are stored. There are quite a few instances of strips with only one or two faces in each mesh, which means they each generate a draw call. The more draw calls, the less your frame rate in simple terms. Contrast this with Agartha, which batched all one and two triangle strips together into separate 'triangle' and 'quad' groups to reduce the number of calls needed.
Still though, the game was going to be a launch title. It's interesting to see these kinds of pitfalls, and how they were avoided by developers later on in the system's life.
I've learnt some more neat things about how geometry was stored. Models are broken down into meshes, each mesh has one material. Each mesh is composed of one or more triangle strips, which are sorted by increasing order. The highbit is set on the final vertex to denote the end of a strip. Each vertex references a point in an array stored at the end of the model file, and also defines UV and colour data. For some reason, it appears colour data is stored in both argb8888 and float32 formats, on the same vertex:
Code:
point, flags, uv, argb8888, a, r, g, b
54,1728(0) : 0.26,0.48 : FFCCCCCC : 1.00,0.80,0.80,0.80
23,736(0) : 0.23,0.53 : 00000000 : 0.00,0.00,0.00,0.00
7,224(0) : 0.21,0.47 : FFCCCCCC : 1.00,0.80,0.80,0.80
65,2080(32768) : 0.19,0.60 : FFCCCCCC : 1.00,0.80,0.80,0.80
tris: 2
Code:
Sega.MMat
12
0,0(0) : 0.50,0.01 : FFFFFFFF : 1.00,1.00,1.00,1.00
2,64(0) : 0.63,0.01 : FFFFFFFF : 1.00,1.00,1.00,1.00
1,32(0) : 0.50,0.20 : FFFFFFFF : 1.00,1.00,1.00,1.00
3,96(32768) : 0.63,0.20 : FFFFFFFF : 1.00,1.00,1.00,1.00
tris: 2
4,128(0) : 0.01,0.64 : FFFFFFFF : 1.00,1.00,1.00,1.00
6,192(0) : 0.99,0.64 : FFFFFFFF : 1.00,1.00,1.00,1.00
5,160(0) : 0.01,0.95 : FFFFFFFF : 1.00,1.00,1.00,1.00
7,224(32768) : 0.99,0.95 : FFFFFFFF : 1.00,1.00,1.00,1.00
tris: 2
8,256(0) : 0.01,0.39 : FFFFFFFF : 1.00,1.00,1.00,1.00
10,320(0) : 0.93,0.39 : FFFFFFFF : 1.00,1.00,1.00,1.00
9,288(0) : 0.01,0.62 : FFFFFFFF : 1.00,1.00,1.00,1.00
11,352(32768) : 0.93,0.62 : FFFFFFFF : 1.00,1.00,1.00,1.00
tris: 2
faces: 6
punk
0 -0.00 -0.00 -0.00
1 -0.00 -0.00 -0.00
2 -0.00 -0.00 -0.00
3 -0.00 -0.00 -0.00
4 -0.00 -0.00 -0.00
5 -0.00 -0.00 -0.00
normals
0 0.00 0.00 1.00
1 0.00 0.00 1.00
2 0.00 0.00 1.00
3 0.00 0.00 1.00
4 0.00 0.00 1.00
5 0.00 0.00 1.00
6 0.00 0.00 1.00
7 0.00 0.00 1.00
8 0.00 0.00 1.00
9 0.00 0.00 1.00
10 0.00 0.00 1.00
11 0.00 0.00 1.00
points
0 -19.56, -16.00, -0.29
1 -19.56, 19.18, -0.29
2 23.43, -16.00, -0.29
3 23.43, 19.18, -0.29
4 -11.76, -0.23, 0.00
5 -11.76, 3.74, 0.00
6 0.47, -0.23, 0.00
7 0.47, 3.74, 0.00
8 0.59, -0.25, 0.00
9 0.59, 2.67, 0.00
10 12.21, -0.25, 0.00
11 12.21, 2.67, 0.00Unsure why they did this. It does pad out each vertex to a nice 32 bytes though.
After the vertices, a list of what I presume are per face normals follows, as the count is the same as the number of faces in the mesh, then a list of vertex normals follows after that. The fact the normals are written separately when they could have been placed where the float32 colour values exist, is quite bizarre!
That all said, I haven't really found any bounding volumes. The models have what looks like one at the end of the file, but they're always set to +/- 10000, which can't be right. So unless they're hidden somewhere else, or generated at run time, then it's fair to speculate that the game might use per polygon hit detection, which would explain why they write out per face normals. It would also mean the game might not do any frustum culling on objects... both taken together would account for a lot of the speed problems.
Another unfortunate decision goes back to how the triangle strips themselves are stored. There are quite a few instances of strips with only one or two faces in each mesh, which means they each generate a draw call. The more draw calls, the less your frame rate in simple terms. Contrast this with Agartha, which batched all one and two triangle strips together into separate 'triangle' and 'quad' groups to reduce the number of calls needed.
Still though, the game was going to be a launch title. It's interesting to see these kinds of pitfalls, and how they were avoided by developers later on in the system's life.
- Joined
- May 31, 2019
- Messages
- 398
- Reaction score
- 320
- Points
- 63
Cheers man. I hope to have a look through that this weekend.
- Joined
- Jul 10, 2019
- Messages
- 56
- Reaction score
- 19
- Points
- 8
Great read, thank you for working on this!