Jump to content

Mortal Kombat: Shaolin Monks PS2 models


roocker666
Go to solution Solved by shak-otay,

Recommended Posts

  • Engineer
3 minutes ago, shak-otay said:

The question is, "can we create a flag from the vertex block values?". I have my doubts when looking at your mesh format pictures above.

In theory yes because we have 4 bytes of padding too after vertices("flag" and "pad" are these 4 bytes, one short and other short) but we need to read Uvs, + 8 bytes of padding and in Vbuf48 the same but reading Normals + 4 bytes padding.

So It seems like we need to read the entire buffer in both mesh formats or something like that.

Link to comment
Share on other sites

  • Engineer
Posted (edited)

Hmm, it skips the wrong faces. The implementation looks correct:

# A000
# skipped 26
# F000
# skipped 27
# 0
f 27/27 28/28 29/29
# 0
f 28/28 30/30 29/29
# 0
f 29/29 30/30 31/31

....

(maybe a "plus/minus 1" index bug, but in principle no fault)

 

edit: hopefully I "bugged it out" but still extra faces, hmm, thinking

(added resulting kitana obj for reference, 1026 faces skipped, only difference I see are lots of holes)

Maybe I'm reading the wrong flags?

The log shows the skipping working as expected, from a mathematical point of view:

# 0. 17c +16 dec. [0]
# 1. 19c +16 dec. [4000]
# 2. 1bc +16 dec. [c000]
# 3. 1dc +16 dec. [c000]
# 4. 1fc +16 dec. [4000]
# 5. 21c +16 dec. [0]
# 6. 23c +16 dec. [7000]
# 7. 25c +16 dec. [b000]
# 8. 27c +16 dec. [b000]
# 9. 29c +16 dec. [0]
# 10. 2bc +16 dec. [8000]
# 11. 2dc +16 dec. [8000]
# 12. 2fc +16 dec. [0]

--------------------------

# C000
# skipped 2
# C000
# skipped 3
# 4000
f 3/3 4/4 5/5
# 0
f 4/4 6/6 5/5
# 7000
f 5/5 6/6 7/7
# B000
# skipped 7
# B000
# skipped 8
# 0
f 8/8 10/10 9/9
# 8000
# skipped 10
# 8000
# skipped 11
# 0
f 11/11 12/12 13/13
# 0

--------------------

 

 

Makeobj_log, kitana_b+16.zip

Edited by shak-otay
  • Like 1
Link to comment
Share on other sites

  • Engineer
Posted (edited)
1 hour ago, shak-otay said:

well, no matter which flag I choose, red or blue, in both cases I get holes.

 

But those holes are in Vbuf32 or Vbuf48 meshes? or maybe in both?

Try this, in Vbuf32 use the first short after vertices as "Flag" but in Vbuf48 use the second short after vertices as "Flag"

 

Edited by roocker666
Link to comment
Share on other sites

  • Engineer
Posted (edited)

Cool thought - but sadly it happens in both:

(it reads "skipped vertexnumber", where vertexnumber is a faceindex of the skipped face)

# 8000   (flag)
# skipped 4079

# 8000  (flag)
# skipped 4080

# 6000  (flag)
f 4080/4080 4082/4082 4081/4081

# 4079. 2a324 +16 [8000] [32]
# 4080. 2a344 +16 [8000] [32]
# 4081. 2a364 +16 [6000] [32]

----------------

# 0
f 947/947 948/948 949/949

# A000
# skipped 949

# C000
# skipped 950

# 0
f 950/950 952/952 951/951

# 948. 8dbc +16 [0] [48]
# 949. 8dec +16 [a000] [48]
# 950. 8e1c +16 [c000] [48]
# 951. 8e4c +16 [0] [48]

-------------------------------------

After having checked it back 'n forth I'm not sure whether skipping is worth using it here (if I haven't used the wrong flags, maybe).

There's less extra faces and lower legs are near to perfect but

as another result of skipping we get holes. Dependent on the flags I use (offset 16 or not) they maybe bigger or less big.

 

kitana_skipping_1.png

kitana_skipping_holesAtKnees.png

Edited by shak-otay
  • Like 1
Link to comment
Share on other sites

  • Engineer
7 hours ago, shak-otay said:

After having checked it back 'n forth I'm not sure whether skipping is worth using it here (if I haven't used the wrong flags, maybe).

There's less extra faces and lower legs are near to perfect but

as another result of skipping we get holes. Dependent on the flags I use (offset 16 or not) they maybe bigger or less big.

Well, at least we have less extra faces. I have an idea, download attached "model3_Kitana_Fatality.rar" from 1st page. I cut all meshes and made two files, one has all Vbuf32 meshes and the other has all Vbuf48 meshes, then choose one or the other to see what happens. Maybe we can identify which mesh group has holes. I hope just one group shows holes..

Kitana fatality model has more meshes inside like guts and bones, the good thing is that this model use one texture for the whole body and other texture for all guts and bones.

  • Like 1
Link to comment
Share on other sites

  • Engineer
Posted (edited)

Thanks! I'll look at that asap. Meanwhile I had logged the skipped meshes (1189) and grouped separately. The picture illustrates the situation.

I append the obj in question for reference.

edit: added pictures for vertex32only and vertex48only .mk models

To track this down I assume it's required to collect the numbers of the obvious extra faces in blender, then check their vertex blocks in the mk file(s)

for similarities. And check whether the flag WORD is >= 0x8000 always.

Kitana_with_skipped.png

Makeobj_log-kitana-1189_skipsIncluded.zip

kitana_vertex32.png

kitana_vertex48only.png

Edited by shak-otay
  • Like 1
Link to comment
Share on other sites

  • Engineer
Posted (edited)

I tried to make a script for Noesis based on TriList by Leeao and a "mesh search" from Durik. The script reads meshes from Kitana fatality "model3_kitana_vertex32.mk" It seems like Vbuf32 meshes look perfect(using 1st short after vertices as Flag). Check Image 1

Then I made a few changes in the script(uncomment lines 32, 41, 42 and 47 to read meshes from Kitana fatality "model3_kitana_vertex48.mk") but meshes have holes(Image 2) *Save changes after uncommenting those lines, then close and open Noesis or just reload plugins from menu.

That means only Vbuf48 meshes have holes. Then I changed the "Flag" using 2nd short after vertices(just swap lines 36 and 37) and No holes! but some extra faces(image 3) *Don't forget to save changes again after changing lines 36 and 37.

So, 2nd short works better for Vbuf48 meshes but is not perfect because it creates some extra faces, I don't know if that is the corret Flag, besides there are more bytes that we can use as Flag after Uvs(only in vbuf48 meshes, Vbuf32 are fine), I am getting tired of this BS, lol

Kitana_fatality_vbuf32.PNG

Kitana_fatality_vbuf48.PNG

Kitana_fatality_vbuf48_FIX.PNG

 

Edited by roocker666
Link to comment
Share on other sites

  • Engineer
Posted (edited)

Cool! Combining the two no-holes meshes should give a perfect body!?

Could you upload the script you created the vertex48-no-holes with, please?

Because no matter how pad and flag line are ordered I get holes for vertex48 mesh (it's less with flag using 2nd short, yes).

(lines 32, 41, 42 and 47  uncommented, of course)

btw, using padding value as flag would mean the concerning vertex never being skipped, so less holes, yeah.

Since vertex48 doesn't have many skips (see last picture in my previous post) there should be no big visual difference, but I have some small holes in 

vertex48, even if "skip" is off in the Make_obj app.

edit: I checked the logs again why some extra vertexes are not marked for being skipped and found a vertex in a vertex48 block with a skip flag value (0xA000 for vertex 187) at  an offset +16. I have no idea whether this is the cause of our troubles and I'm too exhausted atm to check further.

It's important, btw, not to confuse the sub mesh numbers in the picture (SM_58_skip) with the vertex numbers.

The _skip sub meshes consist of one face only (where I'm confused why vertex 184 and 186 are not marked for being skipped by their flags).

Kitana_vertex48_vertex_187.png

Edited by shak-otay
Link to comment
Share on other sites

  • Engineer
Posted (edited)

Yes, by combinning both meshes is a "perfect body" just meshes Vbuf48 have a few extra faces here and there but are inside the whole body.

Script for the"vertex48-no-holes" is the same, lol. Just swap lines 36 and 37, Those lines read pad and Flag after vertices, so you need to change those,

Vbuf48 holes(lines 36, 37):

flag = (bs.readShort() & 0x8000) == 0x8000
 pad = bs.readShort()

No holes:

pad = bs.readShort()
 flag = (bs.readShort() & 0x8000) == 0x8000
               

Edited by roocker666
Link to comment
Share on other sites

  • Engineer
Posted (edited)

Yes, I know.

edit: ok, I see, I have two versions of .pyc in the cache.

My fault was to rename the modified script.

edit2: no. didn't solve my problem.

Could you please compare the modified script with the one you get the vbuf48-no-holes picture with?

Size of mk file is 99488 bytes.

This is what I use and get:

 

 

 

vbuf48-holes.png

fmt_mk_shaolin_ps2_vbuf48_test.py

Edited by shak-otay
Link to comment
Share on other sites

  • Engineer
16 minutes ago, shak-otay said:

edit2: no. didn't solve my problem.

Could you please compare the modified script with the one you get the vbuf48-no-holes picture with?

Size of mk file is 99488 bytes.

This is what I use and get:

Script is fine, maybe you need to press red icon on bottom "Toggle face cull" or just press F4

  • Like 1
Link to comment
Share on other sites

  • Engineer

Ok, the "dirty trick". I was in the hope the script would work without it.

Well, seems to be a good result, though I'm still suspicious about using pad word for flag creation.

Link to comment
Share on other sites

  • Engineer
Posted (edited)
On 5/5/2024 at 3:13 PM, shak-otay said:

Ok, the "dirty trick". I was in the hope the script would work without it.

Well, seems to be a good result, though I'm still suspicious about using pad word for flag creation.

Yeah, that's a problem when you create faces, probably there is other algo to fix faces orientation but that means more work.. So is Ok like that. I am not really sure how PS2 creates faces, that is a big question but anyway. I really appreicate all your work and time for this, Thank you for all your help man! 😃

Edited by roocker666
  • Like 1
Link to comment
Share on other sites

  • 7 months later...
On 5/3/2024 at 12:27 PM, roocker666 said:

Yep but you need to delete all extra faces and group meshes. It takes some time but the result is great!

Thanks for the tool and all your help man.  😃

This is the result:

Kitana_Fix.PNG

can you share fixed model of kitana?

are this extracted model rigged?

Link to comment
Share on other sites

  • Engineer
On 12/17/2024 at 4:39 AM, shivshankar said:

can you share fixed model of kitana?

are this extracted model rigged?

Why don't you use the tool that made shak-otay? you only need to delete extra faces and flip some.

Ok, just that model(it is not rigged so no bones). If you want more models use the tool. Here is it: Kitana model

Edited by roocker666
Link to comment
Share on other sites

  • Engineer
4 hours ago, roocker666 said:

Why don't you use the tool that made shak-otay? you only need to delete extra faces and flip some.

Ok, just that model(it is not rigged so no bones). If you want more models use the tool.

I don't remember correctly - but wasn't your py script the better solution for other models?

Link to comment
Share on other sites

  • Engineer

fmt_mk.py

if use automatic triangle strip for step 48, from the outside it seems like everything is fine, but inside it's chaos of triangles xD

4.png

I think the strip break is somehow indicated after the peaks after the bytes 00 00 00 17, but I'm not sure

for example, I took several meshes for testing, and they cannot be built using the 4th float at the vertex:

id: 145
numStrip: [4, 4]
strip: [0,1,2,3,-1,4,5,6,7]
offset: 159688
vnum: 8 
stride: 48
Spoiler
4th float as 2 short:
[0] 0 0
[1] 0 16128
[2] 0 0
[3] 0 16128
[4] 0 16128
[5] 0 0
[6] 0 16128
[7] 0 0
full:
[0] ::
    v: (4.000004768371582, -785.4821166992188, 70.17066955566406, 0.0)
    t: (0.3962402641773224, 0.58544921875, 0.5, 0.5)
    n: (0.0, 0.013671875, 0.999755859375, 0.0)
[1] ::
    v: (3.000004768371582, -754.7997436523438, 71.17066955566406, 0.5)
    t: (0.3923340141773224, 0.508056640625, 0.5, 0.0)
    n: (-0.000244140625, -0.026123046875, 0.99951171875, 0.0)
[2] ::
    v: (23.000003814697266, -785.4821166992188, 70.17066955566406, 0.0)
    t: (0.478759765625, 0.58544921875, 0.5, 0.5)
    n: (0.0, 0.009521484375, 0.999755859375, 0.0)
[3] ::
    v: (30.000003814697266, -754.7997436523438, 71.17066955566406, 0.5)
    t: (0.482666015625, 0.508056640625, 0.5, 0.0)
    n: (-0.00048828125, -0.026123046875, 0.99951171875, 0.0)
[4] ::
    v: (-23.9999942779541, -754.7997436523438, 71.17066955566406, 0.5)
    t: (0.4826660454273224, 0.508056640625, 0.5, 0.0)
    n: (0.0, -0.12841796875, 0.991455078125, 0.0)
[5] ::
    v: (-20.9999942779541, -785.4821166992188, 70.17066955566406, 0.0)
    t: (0.4787597954273224, 0.58544921875, 0.5, 0.5)
    n: (0.0, 0.010986328125, 0.999755859375, 0.0)
[6] ::
    v: (-4.999995231628418, -754.7997436523438, 71.17066955566406, 0.5)
    t: (0.392333984375, 0.508056640625, 0.5, 0.0)
    n: (0.0, -0.12109375, 0.992431640625, 0.0)
[7] ::
    v: (-3.999995231628418, -785.4821166992188, 70.17066955566406, 0.0)
    t: (0.396240234375, 0.58544921875, 0.5, 0.5)

 

3.png

id: 28
numStrip: [5, 5, 9, 6, 7]
strip: [0,1,2,3,4,-1,5,6,7,8,9,-1,10,11,12,13,14,15,16,17,18,-1,19,20,21,22,23,24,-1,25,26,27,28,29,30,31]
offset: 27544
vnum: 32 
stride: 48
Spoiler
4th float as 2 short:
[0]  0     16256
[1]  0     16256
[2]  0     16128
[3]  0     16256
[4]  0     16256
[5]  0     16256
[6]  0     16256
[7]  0     16128
[8]  0     16256
[9]  0     16256
[10] 0     16256
[11] 0     16256
[12] 16384 16179
[13] 0     16256
[14] 0     16128
[15] 0     16256
[16] 40960 16025
[17] 0     16256
[18] 0     16128
[19] 0     16256
[20] 0     16256
[21] 16384 16179
[22] 0     16256
[23] 16384 16179
[24] 16384 16179
[25] 16384 16179
[26] 0     16256
[27] 0     16128
[28] 0     16256
[29] 40960 16025
[30] 0     16256
[31] 0     16128
full:
[0] ::
    v: (-17.0, -612.7890625, -41.000003814697266, 1.0)
    t: (0.9079590439796448, 0.456298828125, 0.0, 0.0)
    n: (-0.144287109375, 0.22998046875, -0.96240234375, 0.0)
[1] ::
    v: (-20.0, -628.7890625, -49.000003814697266, 1.0)
    t: (0.8989258408546448, 0.430908203125, 0.0, 0.0)
    n: (-0.132080078125, 0.2734375, -0.95263671875, 0.0)
[2] ::
    v: (-33.0, -608.7890625, -33.000003814697266, 0.5)
    t: (0.822998046875, 0.498779296875, 0.5, 0.0)
    n: (-0.699462890625, 0.2041015625, -0.6845703125, 0.0)
[3] ::
    v: (-38.0, -628.7890625, -40.000003814697266, 1.0)
    t: (0.835693359375, 0.432861328125, 0.0, 0.0)
    n: (-0.598876953125, 0.28271484375, -0.7490234375, 0.0)
[4] ::
    v: (-48.0, -628.7890625, -24.000003814697266, 1.0)
    t: (0.765625, 0.44970703125, 0.0, 0.0)
    n: (-0.848388671875, 0.380615234375, -0.367431640625, 0.0)
[5] ::
    v: (49.0, -628.7890625, -24.000003814697266, 1.0)
    t: (0.7656250596046448, 0.44970703125, 0.0, 0.0)
    n: (0.848388671875, 0.380615234375, -0.367431640625, 0.0)
[6] ::
    v: (39.0, -628.7890625, -40.000003814697266, 1.0)
    t: (0.8356934189796448, 0.432861328125, 0.0, 0.0)
    n: (0.598876953125, 0.28271484375, -0.7490234375, 0.0)
[7] ::
    v: (34.0, -608.7890625, -33.000003814697266, 0.5)
    t: (0.822998046875, 0.498779296875, 0.5, 0.0)
    n: (0.699462890625, 0.2041015625, -0.6845703125, 0.0)
[8] ::
    v: (21.0, -628.7890625, -49.000003814697266, 1.0)
    t: (0.89892578125, 0.430908203125, 0.0, 0.0)
    n: (0.132080078125, 0.2734375, -0.95263671875, 0.0)
[9] ::
    v: (18.0, -612.7890625, -41.000003814697266, 1.0)
    t: (0.907958984375, 0.456298828125, 0.0, 0.0)
    n: (0.144287109375, 0.22998046875, -0.96240234375, 0.0)
[10] ::
    v: (0.0, -630.7890625, 41.999996185302734, 1.0)
    t: (0.3625488579273224, 0.429443359375, 0.0, 0.0)
    n: (0.0, 0.38330078125, 0.92333984375, 0.0)
[11] ::
    v: (-21.0, -630.7890625, 42.999996185302734, 1.0)
    t: (0.4206543266773224, 0.429443359375, 0.0, 0.0)
    n: (-0.199951171875, 0.409423828125, 0.889892578125, 0.0)
[12] ::
    v: (-14.0, -604.7890625, 32.999996185302734, 0.7001953125)
    t: (0.433837890625, 0.498779296875, 0.2998046875, 0.0)
    n: (-0.159423828125, 0.153564453125, 0.97509765625, 0.0)
[13] ::
    v: (-49.0, -628.7890625, 26.999996185302734, 1.0)
    t: (0.520751953125, 0.4375, 0.0, 0.0)
    n: (-0.72607421875, 0.419921875, 0.544189453125, 0.0)
[14] ::
    v: (-41.0, -602.7890625, 14.999996185302734, 0.5)
    t: (0.548828125, 0.5048828125, 0.5, 0.0)
    n: (-0.80810546875, 0.111083984375, 0.578125, 0.0)
[15] ::
    v: (-55.0, -628.7890625, 2.9999959468841553, 1.0)
    t: (0.641357421875, 0.44482421875, 0.0, 0.0)
    n: (-0.93994140625, 0.34033203125, 0.023681640625, 0.0)
[16] ::
    v: (-45.0, -602.7890625, -3.0000040531158447, 0.300048828125)
    t: (0.680419921875, 0.49462890625, 0.699951171875, 0.0)
    n: (-0.9931640625, 0.057861328125, -0.099609375, 0.0)
[17] ::
    v: (-48.0, -628.7890625, -24.000003814697266, 1.0)
    t: (0.765625, 0.44970703125, 0.0, 0.0)
    n: (-0.848388671875, 0.380615234375, -0.367431640625, 0.0)
[18] ::
    v: (-33.0, -608.7890625, -33.000003814697266, 0.5)
    t: (0.822998046875, 0.498779296875, 0.5, 0.0)
    n: (-0.699462890625, 0.2041015625, -0.6845703125, 0.0)
[19] ::
    v: (50.0, -628.7890625, 26.999996185302734, 1.0)
    t: (0.5207520127296448, 0.4375, 0.0, 0.0)
    n: (0.72607421875, 0.419921875, 0.544189453125, 0.0)
[20] ::
    v: (22.0, -630.7890625, 42.999996185302734, 1.0)
    t: (0.4206543266773224, 0.429443359375, 0.0, 0.0)
    n: (0.199951171875, 0.409423828125, 0.889892578125, 0.0)
[21] ::
    v: (15.0, -604.7890625, 32.999996185302734, 0.7001953125)
    t: (0.433837890625, 0.498779296875, 0.2998046875, 0.0)
    n: (0.159423828125, 0.153564453125, 0.97509765625, 0.0)
[22] ::
    v: (0.0, -630.7890625, 41.999996185302734, 1.0)
    t: (0.362548828125, 0.429443359375, 0.0, 0.0)
    n: (0.0, 0.38330078125, 0.92333984375, 0.0)
[23] ::
    v: (0.0, -604.7890625, 29.999996185302734, 0.7001953125)
    t: (0.364013671875, 0.498779296875, 0.2998046875, 0.0)
    n: (0.0, 0.142333984375, 0.98974609375, 0.0)
[24] ::
    v: (-14.0, -604.7890625, 32.999996185302734, 0.7001953125)
    t: (0.433837890625, 0.498779296875, 0.2998046875, 0.0)
    n: (-0.159423828125, 0.153564453125, 0.97509765625, 0.0)
[25] ::
    v: (15.0, -604.7890625, 32.999996185302734, 0.7001953125)
    t: (0.4338379204273224, 0.498779296875, 0.2998046875, 0.0)
    n: (0.159423828125, 0.153564453125, 0.97509765625, 0.0)
[26] ::
    v: (50.0, -628.7890625, 26.999996185302734, 1.0)
    t: (0.5207520127296448, 0.4375, 0.0, 0.0)
    n: (0.72607421875, 0.419921875, 0.544189453125, 0.0)
[27] ::
    v: (42.0, -602.7890625, 14.999996185302734, 0.5)
    t: (0.548828125, 0.5048828125, 0.5, 0.0)
    n: (0.80810546875, 0.111083984375, 0.578125, 0.0)
[28] ::
    v: (56.0, -628.7890625, 2.9999959468841553, 1.0)
    t: (0.641357421875, 0.44482421875, 0.0, 0.0)
    n: (0.93994140625, 0.34033203125, 0.023681640625, 0.0)
[29] ::
    v: (46.0, -602.7890625, -3.0000040531158447, 0.300048828125)
    t: (0.680419921875, 0.49462890625, 0.699951171875, 0.0)
    n: (0.9931640625, 0.057861328125, -0.099609375, 0.0)
[30] ::
    v: (49.0, -628.7890625, -24.000003814697266, 1.0)
    t: (0.765625, 0.44970703125, 0.0, 0.0)
    n: (0.848388671875, 0.380615234375, -0.367431640625, 0.0)
[31] ::
    v: (34.0, -608.7890625, -33.000003814697266, 0.5)
    t: (0.822998046875, 0.498779296875, 0.5, 0.0)
    n: (0.699462890625, 0.2041015625, -0.6845703125, 0.0)

 

1.png

Edited by Durik256
  • Thanks 2
Link to comment
Share on other sites

  • Engineer
6 hours ago, shak-otay said:

I don't remember correctly - but wasn't your py script the better solution for other models?

My script shows less extra triangles but I did not update the script to read both mesh formats at the same time, lol.

Link to comment
Share on other sites

  • Engineer
5 hours ago, Durik256 said:

if use automatic triangle strip for step 48, from the outside it seems like everything is fine, but inside it's chaos of triangles xD

Yeah, these models are weird. In theory 4th Float should be a flag for triangles but I don't know how it works.. Besides I don't know why vbuf48 has Normals and vbuf32 don't, this is so strange..

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...