Another modeling riddle...

Discuss Programming / Linux questions.

Moderators: scallenger, Sky, TresCom Support Team

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

Another modeling riddle...

Post by machf »

OK, here are some other number sequences... It seems to me they are bounding sphere and/or box definitions, but I'd like to hear what you think. They are all part of the models headers in the objects chunk of a level resource file. The headers are each 80 bytes in total, apparently representing 20 4-byte integers. The last 4 indicate the number of points in the object mesh, the number of triangles, the number of "components" or sub-assemblies it is divided into, and the size in bytes of the associated texture... so it's the previous 16 values which are unknown.

Apparently, value #1 is the bounding sphere radius, values #2, 3 and 4 are some sort of X, Y and Z coordinates (maybe the center?) and values #5, 6 and 7 another set of X, Y and Z coordinates (bounding box dimensions?). Value #8 is mostly the same in all, with a few exceptions, and value #9 is mostly zero, with a few exceptions too. Values #10-16 seem to be always zero.

Here are few examples: (I'm listing only values 1-9 in each case)

From the resource file Area4.rsc:

bush6a: 0, 0, 111, 0, 16, 200, 16, 18, 0
bush7a: 0, 0, 126, 0, 16, 200, 16, 18, 0
tree4b: 64, 0, 826, 0, 16, 200, 16, 18, 64
tree5a: 64, 0, 744, 0, 16, 200, 16, 18, 64
bush2c: 0, 0, 132, 0, 16, 200, 16, 18, 0
bush5b: 0, 0, 137, 0, 16, 200, 16, 18, 0
bush3c: 0, -1, 153, 0, 16, 200, 16, 18, 0
gbush2b: 0, 0, 146, 0, 16, 200, 16, 18, 0
bush4c: 0, 0, 82, 0, 16, 200, 16, 18, 0
tree3b: 64, 0, 288, 0, 16, 200, 26, 18, 64
gbush1b: 0, 2, 135, 0, 16, 200, 16, 18, 32 (no, it doesn't mean "George Bush"...)

From the resource file Area2.rsc (some objects are also present in Area4.rsc; an * denotes which values of the same object are different in both files):

palm1f: 64, 0, 674, 0, 16, 200, 16, 18, 0
gbush1b: 0, 1*, 135, 0, 16, 200, 16, 18, 0*
stone1: 128, 1, 55, 0, 16, 200, 16, 18, 0
palm2d: 64, 0, 284, 0, 16, 200, 16, 18, 0
palm4b: 64, 0, 694, 0, 16, 200, 32, 18, 0
palm3c: 128, 1, 40, 0, 16, 200, 16, 18, 0
br: 128, 1, 59, 0, 16, 200, 16, 20, 0
br3: 128, -11, 59, 0, 16, 200, 16, 20, 0
gbush2b: 0, 0, 70*, 0, 16, 200, 16, 18, 0
pbush1: 0, -3, 58, 0, 16, 200, 16, 18, 0
bush2c: 0, 0, 132, 0, 0*, 0*, 0*, 18, 0
bush2b: 0, 0, 132, 0, 0, 0, 0, 18, 0
bush3a: 0, 0, 127, 0, 16, 200, 16, 18, 0
bush3c: 0, -1, 153, 0, 16, 200, 16, 18, 0
bush4c: 0, 0, 82, 0, 0*, 0*, 0*, 18, 0
3leafs: 128, -12, 79, 0, 16,200, 16, 18, 0
pbush: 0, -3, 58, 0, 16, 200, 16, 18, 0
tree3a: 128, 0, 288, 0, 16, 200, 16, 18, 0
tree4a: 128, 0, 826, 0, 16, 200, 16, 18, 0
bush5a: 128, 0, 137, 0, 16, 200, 16, 18, 0
bush5b: 128*, 0, 137, 0, 16, 200, 16, 18, 0
bush6a: 0, 0, 111, 0, 16, 200, 16, 18, 0


So, any ideas?
the ARK
Pteranodon
Pteranodon
Posts: 867
Joined: Sun Nov 10, 2002 10:46 pm
Location: Finding a way into the TCOps Forum...
Contact:

Post by the ARK »

A bounding box sets the physical limits of a model, right?
This is truly one of the most disappointing moments in gaming history. Gamers are being reduced to digging through the game's installed files to discover what was supposed to happen in the game they just bought.
User avatar
machf
T-Rex Killer
T-Rex Killer
Posts: 12368
Joined: Thu Apr 24, 2003 11:20 pm
Location: Lima, Peru
Contact:

Post by machf »

Yes, more or less... it's used to determine collisions in a simple way, if I'm not mistaken.
Remdul
-=TresCom Developer=-
-=TresCom Developer=-
Posts: 1845
Joined: Mon Jul 22, 2002 12:35 pm
Location: Holland, Europe

Post by Remdul »

Yes, bounding boxes/spheres are often used for collision detection, or to speed it up if whatever is inside the box/sphere is subdivided into other volumes. Is very often used for frustum culling also.

I'm not entirely sure they could be used for bounding boxes since you say they are integer values (it'd store them as floats). You can do a lot more with floating point values than integers when it comes to geometrical data.
Do those values still make sense if you read them as floating point values?

One of those values could be the bounding box, but you usually have a min x,y,z and a max x,y,z measured from the center or pivot. But since your values vary from file to file they might be totally different things.

Just guessing here...

I think the best way to figure out what those values mean is to alter them and see what happens in-game. Although in this case it is hard to see what actually changes, since they could indeed be bounding volumes which are invisible...
User avatar
machf
T-Rex Killer
T-Rex Killer
Posts: 12368
Joined: Thu Apr 24, 2003 11:20 pm
Location: Lima, Peru
Contact:

Post by machf »

No, they are very visible, fortunately... trees, bushes, rocks and other objects in the levels. When I altered the first value, it wouldn't let me approach (at ground level) the object beyond a certain radius, from any direction... I could enable cheats and take a long jump and land on top of it and literally walk on the air over the area around the object.

Guesses are just what I need.
I know usually bounding boxes are stored as a min and a max set of values, but this doesn't seem to be the case here... Hence my guess that it may be the center and the dimensions of the box around it.

As for the values being integers instead of floats... well, these are just static objects, so maybe that's the reason not to have more precision (although a 4-byte float would occupy the same space).
The actual coordinates for each object's points, OTOH, are store as 4-byte floats... I only wish I were able to render them in 3-D, to see if the (supposed) box 'fits' around the object.
Remdul
-=TresCom Developer=-
-=TresCom Developer=-
Posts: 1845
Joined: Mon Jul 22, 2002 12:35 pm
Location: Holland, Europe

Post by Remdul »

What I meant is that bounding boxes themselves are invisible.

About the float/int thing; yeah I pretty much go used to accurate collision detection, but you are correct that these values can be integers. But if it takes the same amount of bytes to store them as floats they might just as well done that, like you said can't say for sure.

Don't know anything about that game, can't help you any further than this I'm afraid.

However, I uploaded this prog I made while I was trying to hack the JPOG TMD format, it reads the file as an array of floats and renders them as dots in 3d. There are slider bars which allow you to seperate data (changes dot colors) which gives you the (approximate) offset from the start from the file. Its horrible and buggy, but I always found it helpfull to visualize file data, so you can recognise re-occuring data structures easier. If you would open a 3d geometry file with this app you'll see rows of dots going up diagonally (triangles' vertex/normal/texcoord indices), vertex positions show the contours of models and normals show up as a sphere.

Anyhow; maybe it can be of any help for you. Just dump your selected data into a fresh file, save that and open it on my prog.

http://home.planet.nl/~buijs512/_temp/tmdview.zip
the ARK
Pteranodon
Pteranodon
Posts: 867
Joined: Sun Nov 10, 2002 10:46 pm
Location: Finding a way into the TCOps Forum...
Contact:

Post by the ARK »

(Are you still working on the TMD format?)
This is truly one of the most disappointing moments in gaming history. Gamers are being reduced to digging through the game's installed files to discover what was supposed to happen in the game they just bought.
Remdul
-=TresCom Developer=-
-=TresCom Developer=-
Posts: 1845
Joined: Mon Jul 22, 2002 12:35 pm
Location: Holland, Europe

Post by Remdul »

Nope, not at all actually. Andres created the import script so I didn't feel the need to hack it anymore. Andres was just quicker with those things than I was. :)
User avatar
machf
T-Rex Killer
T-Rex Killer
Posts: 12368
Joined: Thu Apr 24, 2003 11:20 pm
Location: Lima, Peru
Contact:

Post by machf »

Well, thanks Remdul, I downloaded your little app and will be trying it later as you suggested (right now I tried opening a complete file, but it's just too messy).
Lou-saydus
Pteranodon
Pteranodon
Posts: 983
Joined: Wed Sep 10, 2003 11:18 pm

Post by Lou-saydus »

Oh, hey Remdul you should still work on the tmd scripts, Andres did a good job really quick, but they have lots of bugs. I would really appreciate it if you continue. J
User avatar
machf
T-Rex Killer
T-Rex Killer
Posts: 12368
Joined: Thu Apr 24, 2003 11:20 pm
Location: Lima, Peru
Contact:

Post by machf »

Here's another bit of data which may be useful... bush6a and tree4b share the same texture and their overall form is the same, only that tree4b is obviously taller, meaning that it has a longer trunk...

Remdul, I tried you app, only it seems it takes a different number of values, as some points are correctly drawn, but others are drawn along the wrong axis (meaning that it's reading X, Y, Z for some of them but for others it's taking Y, Z, X and/or Z, X, Y)...

The mesh points are stored like this:
X coordinate (4-byte float)
Y coordinate (4-byte float)
Z coordinate (4-byte float)
component index (4-byte integer)

The last value indicates to which 'sub-assembly' of the model the point belongs... I'm guessing your app is trying to interpret that value as another coordinate and then it takes a value close to 0.

BTW, how do I get an idea of the scale/coordinates in the app?
Remdul
-=TresCom Developer=-
-=TresCom Developer=-
Posts: 1845
Joined: Mon Jul 22, 2002 12:35 pm
Location: Holland, Europe

Post by Remdul »

Well, actually the app does nothing special. It reads the data as 4-byte floating points. But if there's say 1,2 or 3 bytes before the data it reads (and displays it incorrectly). So integer values, bytes in blocks of 4 and any other type are still interpreted as floating point values (since there's no way to figure out how to interpret it other than assuming they are floats).

That also explains the scale thing, there basicly is no scale. You can zoom in/out btw by dragging while the right mouse button is pressed...

* Oh, I believe Y is up and Z the viewing direction (default startup orientation).
User avatar
machf
T-Rex Killer
T-Rex Killer
Posts: 12368
Joined: Thu Apr 24, 2003 11:20 pm
Location: Lima, Peru
Contact:

Post by machf »

Oh, by 'scale' I just meant a way to know what the actual coordinates of a given point may be... after all, there's a grid there, but I have no idea what the distance between grid lines is.
Remdul
-=TresCom Developer=-
-=TresCom Developer=-
Posts: 1845
Joined: Mon Jul 22, 2002 12:35 pm
Location: Holland, Europe

Post by Remdul »

Have no idea either. :lol:

But I think the grid spacing is 10, well at least it is in my basecode and the app was build from that...

You can actually figure that out yourself by putting a single floating point value in a file, load that an compare it with the grid spacing.
User avatar
machf
T-Rex Killer
T-Rex Killer
Posts: 12368
Joined: Thu Apr 24, 2003 11:20 pm
Location: Lima, Peru
Contact:

Post by machf »

machf wrote: The mesh points are stored like this:
X coordinate (4-byte float)
Y coordinate (4-byte float)
Z coordinate (4-byte float)
component index (4-byte integer)

The last value indicates to which 'sub-assembly' of the model the point belongs... I'm guessing your app is trying to interpret that value as another coordinate and then it takes a value close to 0.
Here's something more about this, that "component index" seems to actually be a "bone (or joint) index". Apparenty, they used a bone structure when making the models and animating them, but then for the actual 3d model files they didn't store the bones themselves, just the indexes, and used compressed vertices for each animation keyframe (maybe that's faster to render and requires fewer calculations than storing the bone positions and extrapolating from there?). Only 'static' models (objects like trees, bushes, rocks, but also the moon/sun, game compass, binoculars) kept the original bone information within their files...
Post Reply