[XBOX] Crimson Sea XKMD

[einherjar007]

I couldn't add the image in the edit, so please allow me to post more. When I got the next mesh with the data I guess, it seemed wrong. However, it was shaped to some extent, and the UV on the trousers seemed to be correct. It seems that we need a little more wisdom.

[Bigchillghost]

I couldn't add the image in the edit, so please allow me to post more

Which Windows OS are you using? I never expect to see such an old-style UI, not even on WinXP.

It seems that we need a little more wisdom.

The truth is, it's definitely gonna drive you crazy to load all the submeshes manually, let along the vertices need to be transformed to the correct positions with the corresponding bone transformation info. There's a submesh info table at 0x12AC where each entry takes 44 bytes and you'll find the count of the tristrip indices of each submesh (or "fragment" if more accurately) and the begin index id in the indices buffer. You can load correctly the 2nd and the 3rd meshes with AXE if you had that patience, given that their vertices positions are correct in the first place. But there's no point in doing so if you've already understood how it worked.

[shakotay2]

let along the vertices need to be transformed to the correct positions with the corresponding bone transformation info

This important sentence should be included into any tutorial "How to rip 3D models from hex data".
(Took me years to understand the clumped mesh problem. )

[einherjar007]

Which Windows OS are you using? I never expect to see such an old-style UI, not even on WinXP.

I don't have very good eyesight, so I prefer a simple view, and I always use the classic view of Windows. The OS is Win7

The truth is, it's definitely gonna drive you crazy to load all the submeshes manually, let along the vertices need to be transformed to the correct positions with the corresponding bone transformation info. There's a submesh info table at 0x12AC where each entry takes 44 bytes and you'll find the count of the tristrip indices of each submesh (or "fragment" if more accurately) and the begin index id in the indices buffer. You can load correctly the 2nd and the 3rd meshes with AXE if you had that patience, given that their vertices positions are correct in the first place. But there's no point in doing so if you've already understood how it worked.

I have found that simply giving parameters does not give good results. I have been fortunate to have three advanced users who have given me scripts and information that work practically. I don't have enough experience and knowledge to understand it yet, but I will take the time to figure it out.

[einherjar007]

XBOX's Dynasty Warriros 3 (Sangoku Muso 2) also seemed to use something close to this format.
Looking at the results obtained with AXE and the results of the plugin, it seems that the face specifications are slightly different.

[Bigchillghost]

Done:

linkdataUS.png

[Bigchillghost]

The updated script:

fmt_CrimsonSea_xkmd.zip

[einherjar007]

Bigchillghost, thank you so much!
I would like to take a look at your script and learn what has changed!

[einherjar007]

I'm sorry, I think this is probably the last question.
Some files have a strange display, probably because the XYZ directions of each data are different.
If the Noesis script swaps this direction, what value should I change?

[Bigchillghost]

probably because the XYZ directions of each data are different.

No it's not that. There're 4 extra bytes before the vertex chunks so the recorded addresses are no longer correct. Sadly there's no obvious way to tell when there'll be a 4-byte difference so this is just an experimental workaround:

fmt_CrimsonSea_xkmd.zip

[einherjar007]

I see, thank you! The object I was seeing looked correct to some extent, and I thought it was in the wrong direction because it was stretched. I'm surprised that even a 4 byte shift will bring about such a result.

Certainly, in the old plug-in state, when I shifted the vertex start point of enemy8 by 4 bytes, it loaded normally.
ex) 5fac to 5fb0, 111d8 to 111dc
I was able to confirm that there was extra data of 00 in the binary.

*EDIT
Bigchillghost, thanks for the hint! There were some other weird models, but the hint that they contained extra data was very helpful. Shifting them will load most of them correctly. And yes, the size of the shift varies from model to model. It doesn't seem to be written somewhere. In the sample, it was a 4-byte shift, but there are models that shift by 8-bytes.

*EDIT2
It's like an adjustment. I think they are trying to align the start position of the vertex data with the position of 0x*0. Now I noticed that I manually corrected all the damaged model data.

[Bigchillghost]

I think they are trying to align the start position of the vertex data with the position of 0x*0.

The original xkmd sample you uploaded uses addresses that're not aligned by 0x10 byte:

vertAddrs.png

So unless this "alignment" is game-specific, there's no elegant solution to be compatible with all files.