TresCom Forums

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?

Hmm, are you sure those texture coordinates range from 0-255? It is possible, but texcoords are almost always stored as floating point values, ranging from 0 to 1, but can also be negative (mirrored textures) or larger (tiled texture).

Other data looks interesting, but my brain is a little soft tonight, will take a look at it tomorrow...

_________________
http://www.bytehazard.com

Yes, I've verified that they are texture coordinates. As I said, textures are limited to 256 pixels in width, so there's no need to use a float value between 0.0 and 1.0 and map it to the actual dimensions of the textures (calculating U*width and V*height), just take the actual integer values... I think the use of integers in several parts of the 3D models may be what makes this game faster than other similar ones...

As I said, it's that index value which currently puzzles me. Could it somehow be used in the formation of strips/fans? Or just to indicate which triangles should be rendered first?

"unknown value1" is some collection of flags, apparently (though it seems that not all bits are being used). "unknown index" is a pointer to a "parent" triangle of sorts, but as I've already said, I don't know what use that may have... "unknown values 3-6" seem to be just unused/always zero. That leaves "unknown value 2". My guess is that it may be the one holding information on triangle normals...

Interesting case here.

Especially "unknown index" is strange. I can't think of any value having something to do with face count. But like you suggested, it might very well have something to do with the order of drawing. However, most of the time that is done on the fly ("z-sorting" or "depth-sorting"), since your point of view may vary.

However, the idea of triangle strips, fans etc. is that the data is in the right order already. You just send vertex after vertex, and thats it (see http://bruno.cicv.fr/etudes/rsc/OpenGL. ... l-wv-2.png ). But as the data here includes 3 vertex indices, its most likely that this case involves just regular triangles.

I'd also suspect vertex normals in there, are you sure that none of the values range [-1,1]? Or at least an index to a normal array. You'll need a structure of 3 32-bit floats, allthough it can also be stored in 16-bit, or even 3 bytes (like its done these days in normal maps). Idealy, you have a seperate array of vertex normals, which can be shared by multiple vertices (for example, a heavily subdivided cube would need only 6 normals, one for each side). But it's not uncommon to store normals along with vertices, e.g.;



A face(t) normal could also go per face data, but I can't think of a reason to do that, calculating vertex normals on the fly is very expensive, and flat shaded triangles obviously look like crap.

Another thing that could be in there are vertex colors (3 bytes per vertex if done efficiently), perhaps even an 1-byte index per vertex to a palette containing vertex colors.

Also, per face you can expect an index to a material. Could one of the the last values be an index to a material? Often a model may have only one material, and be zero because of that.

_________________
http://www.bytehazard.com