Trapt (PS2) Help Viewing/Exporting .smi models

[Biohazard4x]

Hello once again,

Im trying to View/export models inside the PS2 game, Trapt (Kagero II: Dark Illusion). These .smi files are locked behind 2 types of archives the "game.dat" which has "arc" which are a another form of archive having several files within them. Inside these .arc files a ".smi" file which contains the models within them and supposedly contain several meshes inside them.

Thanks to a friendly fellow on discord by the name of, DKDave, we have been able to identify many parts of the smi file such as, vertices', Normals, and UVs. Faces offset has yet to be found.

Below is his identification of the .SMI file of "c01f_a.smi"

There are quite a few meshes in that file.
There's a table at 0x1868 which contains the various offsets for each mesh.
Just as an example:

vertices at 0x2680 as Floats (stride = 16, some other meshes are 32) - number of entries is 684,
Normals at 0x5140 as Shorts (stride = 8),
UVs at 0x66a0 as Floats (stride = 8).

Faces are not stored that I can see


He went on to make a Noesis script to import them, but since faces offset has not been found, he did the idea of auto-generating triangle strips. This simplys deforms the model...




Here is the link to script...
*Link Removed*

"...it draws all the meshes in the file. Some of it's guesswork ... I'm guessing either the faces are stored somewhere else or there's some weird formula to calculating them ... The UVs are also wrong..."

Like I said I in no way helped made this script all credit goes to, DKDave.

So any help on trying to make a script to view or export them to preferably OBJ will be highly appreciated.
Thanks.


Below I have attach the file i am trying to view, "c01f_a.smi". Along with other samples.

[Biohazard4x]

I found more .smi models, way smaller in size of 5kb and smaller these have different offsets then describe then above though since these are smaller in size, so they will be easier to manage. Still trying to crack the code to properly open them!

Below I have Attached them...

dummy_models.zip

[Biohazard4x]

After more diving we have possibly found where faces offset is stored at in these models.
In this pic this is the unknown table we are having difficulty translating...



it's just a case of how to interpret that table - each entry is 8 bytes, and the last byte of some entries is 0x80, which might indicate where to split the faces and start a new face.

Each mesh part always has this table, so it must be needed.


I've found where earlier in the model it points to this part of the model, specifically this unknown table.
In first model c01f_a at offset 1b68
this 3 byte array E0 66 03
convert to little endian and it points to this unknown table
same goes with the others file

dummy_model.smi - 0A30
cone.smi - 100


If anyone knows how to decipher this please let us know!

[chrrox]

it looks like its auto generated strips with a draw flag.
look at my time splitters script for how to handle this.
https://forum.xentax.com/viewtopic.php?t=9994

[DKDave]

Thanks, chrrox - useful info as always! So if the UInt64 value has bit 63 set, that and the previous 2 entries are not valid faces. There are some other flags in there that probably do something, as not everything is perfect yet.

But some objects look correct now, so at least it's making good progress:

[Allen]

The vertex position of the skinned model in this game needs to be multiplied by the corresponding bone matrix.
Thanks DKDave for the previous research.
The script is modified based on DKDave's version.
I added the parse of faces and skins, bones, and repaired vertex positions.

Edited:
Fixed material wrong.

[DKDave]

Thanks, Allen.

They don't make it easy, do they!!

[Allen]

Thanks, Allen.

They don't make it easy, do they!!

Indeed it is.
I think the hardest part is the position of the vertices of the two weights, which I couldn't figure out at first. At first I used boneMatrix1*pos1*weight1 + boneMatrix2*pos2*weight2 but always got the wrong position. Later, I carefully compared the data and found that the pos data of the local coordinates is the result of multiplying the weight, so I reversed the division, that is, (pos1/weight1) to get the correct local coordinates, and then multiply by boneMatrix1 to get the correct result.