Q about triangles, strips and fans
Posted: Sun Jan 11, 2004 7:12 pm
While I've been analyzing the Carnivores model files, I noticed that the triangles are grouped to allow easily to use fans and/or strips to render them. Here's how the triangles aree stored:
point #1 (4-byte integer)
point #2 (4-byte integer)
point #3 (4-byte integer)
hor_tex_coord_1 (4-byte integer)
hor_tex_coord_2 (4-byte integer)
hor_tex_coord_3 (4-byte integer)
ver_tex_coord_1 (4-byte integer)
ver_tex_coord_2 (4-byte integer)
ver_tex_coord_3 (4-byte integer)
unknown value 1 (4-byte integer)
unknown value 2 (4-byte integer)
unknown index (4-byte integer)
unknown value 3 (4-byte integer, seems always 0)
unknown value 4 (4-byte integer, seems always 0)
unknown value 5 (4-byte integer, seems always 0)
unknown value 6 (4-byte integer, seems always 0)
The first 3 values are indexes to the points array, the next 6 are texture mapping coordinates for the three vertexes of the triangle; as textures are always 256 pixels wide, the coordinates are stored as integers in the range 0-255 (so 3 bytes are being wasted).
The unknown value 1 seems to be some sort of flag, since it's either 0 or a power of 4 (maybe a power of 2, but I need to examine more files); the unknown value 2 uses the full 4 bytes, and often it's some negative value (meaning it's &hFFFFFFxx). Maybe it's a compressed normal?
The unknown index is the one I'm more concerned about... Let's say there are N triangles in the model, then this index will be a number between -1 and N-1. Often there aren't any repeated values, but sometimes a value may be repeated once. Some of the indexes seem to point to the previous triangle (say, the index value for triangle i is i-1), but that isn't always the case. Any idea what this could be?
point #1 (4-byte integer)
point #2 (4-byte integer)
point #3 (4-byte integer)
hor_tex_coord_1 (4-byte integer)
hor_tex_coord_2 (4-byte integer)
hor_tex_coord_3 (4-byte integer)
ver_tex_coord_1 (4-byte integer)
ver_tex_coord_2 (4-byte integer)
ver_tex_coord_3 (4-byte integer)
unknown value 1 (4-byte integer)
unknown value 2 (4-byte integer)
unknown index (4-byte integer)
unknown value 3 (4-byte integer, seems always 0)
unknown value 4 (4-byte integer, seems always 0)
unknown value 5 (4-byte integer, seems always 0)
unknown value 6 (4-byte integer, seems always 0)
The first 3 values are indexes to the points array, the next 6 are texture mapping coordinates for the three vertexes of the triangle; as textures are always 256 pixels wide, the coordinates are stored as integers in the range 0-255 (so 3 bytes are being wasted).
The unknown value 1 seems to be some sort of flag, since it's either 0 or a power of 4 (maybe a power of 2, but I need to examine more files); the unknown value 2 uses the full 4 bytes, and often it's some negative value (meaning it's &hFFFFFFxx). Maybe it's a compressed normal?
The unknown index is the one I'm more concerned about... Let's say there are N triangles in the model, then this index will be a number between -1 and N-1. Often there aren't any repeated values, but sometimes a value may be repeated once. Some of the indexes seem to point to the previous triangle (say, the index value for triangle i is i-1), but that isn't always the case. Any idea what this could be?