XeNTaX

The format for the pkg files in tlou is nearly identical to the format on ps3 structure wise.

it's probably a flag for something, but specifically it's a programmer's inside joke:
https://en.wikipedia.org/wiki/Hexspeak

[out]

the PS3 pkg format is described here:
http://www.psdevwiki.com/ps3/PKG_files

The source code to a PS4 Pkg unpacker is here:

https://github.com/Keyaku/ps4tools

The problem is, the encryption. The PS4 tool above can only decrypt a few basic files using RSA keys. but the rest uses a different encryption. It's made up of PFS blocks. http://www.psdevwiki.com/ps4/PFS

[out]

[out]

pretty sure that's what the model viewer/extractor of this thread does.

[out]

Well if it's anything like the PS3 games I've worked on, they do not include vertex/face counts anywhere in the model file. Which is why he has to scan for the beginning. To call it a 'format' is a bit misleading, it's closer to a memory image. I know the buffer sizes have to be stored somewhere, but it might be in the main executable code of the game itself, or in the shaders, or only the devs know where. It will be quite a challenge to accomplish a clean extract.

[out]

[out]

Wobble wrote: how you are calculating these offsets to the vertex and index data?
.

Those offsets are not from the beginning of the file, they are from the starting offset of their respective blocks.

In pak files not all of the mesh data is in one place, it is divided into seperate blocks. For example let's say a file has 6 meshes and 3 blocks. It is possible that 3 meshes are in block 1, 2 meshes in block 2 and 1 mesh in block 3. It differs for each file.

So how do you find these blocks? I assume you already checked chrrox's noesis script. Headers and info1 arrays are what you need. Headers [4] tells you how many blocks there are in the file and info1 array has the offset of these blocks. Info1's elements (blocks) are integer arrays with 2 elements, so there are 2 values for each block. Value at index 0 is the starting offset of the block and value at index 1 is the offset you need to advance to reach the next block. I couldn't find any use for index 1 so I will say that you only need the values at index 0.

The program can find the index offset of each mesh and it can also find the different blocks in the file. Only problem is that it doesn't know which mesh belongs to which block. It just tries each offset with every block, trying to find a reasonable data. Maybe you can find a way to get this info.

[out]

[out]