05-03-24, 08:15 | #1 |
Member
Joined: Jan 2018
Posts: 1,283
|
TRG File Format (Tomb Raider I-III Remastered)
This file seems to be keeping the modern geometry data for levels. I tried to see if I can make an import/export script for this. Managed to figure out some but kind of stuck at the moment so I'll share my findings and take a break from this.
TRG files start with a marker then contain lighting, some unknown, texture, indice & vertex data. Values are Little Endian and there's zero padding for 4 byte alignment when necessary. MAIN LAYOUT: Code:
uint32 trg3 // "TRG\x03" format marker uint32 num_lightings uint32 lightings[num_lightings * 24] // 24 bytes each, 6 RGBA colors uint8 unknown[*] // Variable size unknown area uint32 num_textures uint16 textures[num_textures] // DDS texture IDs // zero padding for 4 byte alignment uint32 num_indices uint32 num_vertices uint32 indices[num_indices] Vertex vertices[num_vertices] // 20 bytes each These seem to be 6 colors for each 3D cardinal directions. When I turned first color into red and the rest 5 into zeros for every 24 byte block at once, I got red light from a direction on objects (like Lara and Doors). Zeroed the first one back and set second light to some color and objects started getting light from a different direction and so on. I don't know why these are so high in number. Perhaps they calculated light from 6 sides for each individual block? Needs more experimenting with. UNKNOWN AREA: I couldn't find a way to reliably determine the size of this area to at least skip over. Perhaps it's room coordinates or some kind of point/spot lights system that has coordinates. Needs a lot of figuring out. It might be dependant on some outside value, like a num_rooms value from PDP or PHD files. (maybe even .TEX files but they don't seem to be used. I suspect they might be development files forgotten, I delete/rename .tex files and the game still seems to run normally) What I currently do is examine the file from backwards to determine where the vertex data begins (they have a visual pattern in Hex Editor). Then I take the size of the data and divide it by 20 (per vertex) to determine num_vertices. Then I search for num_vertices in the file to spot the position of num_indices & num_vertices. Right before them is the texture data, again easy to notice in hex editor. TEXTURE IDs: Textures are easy. Notice most textures are in TEX folders as DDS files and have numbers as names. Here's a list of uint16s that correspond to those filenames. UINT16 gives us 65536 possibilities, game uses about 9000. This makes one consider using higher numbers for modding purposes but they don't seem to work. Also there're unused texture numbers below 9000. Some modders tried using them instead but reported having issues. The safest way is just replacing existing textures, whichever textures the TRG you're modding is using, replace those. (Don't forget zero padding after this list for 4 byte alignment) INDICES & VERTICES: Finally, what makes up the 3D geometries. First we have indices and vertices counts together. Once you got those, indices are easy. Just uint32 for each indice. 3 of them make 1 triangle (or polygon, or face). (Notice it's uint32 unlike TRM Data where it's uint16 because levels have much more vertices than objects) VERTEX STRUCTURE: Code:
Vertex { // 20 bytes int16 x, y, z // the usual x, y, z coordinates int16 unknown1 // mostly zero but there are exceptions uint8 normal[3] // each x, y, z component 1 byte uint8 texture // order in textures list, starting from 1 uint8 unknown2[3] // ? uint8 u // horizontal UV uint8 unknown3[3] // ? uint8 v // vertical UV, might appear upside down } Normal components seem in the range 1-253. I'm guessing values 0, 254 & 255 are used for representing -+Infinity & NaN values. The formula explained here helps converting these to floats. Code:
x = x - 127; y = y - 127; z = z - 127; length = math.sqrt((x * x) + (y * y) + (z * z)) x /= length; y /= length; z /= length; Unknowns are not necessarily zero. The structure here is similar to TRM but I don't think these are joint/weight data. U component of UV data. I convert U to float simply by dividing it with 255. Yes, there're 3 bytes in between UV values for some reason, not necessarily zero. Finally V component of UV data. Again divide it by 255 to convert to float. This so far needs to be flipped with (1.0 - float) because UVs end up upside down. Last edited by MuruCoder; 05-03-24 at 09:12. |
05-03-24, 10:12 | #2 |
Member
Joined: Feb 2008
Posts: 4,246
|
Exciting stuff!
I would think there might be some confusion on the texture data for room geometry as it would (probably) be similar to a Tomb Engine/Tomb Editor method where custom UV mapped room geometry overlaps original editor blocks textured to be transparent in order to allow better texturing while keeping the original collision. |
05-03-24, 11:02 | #3 |
Member
Joined: Feb 2024
Posts: 108
|
Nice. I'm not good with level editor but it would be cool to see new levels made with the remastered graphics. TEN engine is the closest thing to these graphics. It seems to me that there were already methods to import models in game, even if very few people used them
|
05-03-24, 11:18 | #4 | |
Member
Joined: Feb 2008
Posts: 4,246
|
Quote:
Porting for TRNG and below though wil require retopology to keep tex infos at bay as the polycount is a bit high. |
|
07-03-24, 01:55 | #5 |
Member
Joined: Jun 2007
Posts: 26,910
|
Some textures seem to have some sort of parallax occlusion type effect. Maybe that's what the extra UV info is for?
|
17-03-24, 23:52 | #6 |
Member
Joined: Mar 2024
Posts: 1
|
Chatgpt and i are gonna take a crack at this tonight
|
Yesterday, 06:54 | #7 |
Member
Joined: Jan 2018
Posts: 1,283
|
I think unknown data has Shader info similar to TRMs, I managed to parse certain files (just skipping over unknown data) but does not fit all so still needs work.
Maybe. They could also be for vertex colors, to use as static lighting. |
Thread Tools | |
|
|