What I find is point clouds (here's normals, which look ok), but the face indices don't seem to fit. . a2_ground_mesh.png For the meshes, here for exampe is a strange offset in columns (look at the sevens), whatever, no time to fiddle around: ... 19061 16850 45582 16587 10677 16640 31754 16296 40958...

Hi kgal104, the face indices are bytes for the file you posted which hex2obj doesn't support. (maximum face index=182 -> vertexcount ) You may try out the tools from Bigchillghost or Lazov which should have that option. Here*s the obj file with "manually" created face indices: . test_bingeom.zip

Kotcrab wrote: ↑

Thu Apr 30, 2020 10:47 pm

I figured out a way to extract Fate/Extella and Fate/Extella Link animations from .mtb files. The process is a bit complicated but basically it uses the game itself to decode frames. This was simpler to do than figuring out the format details.

Very cool idea!

You'll need some coding to convert the text to a wavefront obj file for example. From Arrays "arrays-0" POSITION|NORMAL|TEXCOORD 0 25 { -384.000000 -12288.000000 0.000000 0.000000 0.000000 1.000000 0.000000 1.000000 ... you'd get v -384.000000 -12288.000000 0.000000 vt 0.000000 1.000000 ... Face ind...

Use File/SaveAs mesh in hex2obj. The uvs are the lines with "vt" in the created wavefront obj file (usually in same folder as the model file).

Use HF_UV as reh said. (And remove the 0x before the uv address 19344.)
. btw: don't open multiple threads on the same issue, please

sonicdude143 wrote: ↑

Sat Aug 29, 2020 8:05 am

when you go far it has multiple vertices and the UVs are wrong any ideas?

Could you be more specific, please?
As always I cared for the first submesh only and apart from some fiddling to get the uvs' start address it was not too hard:
.

Using hex2obj (view link in my sig):
. (uvs might need a deeper look at.)

.Model00p looks compressed (signature PCMDM). You'll need to uncompress them to get the model data.

So the uvs of the submesh here are half floats - mesh format doesn't look too hard but I usually don't care when solutions already exist.

(Too sad that the code is burried in a dll without source.)

Trophi Hunter wrote: ↑

Sun Aug 23, 2020 4:02 am

Noesis does import them but the UVS are broken.

What does that mean exactly? Looks better than expected:
. (Maybe a swap between half floats and shorts required, or vice versa, dunno, because the code is hidden in a dll.)

Using hex2obj (view link in my sig):
. (no time to care for face indices)

, but when I opened the axelrod.bin file in Hex2OBJ, it just gave me an error message when I tried to save it as an H20 file. The .bin file is NOT saved as H2O file, the params (addresses, counts) are. Rename or delete existing H2O files to save another one. So am I supposed to open the .bin in a h...

Edit: The main things I'm confused about are the .bin thing (specifically, how to turn the .vbuf and .ibuf files into one .bin) Create a .txt file (rename to .cmd finally) with this single line: copy /b axelrod_0.vbuf + axelrod_0.ibuf axelrod_0.bin and execute it in the folder where vbuf/ibuf files...

So I have to convert the .oct to a .bin somehow No - the bin is the binary copy of .vbuf+ .ibuf file(s). If you can't use hex2obj you'll have to wait for someone coding a (python) script. . axelrod.png - The link to the program wasn't working, ... Trust me, it is. Look at the bottom of that site: F...