LukeAndBobPro wrote: ↑Mon Nov 29, 2021 3:42 pm 1st of all: Don't play "Stupid" with me! [NO OFFENSE OR PUN INTENDED]

Calm down - I don't need to help you. So.

I've tried to use hexeditor on it, but it's very impossible to use because the tutorial doesn't properly explain the program's functions to me. Which tutorial are you talking about? A hexeditor usually is for displaying/editing hex data (as the name states), not for showing 3D models. Using hex2obj...

Do we have a chance that one develops a general plugin? That's not as simple as you may think of, for boss143 for example the layout is different. With a slightly patched scripts (with Vcount= 1966 and rotMat not used) you get this: . boss143-partial.png So more work to be done. Great script, btw, ...

moonpaladin wrote: ↑Thu Nov 25, 2021 6:01 am if someone extract the mesh

Yeah, that unknown "someone" we're all waiting for...

please attach to this post :'(.

Thing is that I have no idea how to identify the sub meshes for this layout.
.

moonpaladin wrote: ↑Tue Nov 23, 2021 5:48 pm oh I see (I was dreaming lol) ,you were able to load the submeshes?

Check it for yourself, please.
.

moonpaladin wrote: ↑Tue Nov 23, 2021 3:30 pmYou are getting this kind of meshes with hex2obj?

No, read the first sentence here again:

shakotay2 wrote: ↑Mon Nov 22, 2021 8:16 pm

What I get using hex2obj is the face indices only, at 0x333EBA 5220.
(Results in a vertex count of 1176.)

All parts clumped together, too much work for me for such a lowpoly mesh:
.

As a test I set the rotation of the skeleton's bones to 0.0 0.0 0.0 and as you can see, it's fine:
. So the problem is located in the rotation values.

You'll need to be a coder to get the vertices. But you could care for the face indices, I'm done with this point cloud: . ride20-Point-cloud.zip (vertices and uvs contained; normals disabled by #) edit: first block of FIs attached (which you can get from hex2obj ). (This 01 reminds me of another for...

My suggestion is to give the file(s) a structure, find out where's animation data and exclude those blocks from "your search for the mesh". This is animation data, obviously: . ride020_1.png The count is 187, well 188 (BC000000), don't be pedantic :D , so block size is 0x2340 (188x48 dec.,...

I'd guess for animation data - even where you'd expect mesh vertex blocks, it's not. Annoying 01 instead and other unknown data (rectangled lightblue): . strangeOnes.png But, hey, those damn.. 01 follow a rule! :D edit: well, it's indeed vertices :D , normals and uvs. After having skipped those 01 a...

I checked std.act in the hope it were simple, but seems it is not: the size of frame blocks is not constant: no, start address (blocksize:, rest is blocksize modulo 16), rest means remainder :D --------------------------------------------------------------------- As you can see remainder is not alwa...

Some final thoughts from my side concerning wrong uvs for FH5 models (keep in mind that the tool linked in my sig was for FH3 - I will not dig into this again for FH5.) But I checked those uvs using hex2obj to get a clue. The result for wrong uvs: the adresses are "off" (by 12 bytes in thi...