XeNTaX

Ekey wrote:
Where : 0xAAAAAAAA - It's original hash, 0xBBBBBBBB - Section number

I don't understand your format. Is this a symlink-structure?
When you scan the tiger files you loop through 5492 "link-directorys".
Every link-directory contains a number of sections (howdies symlinks) - or in other words, data-offsets to the original files (the CDRM-Sections).
The CDRM-Sections are sometimes splitted in zlib-compressed data-sections, but that is irrelevant.

While looping through the link-directorys and there sections, the first appearance of the target file (mesh,dds,fsb...) is saved (filename=CDRM-Offset) in the "bigfile.00x"-folder. All other sections linked to the same offset will be skipped. So you have only one Offset-Filename per file.

So what is your 0xAAAAAAAA and 0xBBBBBBBB in this scenario and where should be the unique files stored?

Ekey wrote:So the model in other format, plugin for Noesis that does not support it.

Yes, there are meshes starting with different bytes (c00l's plugin support only 0x06), but there are others starting with 0x04,0x03 and a few others with no specific header (bigfile.001/0x29f99800.mesh)
0x06 = 9555 files
0x04 =233 files
0x03 = 417 files
0x?? = 170 files
---------------
Total 10375 meshes

Axsis wrote:CDRM at offset 0x6BD91800 in bigfile.002.tiger
size: 784580 bytes, uncompressed: 1154664 bytes, i'm sure there is lara model (at least one of them ) it's biggest cdrm

You think its Lara, cuz its the biggest cdrm? I don't believe Lara is a 70 MB mesh. Maybe around ~1 MB.
70 MB sounds like a complete scene-file or something else really big. The biggest meshes have a 0x03 starting-byte.

It makes no sense to guess where lara could be. We have to analyze the other mesh-formats, then we will found Lara.

Sammie wrote:

Ekey wrote:
Where : 0xAAAAAAAA - It's original hash, 0xBBBBBBBB - Section number

I don't understand your format. Is this a symlink-structure?
When you scan the tiger files you loop through 5492 "link-directorys".
Every link-directory contains a number of sections (howdies symlinks) - or in other words, data-offsets to the original files (the CDRM-Sections).
The CDRM-Sections are sometimes splitted in zlib-compressed data-sections, but that is irrelevant.

While looping through the link-directorys and there sections, the first appearance of the target file (mesh,dds,fsb...) is saved (filename=CDRM-Offset) in the "bigfile.00x"-folder. All other sections linked to the same offset will be skipped. So you have only one Offset-Filename per file.

So what is your 0xAAAAAAAA and 0xBBBBBBBB in this scenario and where should be the unique files stored?

I know about all struct's TIGER DRM and CDRM files. It's just template pic lol

Ekey wrote:I know about all struct's TIGER DRM and CDRM files. It's just template pic lol

I know, but what should howfie do with this kind of template-structure?

cool thx ekey ill look into it soon. took a break for a few days to extract models from metal gear rising .

@howfie. Okay. See pm

Sammie wrote:You think its Lara, cuz its the biggest cdrm? I don't believe Lara is a 70 MB mesh. Maybe around ~1 MB.
70 MB sounds like a complete scene-file or something else really big. The biggest meshes have a 0x03 starting-byte.

It makes no sense to guess where lara could be. We have to analyze the other mesh-formats, then we will found Lara.

where did you see 70 mb? 700kb compressed, 1 mb uncompressed.
and it is not just guess, as i wrote, i parsed through drm structure of laracroft_clean.drm, it have references to 515 cdrm objects, 67 of them are textures (from <100 bytes to >4 mbytes in size) and only 1 object, except textures have size more than 16 kb and type 0x0C, which is "RenderMesh" according to Rick's description of DeusEx3 DRM format description. textures are still 0x05.
anyone tried to load this mesh using current script from C00L12345?

axsis, in that directory (on mines symlink directory 2878, the textures are indeed lara). haven't checked the model format yet. ekey sent me some code to help me identify names i think so i can rename those folders according to the names he extracted (it contains a mix of some of rick's code and mines). will work on it soon. if you guys want, if c00l's code doesn't work on the mesh file, i can quickly hardcode the model out of there if you want it.

Okay guys, its correct, thats lara.

cool, how much does c00l's script extract?

howfie wrote:cool, how much does c00l's script extract?

For Lara I had to remove the bones-part and set to MESH_START manually to 0x6E68 and Lara loads fine.
I think with a little rewrite at the beginning of the script to auto-detect the correct Mesh & Bones-offsets for all mesh-types it could load the other meshes, too.
Maybe c00l can fix this tomorrow and add UV-support.

oh ok I see, he is having trouble detecting the size of the header before the mesh. the size of the header is actually stored in the file table; i can redo the ripper to strip the headers from the mesh files if you want c00l. i left the headers in there because i thought they might be important (the header information for the texture files were important so i left these in as well, but stripped them from the audio files).

Can you tell me which file Lara is in so I can investigate this?

Cheers.

CDRM header maybe contained about file types? I can not check it now because I do not at home.

C00L12345 wrote:Can you tell me which file Lara is in so I can investigate this?

Cheers.

Axsis wrote:CDRM at offset 0x6BD91800 in bigfile.002.tiger
size: 784580 bytes, uncompressed: 1154664 bytes, i'm sure there is lara model (at least one of them )

or here if you lazy

Ekey wrote:CDRM header maybe contained about file types? I can not check it now because I do not at home.

not cdrm, but drm have object type field, that is seems to be the same as stated in http://svn.gib.me/public/crystaldynamic ... ionType.cs
as you already know, drms have two tables - first, with records length 20 bytes, and second with 16 bytes. second dword of every record in first table is object type, in second table it's fourth byte of each record.

correct, there is also a subtype byte in the third dword. the codes have not changed from the previous games.