Hiya. I managed extract files from the games "Shinobi" and "Nightshade", from PlayStation 2, aiming to extract the player models.

I reached the correct files, but it seems the extension .MLD which they have is not documented anywhere.
What I found out though, is that these files have .IZCA in the header, which seems to be a format used in some Sega games from that era, but that's as far as I found out.

I hope to be able to import these models+original armature on Blender as fbx or something, and maybe import back in the game as well, but that's secondary.

I'm linking here two different files, one from Shinobi which is likely the character "Hotsuma", and another from Nightshade which is likely to be "Hibana".

SHPLAYER00.zip NIPLAYER00.zip

Player00.MDL contains "IZCA" 149 times. Iirc you'll have to split up the file for better handling. Despite this there's many unknown 4 letter signatures like PPPL, MLE0 and such.

(The others are similar to those from Valkyria Chronicles, see gomtuu's blender mlx import script on github, but MLX files usually have one IZCA only at the beginning.)

Those MDL files have several IZCA containers and each IZCA has files with meshes, animations, textures and more crap. So you need to split each IZCA and then extract the content. About mesh files, these have HMDL strings in the header. I found a hand and I analyzed the format this is what I know so far:
There are mesh groups and each mesh group has A LOT of tiny submeshes and each submesh has a VIF Tag(4 bytes) before each buffer, something like this:
Vertices Tag XX C0 YY 6C, 1st byte unk(it looks like an order), 2nd byte always C0, third byte count, 4th byte alway 6C. Then 3 floats XYZ and 4 bytes padding/flags.
Normals Tag XX C0 YY 68/69 same thing but 4th byte is 68/69. I don't know why there are two different tags for normals but it seems like 68 and 69 have different buffer format(Int32?) and sometimes you can find both in the same mesh, weird..
Unk Tag XX C0 YY 62, I don't know what this is, it appears in some submeshes. Buffer is 1 byte and it is always aligned to 4 bytes so it has padding, for example if count is 3, you will see FF FF FF 00, if 5: FF FF FF FF FF 00 00 00, etc..
UVs TAg XX C0 YY 65, nothing weird here, buffer has shorts.
I analyzed a hand and I tried to collect all vertices but I got holes.. Maybe we need to use those flags in vertices for strips but this is very different from other PS2 games. In other PS2 games flag for strips has bytes 00 80 but not here. And there are submeshes with count 1 and 2 but I ignored those because you can't create a triangle. This hand is from Nightshade but it seems like the format is very similar in Shinobi.
Here is my rsult and the file, I don't know if anyone can get better results.
By the way you can find all mesh groups if you search for these bytes:
06 01 00 01 00 00 00 05 00 00 00 20 00 00 00 00, this hand has only one mesh group(These bytes could be different in Shinobi)

block_002_0x02E480_HMDL.rar

Edited August 4Aug 4 by roocker666

Ok, in Shinobi it is very similar: Mesh file HMDL; Verts tag XX C0 YY 6C, then 3 floats and 4 bytes padding. Normals: XX C0 YY 68, just one normals tag so no 69, buffer looks like Int32 too. UVs: XX C0 YY 64 and buffer has Floats no shorts. And I did not find that unk tag 62.
Now, to find mesh groups there are 4 patters:
03 01 00 01 00 00 00 05 00 00 00 20 00 00 00 00
04 01 00 01 00 00 00 05 00 00 00 20 00 00 00 00
03 01 00 01
04 01 00 01
Shinobi was released in 2002 and Nightshade in 2004 so it seems like Nightshade uses a newer version of the format.
I forgot to mention about bytes 00 00 00 17, These bytes appear at the end of a chain of submeshes or a mesh group. They only serve to separate blocks; I suppose the game tells the PS2, "Here's this block, read it, then I'll send you another one." And that makes sense because, looking at the first byte in the tags, it increments, and when it reaches the separator 00 00 00 17, that byte resets to 00. Something like this:

Mesh group
    submesh1
        00 C0 YY 6C
        01 C0 YY 68
        02 C0 YY 64
    submesh2
        04 C0 YY 6C
        08 C0 YY 68
        12 C0 YY 64
    submesh3
        16 C0 YY 6C
        24 C0 YY 68
        28 C0 YY 64
    00 00 00 17 --------End of block.
    submesh4
        00 C0 YY 6C ---- next tag resets to 00(1st byte)
        01 C0 YY 68
        02 C0 YY 64
    submesh5
    submesh6
    submesh7
00 00 00 17 -------------End of block and end of mesh group

I've seen that separator in other PS2 games, but they're always at the end of a submesh. In this case, it appears after several submeshes because they're very small.
All right, that is my research so far. Thanks for reading all this.

4 hours ago, mariokart64n said:

But that tool was for Soulcalibur, is there a new version?? 😲