ps3 (PS3) Ratchet & Clank: Future series terrain models "UFrags"

[VELD-Dev]

Hey ! I figured out most of the structure of Post-Resistance 2 games made on the Insomniac Engine (or Luna Engine for the intimates), here's basically how it's made:
The Zones have a specific section for them (this was discovered way before my discovery), 0x6200 and within this section, UFrags metadata are built up like this:

[StructureSize(0x80)]
public struct UFragNewEngine
{
  [Offset(0x00)] public ulong tuid;
  [Offset(0x30)] public Vector3 position;
  [Offset(0x40)] public uint indexOffset;
  [Offset(0x44)] public uint vertexOffset;
  [Offset(0x48)] public ushort indexCount;
  [Offset(0x4A)] public ushort vertexCount;
  [Offset(0x50)] public ushort shaderIndex;
}

Credits: NefariousTechSupport

So this is was figured by NTS, as far as I know, correct me if I'm wrong. Although, what I've discovered about them is that they DO NOT have a transformation matrix inside of them. Instead they ONLY have a position Vector3 of single precision floating point numbers.

Their vertices are built up like this. This was also mostly figured out by NefariousTechSupport:

[StructureSize(0x18)]
public struct UFragVertex
{
  [FileOffset(0x00)] public short x;
  [FileOffset(0x02)] public short y;
  [FileOffset(0x04)] public short z;
  //[FileOffset(0x06)] public ushort unkConst;  // Idk maybe it's used for something
  [FileOffset(0x08)] public Half UVx;
  [FileOffset(0x0A)] public Half UVy;
}

This part is interesting because as you can see, vertices have a Vector3 of signed half precision integral numbers, commonly called "short". Of course, when they are placed as is in space, it makes very very odd results, to be fair the models are just gigantic.

What NTS doing before is that they were dividing the value they obtained for each coordinate by 0x7FFF, as these were "short" integers, dividing by max and min value would probably make sense. Although doing that was making the models very very small, so a very very large quest of "finding the constant" began. NTS did all that great work, did a huge work to make R&C:Future worlds viewable, but this part was weird and they lost motivation. I then helped, and searched for that number. The constant that would help to have correct models.
It took me 3 weeks to find it. After trial and error, trying to find transformation matrices and all this kind of stuff, I ended up by finding this number.

The coordinates had to be divided by 256.
Although, that done, there's still one issue that remains: There's huge gaps. The position I'm using, the one that is into the UFrags metadatas higher, is close, but not exact.
This is where I need help. I can't figure why the position is approximate and not always the exact perfectly right one.

Above that, the UFrags organization is still unknown for pre-R2 games, so all the games before Resistance 2 (Ratchet & Clank: Tools of Destruction, Rathcet & Clank: Quest For Booty, Resistance 1)

I had a theory: This is their bounding position, used for the mesh culling. it seems to be common in these games, and I guess in all games.

Please help me.

 

Edited July 16 by VELD-Dev
Added structure sizes, it was a capital information that I forgot to mention

[h3x3r]

Can you tell me a exact name of the game. I don't want download all of em.

BTW it looks like that vertices lost precision point that's the most probaly the reason of gaps between meshes.

Isn't that "//[FileOffset(0x06)] public ushort unkConst; // Idk maybe it's used for something" modifier for vertices? I am just guess...

Edited July 14 by h3x3r

[VELD-Dev]

7 hours ago, h3x3r said:

Can you tell me a exact name of the game. I don't want download all of em.

BTW it looks like that vertices lost precision point that's the most probaly the reason of gaps between meshes.

Isn't that "//[FileOffset(0x06)] public ushort unkConst; // Idk maybe it's used for something" modifier for vertices? I am just guess...

It's Ratchet & Clank: A Crack In Time

It's what I thought at first, but I couldn't figure out what to do with this constant, it's always here and it seems to be the same all the time, Haven't verified if it changed between maps, but when I checked it was the same between zones. I'll further inspect that, it could be an interesting hint but I'll have to consciously inspect the differences between the maps, it's the only way I see for those. Otherwise, there's a correction value somewhere floating around

[h3x3r]

So... assetlookup.dat is TOC right? and mobys.dat has models in it right? Also i noticed that zones.dat has some matrix4x4 pattern...

But i think it's for dynamic models.

EDiT: Well i got past Assets info, but don't know how are relative offsets converted to absolute. Also i don't get where is vertex/index info.

Edited July 15 by h3x3r

[VELD-Dev]

10 hours ago, h3x3r said:

So... assetlookup.dat is TOC right? and mobys.dat has models in it right? Also i noticed that zones.dat has some matrix4x4 pattern...

But i think it's for dynamic models.

EDiT: Well i got past Assets info, but don't know how are relative offsets converted to absolute. Also i don't get where is vertex/index info.

It would be cool if it was that simple haha, in fact the assetlookup.dat is indeed a Table of Contents, it points to the stuff we want, but actually the UFrags geometry is stored into zones.dat

mobys.dat contains the models and other metadatas for mobys, ties.dat contains the models and other metadatas for ties (they are similar to UFrags, except UFrags are unique terrain fragments, that are not instantiated and are never the same, meanwhile ties can be instantiated and duplicated; their common point is that they are static objects and are not interactable, they are terrains)

highmips.dat contains the textures in high quality, etc...

 

Offsets are a bit tricky, you must see the .dat files as archives for several smaller files inside them, they have a beginning and a length, it's hard to explain in a message so I'll only keep the important parts. The zones.dat file has several smaller "IGFiles" inside which contains each one zone, within these zones there is a repetitive pattern and the "Ufrags section" is always the same etc...

The sections contain an absolute offset *inside* the igfiles, but can be seen as relative from the beginning of each IGFile. When the section is reached, there is a defined amount of objects that is defined into the section pointer, and a length (that is sometimes wonky, don't base the length of an object based on it, sometimes it's wrong), then you must know the length of one object structure, that's what I've defined higher.

Edited July 15 by VELD-Dev
Additional precisions about the offsets and structures