nvm

He means that the values you got are absolute pixel coordinates, meaning that you need to convert them to uv coordinates ex. If the texture is 256 wide, and you pixel coordinate is 160 then the uv coordinate is 160/256 = 0,625 T. yes sure I understand that, but the values I posted (100, 0; 160, 0 e...

fatduck wrote:absolute pixel coordinate, mate!

I'm not sure I understand what you mean:

F4 38 00 00 7A 1C 00 00 = 14580, 7290
D0 C6 3B 00 7A 1C 00 00 = 3917520, 7290

How do I get to 100, 0 and 160, 0 from there ? its not even proporsional

Gave it another shot today, been focusing on UVs. I know where they are and I have these UVs for the face of the "inside" of the chest: F4 38 00 00 7A 1C 00 00 D0 C6 3B 00 7A 1C 00 00 D0 C6 3B 00 68 E3 1D 00 F4 38 00 00 68 E3 1D 00 I've also managed to extract the texture: http://s24.posti...

Hello, I'm looking for info on Wipeout 1 (1995) and found this very useful website http://rewiki.regengedanken.de/wiki/Wipeout , it seems the regular models are stored in the PRM files but the track models however are in .TRF (for track faces), TRV (track vertices) and the textures are in TIM files ...

I'm trying to understand the 057f and 067f sections and things are getting very tricky :evil: . For TREASURE.CHR it's quite simple: TREASURE.CHR, 057f: 0: 0, 0, 0 1: 0, 80, -50 2: 0, 0, 100 and the 067f: 3576 3578 3577 The values above are submesh IDs, when offsetting the submeshes in this order, re...

Continuing research... I've tidied up my (incomplete) CHR specification if anyone wants to have a look at the format. Consists of chunks and subchunks, with 4 bytes for the chunk ID, 4 bytes for the chunk size and the next bytes for the chunk data. 0x8000: Root chunk +4 long chunk size 0x18000: unkn...

I have a very weak 3d background, but is what you're telling me related to this http://www.misfitcode.com/misfitmodel3d/olh_jointdetails.html ? A bone joint is is an object that forms one part of a model's skeletal structure. The root bone joint has no parent joint, all other joints have one parent....

TaylorMouse wrote:I think the MeshIndex x y z refers to bones?

T.

ty for help. Btw sry for my ignorance but is bone description alone sufficient to place the cover over the chest or eg a foot at the end of a leg?

Yes, the chest has an animation. Idont know anything about bones however... do u know some tut that explains what it is and/or what to look for when reversing them? Its so annoying to be so close and still not be able to understand how the damn format works. Actually the section I do not understand ...

I've confirmed my assumptions that the floats towards the end are used for placement of the parts by replacing each of those floats by 0 and looking at how the game reacts. With all floats at 0, the chest parts are misplaced. Now it's only a matter of figuring out how those coordinates are used.

Okay, I spent the last weekend studying the format and here are my notes: OFFSET TYPE COMMENT 20 long N 32 + N long # of chunks (model parts) in this file 44 + N long first chunk size in bytes (add 8 bytes to include up to this byte) 60 + N long first chunk vertice count (V) 64 + N long first chunk ...

edit: nvm I made a mistake in my previous post, corrected it, I'll try out your suggestion TaylorMouse

Thanks Shakotay, I've also been frustrated by face count but I think they're not triangles, they seem to be polygons, because if you start at offset 367, you have this structure: (8 bytes ??) 0 0 33 0 1 0 33 0 6 0 33 0 5 0 33 0 (8 bytes ??) 1 0 34 0 2 0 34 0 7 0 34 0 6 0 34 0 (8 bytes ??) 2 0 34 0 3...

ok, I've confirmed the first floats in the float array are the vertices, I've plotted the vertices from CHEESE.CHR (see attachment). The remaining floats in the chunk must be the UV. Now on to find faces
edit: also found vertice count