Extracting models from Gantz: The Game (PS2)

[justadude]

After unpacking the .NKP files with an existing quickbms script, i got to a dead end trying to convert these .NKM model files to any conventional format.

I wonder if any of you could help me out with this, i just want the model with their UVs, rigs are unnecessary.

Samples in the .RAR file.

Thanks for reading.

sample.rar

[roocker666]

Model format is the same as "Cy girls PS2"(both were made by KONAMI). Those .NKM have A LOT of submeshes and there are like 2 or 3 different mesh formats(vertex buffer size changes). Besides it seems like you need to apply the skeleton because model is not in T pose. I hate when models have meshes with different vertex buffer sizes but that happens in some PS2 models. That sucks.. lol

[justadude]

6 hours ago, roocker666 said:

Model format is the same as "Cy girls PS2"(both were made by KONAMI). Those .NKM have A LOT of submeshes and there are like 2 or 3 different mesh formats(vertex buffer size changes). Besides it seems like you need to apply the skeleton because model is not in T pose. I hate when models have meshes with different vertex buffer sizes but that happens in some PS2 models. That sucks.. lol

Is there any existing plugin, script, converter or something like that?

[shak-otay]

@roocker666: it doesn't seem to be a "vif" format?

edit: see, xx=04 seems to be the count. Searching for CCxx0010 in main-kurono01-base.nkm gives 136 occurrences.

That's a normals sphere, seems. There's only 28 other CCxx00yy signatures so not sure whether it's "vif".

Ok, there's "types" 33, 66 and 99 also. Will give them a try...

edit2: all I get is "spheres with nucleus". Maybe the vertices vary too much:

# 0x201f3: 13
v -5.156250 -71.761719 -105.824219 
v -2.640625 -4.339844 0.328125 
v -15.988281 -12.964844 82.507812 
v 25.042969 1.550781 -3.558594 
v 14.398438 16.000000 -12.964844 
v -96.953125 -0.128906 1.550781 
v 0.328125 2.398438 -15.988281 
v 75.929688 -102.371094 23.710938 
v -3.687500 0.355469 13.597656 
v -11.425781 75.929688 -102.371094 
v 1.503906 -3.687500 0.328125 
v -15.988281 4.171875 127.542969 
v 23.722656 3.152344 -0.093750 
# 0x20283: 13
v 11.425781 -75.929688 102.371094 
v -1.503906 3.687500 0.382812 
v -15.988281 12.964844 -82.507812 
v -25.042969 -1.550781 3.558594 
v 14.398438 16.000000 12.964844 
v 96.953125 0.128906 -1.550781 
v 0.382812 2.398438 -15.988281 
v 71.761719 105.824219 -23.875000 
v 4.339844 0.410156 13.597656 
v 5.156250 71.761719 105.824219 
v 2.640625 4.339844 0.382812 
v -15.988281 1.011719 84.863281 
v -25.515625 2.609375 3.929688 
# 0x2084f: 5
v 124.027344 27.320312 -15.695312 
v -3.277344 -1.957031 0.027344 
v -15.988281 80.394531 26.003906 
v 9.164062 -5.207031 6.734375 
v 5.597656 16.000000 80.394531 
# 0x20903: 5
v -85.261719 -36.453125 -88.183594 
v -9.542969 -7.906250 0.082031 
v -15.988281 -95.007812 55.144531 
v -4.253906 -1.281250 4.507812 
v 4.000000 -15.988281 -0.003906 
 

Edited August 25 by shak-otay

[roocker666]

8 hours ago, shak-otay said:

@roocker666: it doesn't seem to be a "vif" format?

It seems like at 0x30 is a pointer to meshes(0x3A90). It was hard to analyze 1st submesh so I analyzed 2nd one at 0x3FE8. This is what I found:

[roocker666]

In 2nd submesh, Vbuf size is 18 but like I said I found meshes with different Vbuf size. For example at 0x389F0. I am not really sure but it seems like in "Mesh tag" the last byte changes. If it is 69, Vbuf size is 18, if it is 6D then Vbuf size is different. I still don't know the correct Vbuf size of 6D..

Edited August 25 by roocker666

[shak-otay]

Thanks! Definitely looks better:

kurono01_base nkm

(Some extra faces, some missing, as usual with PS2 models.)

 

edit: well, the vbuf size for 6D; (offset to next signature/vif at 39238)/ 44= 48 (just a wild guess...)

 

Edited August 25 by shak-otay

[roocker666]

Yeah, that looks like something! Ok, I analyzed submesh at 0x3AF98, this has 6D too. So Vbuf size in "Mesh tag" with 6D is 24. Uvs, Normals and Vertices have same order but with 2 extra bytes between them. And notice that bytes 12 04(After vert count) also have 2 extra bytes "00 00"

So If "mesh tag" has 69 then Vbuf size = 18. If "mesh tag" has 6D then Vbuf size = 24

But the main problem is that all limbs are in the center(and maybe other objects like weapons) so the model is not in T pose. I guess we need to attach the skeleton and bone weights but I don't know how to do that, lol.

Edited August 26 by roocker666

[justadude]

5 hours ago, roocker666 said:

Yeah, that looks like something! Ok, I analyzed submesh at 0x3AF98, this has 6D too. So Vbuf size in "Mesh tag" with 6D is 24. Uvs, Normals and Vertices have same order but with 2 extra bytes between them. And notice that bytes 12 04(After vert count) also have 2 extra bytes "00 00"

So If "mesh tag" has 69 then Vbuf size = 18. If "mesh tag" has 6D then Vbuf size = 24

But the main problem is that all limbs are in the center(and maybe other objects like weapons) so the model is not in T pose. I guess we need to attach the skeleton and bone weights but I don't know how to do that, lol.

Not going to lie, i don't know jack about hex or anything like that but i appreciate you guys efforts 👏🏻

[shak-otay]

8 hours ago, roocker666 said:

I guess we need to attach the skeleton and bone weights

Yeah, but the points from the matrix look a liitle bit weird:

matrix as points

[roocker666]

10 hours ago, shak-otay said:

Yeah, but the points from the matrix look a liitle bit weird:

matrix as points

And I found something weird too. In some mesh tags with "69" look like Vbuf is bigger, for example at 0x1C9D0. I can't figure out Uvs, Normals and Verts order..