The TRB files are containers with various sections used to define the model (textures, shaders, skeleton, geometry etc). A binary template for this file format can be found here.

The following header is for all the different sections.

This section is used to define and encapsulate all the other ones. It contains information such as the sections count, offsets and other info. To avoid confusion, sections contained in this one will be called "subsections".

This section is used to define a single texture (so each texture used by the model will have an associated SEDBtxb section).

N.B.: The SEDBtxb section is 16 bytes aligned, some 0 padding is used to properly align if necessary.

N.B.: This chunk is in Big Endian.

This struct defines the necessary information to extract the texture data from the associated IMGB file.

This section is used to define the necessary semantics in case of data spread into several TRBs. The attribute definition is similar to the ones in the STMS chunk. See m253/583 on ps3/win32 for examples.

Data as defined by the STMS Header. Matches the data format in the calling trb file.

This section is used to reference another trb file with the missing data to build the model, only used when the data is spread into several TRBs.

This section is used to define the geometry data (attributes, skinning information, submeshes etc).

This section is used to define the model's skeleton.

The subsections seen so far are the following:

This subsection has the necessary information to construct the skeleton (parenting, position, rotation etc). The number of joint entries is equal to the subsection size divided by 0xB0 (size of the joint structure). The joint structure is defined the following way:

N.B. The child indices do not seem to be used within the game other than determining the load order of the bones. Bones that are not listed in a “child” index are not created but the specific order of the child index does not seem to matter. i.e. if each bone utilizes a single child index pointing to the next bone (0 -> 1, 1 -> 2, etc.) for the whole list, then it all still loads and works fine. The only restriction is that a bone listed as a “parent” MUST be created before the parent index is used. A parent or child index of -1 is not used.

For the group ID, the purpose seems to vary between the games: In XIII the joint groups seemed to be fairly well defined as

0 = Main 1 = Accessory/Clothing/Hair 2 = Body 3 = Head

Whereas in XIII-2/LR it seems to split the skeleton into "limbs".

Research needed.

This section is used to define the "sockets", which are used as location to attach weapons, accessories etc.

Next are some structs (socket count of them) used to define the names, bone parenting and location info of the sockets.

Next some euler angles (socket count of them), used to define the socket rotation.

Finally, a section where all the null-terminated strings referenced by the previous offsets are packed. Socket names and their bone parent names can be found here.

Chunks are structures used to subdivide the above sections in several blocks of information. There are two chunk types : chunks and chunk containers. The latter are used to "pack" several chunks, which will be referred to as their "children".

The following header is for all the different chunks.

This chunk contains the actual DX9 shader code and name. As of now the best way to disassemble/decompile the bytecode is to use the following PR build.

The purpose of this chunk is currently unknown. It seems to always have the same size and content.

The purpose of this chunk is currently unknown. It seems to always have the same size and content.

This chunk contains the shader parameter values and the samplers' data.

A parameter data entry has the following structure:

A sampler data entry has the following structure:

This chunk stores a string. As its name suggests it's used to store a name.

This chunk stores a null terminated string.

N.B.: For the bone indices, these are not the absolute indices as defined in the SEDBSKL section. Instead, a bone map is made using the ENVD chunks and the indices refer to the bones defined in the latter.

N.B: Color : while this can be used to color shade the model somewhat, it's used more for shadowing areas of the model independently. For example, Hope's wrists as they come out of his gloves are darkened by using this. 4 byte values, in RGBx. 255 being full brightness/color and lower values darkening the specific color. The game always keeps the last value at 255., which is most likely the alpha channel.

Purpose currently unknown. (PS3)

Purpose currently unknown. (PS3)

This chunk defines which vertices are affected by a given bone (referenced by its name) and by how much (weight). It is redundant since this info is already given by the STMS buffer, however the game uses the ENVD order as a bone map.

For example if the first ENVD of a MESH chunk container references the bone "larm", then a 0 bone index in the STMS buffer will refer to "larm", whereas the 0 index in the skeleton would normally refer to the bone "trans". Therefore, when combined together, the ENVD chunks form a bone map, defining a skeleton subset that deforms the submesh.

Resource ID? References a resource located in another file. Typically seen in the environment files referencing a shader.

Resource Type? Type of resource identified in RSID.

Source location of remote resource

File type (or extension) of remote resource

This chunk contains some bounding box info. AABB chunks are used for identifying viewable meshes in-game while COMP chunks use some bounding box like information used to determine the scale/bias, which is then used to dequantize the submeshes' position data.

The dequantization is done in the vertex shader, using the following routine :

scale = BBoxMax - BBoxMin;
scale *= 0.5;
bias = BBoxMax - posScale;
position = position/32767 * scale + bias

Purpose currently unknown.

Always empty so probably unused by the game.

Purpose currently unknown.

The following header is for all the different chunks.

This is the main chunk container for the shader section.

This is the main chunk container for the geometry section. Its underlying chunk containers are all in Big Endian.

This chunk container has the "main" model geometry information embedded. It's the biggest one of the 3 containers defined in the SEDBwrb section.

This chunk container defines a mesh and its underlying submeshes, defined in "MESH" chunks.

This chunk container defines a submesh. It has the vertex buffers necessary to construct the geometry.

This chunk container is used to define bounding box information (Mesh & MDL) and scale/bias information (MDL only).

This chunk container only has a header chunk. Its purpose is currently unknown, considering its size it's probably unused.

This chunk container only has a single embedded chunk container. Its purpose is currently unknown.

Purpose currently unknown

Purpose currently unknown