TresCom Forums

TresCom : The Trespasser Fan Gateway...
It is currently Mon Jun 25, 2018 3:23 pm

All times are UTC




Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Jan 09, 2004 4:02 am 
Offline
T-Rex Killer
T-Rex Killer
User avatar

Joined: Thu Apr 24, 2003 11:20 pm
Posts: 10781
Location: Lima, Peru
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?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 09, 2004 3:45 pm 
Offline
Pteranodon
Pteranodon

Joined: Sun Nov 10, 2002 10:46 pm
Posts: 867
Location: Finding a way into the TCOps Forum...
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 09, 2004 3:50 pm 
Offline
T-Rex Killer
T-Rex Killer
User avatar

Joined: Thu Apr 24, 2003 11:20 pm
Posts: 10781
Location: Lima, Peru
Yes, more or less... it's used to determine collisions in a simple way, if I'm not mistaken.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 09, 2004 4:21 pm 
Offline
-=TresCom Developer=-
-=TresCom Developer=-

Joined: Mon Jul 22, 2002 12:35 pm
Posts: 1845
Location: Holland, Europe
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...

_________________
http://www.bytehazard.com


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 09, 2004 4:47 pm 
Offline
T-Rex Killer
T-Rex Killer
User avatar

Joined: Thu Apr 24, 2003 11:20 pm
Posts: 10781
Location: Lima, Peru
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 09, 2004 6:49 pm 
Offline
-=TresCom Developer=-
-=TresCom Developer=-

Joined: Mon Jul 22, 2002 12:35 pm
Posts: 1845
Location: Holland, Europe
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

_________________
http://www.bytehazard.com


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 10, 2004 3:08 am 
Offline
Pteranodon
Pteranodon

Joined: Sun Nov 10, 2002 10:46 pm
Posts: 867
Location: Finding a way into the TCOps Forum...
(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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 10, 2004 10:45 am 
Offline
-=TresCom Developer=-
-=TresCom Developer=-

Joined: Mon Jul 22, 2002 12:35 pm
Posts: 1845
Location: Holland, Europe
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. :)

_________________
http://www.bytehazard.com


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jan 10, 2004 7:53 pm 
Offline
T-Rex Killer
T-Rex Killer
User avatar

Joined: Thu Apr 24, 2003 11:20 pm
Posts: 10781
Location: Lima, Peru
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).


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jan 11, 2004 1:43 am 
Offline
Pteranodon
Pteranodon

Joined: Wed Sep 10, 2003 11:18 pm
Posts: 983
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


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jan 11, 2004 6:21 pm 
Offline
T-Rex Killer
T-Rex Killer
User avatar

Joined: Thu Apr 24, 2003 11:20 pm
Posts: 10781
Location: Lima, Peru
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?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jan 11, 2004 9:26 pm 
Offline
-=TresCom Developer=-
-=TresCom Developer=-

Joined: Mon Jul 22, 2002 12:35 pm
Posts: 1845
Location: Holland, Europe
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).

_________________
http://www.bytehazard.com


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jan 12, 2004 1:15 am 
Offline
T-Rex Killer
T-Rex Killer
User avatar

Joined: Thu Apr 24, 2003 11:20 pm
Posts: 10781
Location: Lima, Peru
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jan 12, 2004 10:13 am 
Offline
-=TresCom Developer=-
-=TresCom Developer=-

Joined: Mon Jul 22, 2002 12:35 pm
Posts: 1845
Location: Holland, Europe
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.

_________________
http://www.bytehazard.com


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 12, 2004 5:20 pm 
Offline
T-Rex Killer
T-Rex Killer
User avatar

Joined: Thu Apr 24, 2003 11:20 pm
Posts: 10781
Location: Lima, Peru
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...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

Powered by phpBB® Forum Software © phpBB Group