Another modeling riddle...

Discuss Programming / Linux questions.

Moderators: scallenger, Sky, TresCom Support Team

User avatar
T-Rex Killer
T-Rex Killer
Posts: 12315
Joined: Thu Apr 24, 2003 11:20 pm
Location: Lima, Peru

Post by machf »

There is another type of file which shares several things in common with the objects within the resource files, except for having a simpler header lacking the first 64 bytes (those values I was wondering about when I started this thread).Two of those files, which contain the models for the sun and moon, and except for the texture are identical, happen to be very short, and as such, ideal for further study. Here is their structure:


Code: Select all

05 00 00 00  04 00 00 00  01 00 00 00  00 00 02 00
which corresponds to
# of vertices (4-byte integer)
# of triangles (4-byte integer)
# of bones (4-byte integer)
texture length in bytes (4-byte integer)

or in this case, replacing the values:
5 vertices, 4 triangles, 1 bone, 131072 bytes texture (width is always 256 pixels and it uses 16bpp, so that makes it 256x256x2 bytes, or 256 pixels tall)

Next comes the data for the triangles, the structure is the one mentioned in this other post

Given that the last 16 bytes for every triangle seem to always be zero, I'll just list the decimal values for the other ones, in the order (vertA, vertB, vertC), [(A_hor, B_hor, C_hor), (A_ver, B_ver, C_ver)], flags, unknown (normal?), parent triangle

Triangle 0: (4, 0, 3), [(128, 253, 253), (128, 3, 253)], 0, 68 {=&h00000044}, 3
Triangle 1: (4, 3, 1), [(128, 253, 3), (128, 253, 253)], 0, -46 {=&hFFFFFFD2}, -1
Triangle 2: (4, 1, 2), [(128, 3, 3), (128, 253, 3)], 0, -68 {=&hFFFFFFBC}, 1
Triangle 3: (4, 2, 0), [(128, 3, 253), (128, 3, 3)], 0, 46 {=&h0000002E}, 2

Next come the vertices, which have a 16-byte structure like this:
Xcoord (4-byte float)
Ycoord (4-byte float)
Zcoord (4-byte float)
bone (4-byte integer)

The corresponding decimal values for all 5 vertices are:
Vertex 0: (384.19043, 384.19043, 0), 0
Vertex 1: (-384.19043, -384.19043, 0), 0
Vertex 2: (-384.19043, 384.19043, 0), 0
Vertex 3: (384.19043, -384.19043, 0), 0
Vertex 4: (0, 0, 0), 0

Next, the info corresponding to the bones. Since there is a single bone and the first 48 bytes are used to store a zero-padded string with the name of the bone, which in this case is "Sun " for both files (yes, on the moon it is labeled "Sun " too), I will just show the last 16 bytes, which are:

Code: Select all

00 00 00 00   00 00 00 00  00 00 00 00  FF FF 00 00
Those values correspond to
Xcoord (4-byte float)
Ycoord (4-byte float)
Zcoord (4-byte float)
parent bone (2-byte integer)
unknown (2-byte integer) (seems always 0)

Or, for the current values:

Bone 0: (0, 0, 0), -1, 0

And finally, the texture data (in this case, as already established, 131072 bytes long). This is the only part that's different in both files.

I'm showing here two JPEG versions of the textures, with the corresponding mapping coordinates for the triangles and vertices marked over them by me.

Moon texture
Sun texture

Could you help me guess what the unknown value in the triangles may be?
-=TresCom Developer=-
-=TresCom Developer=-
Posts: 1845
Joined: Mon Jul 22, 2002 12:35 pm
Location: Holland, Europe

Post by Remdul »

Ok, let me just organize stuff for myself, lets just jot it down as a C struct;

Code: Select all

struct triangle {
 // vertex indices
 long vert1;
 long vert2;
 long vert3;
 // texcoords
 long texh1;
 long texh2;
 long texh3;
 long texv1;
 long texv2;
 long texv3;

 // unknown
 long unknown1;
 long unknown2;

 long weirdindex;
 long unknown3;
 long unknown4;
 long unknown5;
 long unknown6;

struct float3 {
 float x;
 float y;
 float z;

struct skinnedvert {
 float3 pos;
 int boneindex;

struct bone {
 char[48] name;
 float3 pos;
 int parent;
 int unknown;

struct model {
 long vertnum;
 long trinum;
 long bonenum;
 long texlen;
 triangle tris[];
 float3 verts[];
 bone bones[];

 // texture data goes here
Still thinking. I think the texture coordinates are stored a little inefficently. And then there's some other stuff. Hmm...

Edit: typo.
Last edited by Remdul on Wed Aug 25, 2004 10:09 am, edited 1 time in total.
User avatar
T-Rex Killer
T-Rex Killer
Posts: 12315
Joined: Thu Apr 24, 2003 11:20 pm
Location: Lima, Peru

Post by machf »

Given that I haven't seen any textures bigger than 256x256, storing the coordinates as 4-byte integers is inefficient. Maybe they started with floats, then decided to switch to integers to make computations faster but kept the size... (they've done it with RGB values too)

That "weirdindex" value is always either pointing to another triangle or -1. I'm guessing it's some kind of "parent" index as sometimes there's more than one (so far, I haven't seen more than two) pointing to the same.

The first unknown is a set of flags, as I may have mentioned... the second one puzzles me, as the values can be either poistive or negative integers, I've seen as high as 612 (&h020A). The symmetry in this example leads me to conclude they are not RGBA values. And they can't be indexes, as the values are beyond the number of either triangles or vertices. They could somehow be face normals, though as you mentioned, that wouldn't be too useful (except, of course, for static objects - and in the case of the animals, well, I guess that pose corresponds to how they appear in the trophy room - the animation frames don't store anything else than compressed vertex coordinates).

Thanks again.
Post Reply