Tomb Raider Forums  

Go Back   Tomb Raider Forums > Tomb Raider Level Editor and Modding > Tomb Raider Level Editor

Reply
 
Thread Tools
Old 05-03-24, 08:15   #1
MuruCoder
Member
 
MuruCoder's Avatar
 
Joined: Jan 2018
Posts: 1,283
Default 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
LIGHTINGS DATA:

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
}
Once again unlike TRM format, the X, Y, Z coordinates are int16s. Similar to old editor, 1024 is block size therefore seems like -32000 and 32000 are the ranges for room geometry. I also think positive integers are used for blocks so 32x32 blocks maximum (or even 31x31). You can't model a big map with these alone, there needs to be some room data that helps shifting these around.

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;
Texture byte is pointing into the texture IDs list above, but starts from 1 not the usual 0. Vertices of the same face/polygon seem to point to the same texture, naturally.

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.
MuruCoder is offline   Reply With Quote
Old 05-03-24, 10:12   #2
Heckler
Member
 
Heckler's Avatar
 
Joined: Feb 2008
Posts: 4,246
Default

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.
Heckler is online now   Reply With Quote
Old 05-03-24, 11:02   #3
Jiraz
Member
 
Jiraz's Avatar
 
Joined: Feb 2024
Posts: 108
Default

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
Jiraz is offline   Reply With Quote
Old 05-03-24, 11:18   #4
Heckler
Member
 
Heckler's Avatar
 
Joined: Feb 2008
Posts: 4,246
Default

Quote:
Originally Posted by Jiraz View Post
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
Indeed. Importing to blender for porting to TRLE is very straightforward as you can also resize the textures in blender

Porting for TRNG and below though wil require retopology to keep tex infos at bay as the polycount is a bit high.

Heckler is online now   Reply With Quote
Old 07-03-24, 01:55   #5
Zebra
Member
 
Zebra's Avatar
 
Joined: Jun 2007
Posts: 26,910
Default

Some textures seem to have some sort of parallax occlusion type effect. Maybe that's what the extra UV info is for?
Zebra is offline   Reply With Quote
Old 17-03-24, 23:52   #6
PiagePiage
Member
 
Joined: Mar 2024
Posts: 1
Default

Chatgpt and i are gonna take a crack at this tonight
PiagePiage is offline   Reply With Quote
Old Yesterday, 06:54   #7
MuruCoder
Member
 
MuruCoder's Avatar
 
Joined: Jan 2018
Posts: 1,283
Default

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.

Quote:
Originally Posted by Zebra View Post
Some textures seem to have some sort of parallax occlusion type effect. Maybe that's what the extra UV info is for?
Maybe. They could also be for vertex colors, to use as static lighting.
MuruCoder is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 11:38.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
Tomb Raider Forums is not owned or operated by CDE Entertainment Ltd.
Lara Croft and Tomb Raider are trademarks of CDE Entertainment Ltd.