Ebirah.cmp contains a mesh: Ebirah_cmp.JPG (But the face indices don't seem to fit and I don't have the time to care for them.) f 1835 2264 1835 f 2264 1835 2264 f 1835 2264 1835 f 2264 1835 2264 f 1835 2264 1835 f 2264 1878 4044 f 1802 4004 1652 f 4042 1618 3927 f 1450 3923 1432 f 3706 1353 3702 f...

oh well, I've overviewed that your animation fbx file containes the mesh already. Everything is working fine: meshplusanim.JPG (I previously dragged this anim onto the mesh you uploaded. That's the reason for the ugly result in my last post.) But the really great thing with Noesis is that you can ex...

well, it's better (concerning the rotation) - but still reminds me of Ripley7: (If you display the skeleton (F6) you'll see that it's moving correctly.)

Noesis complains about a "Bone count mismatch". There are indeed Bip01_L_Toe01 , Bip01_R_Toe01 for example in your fbx mesh that I can't find in the bvh anim file. Sure you uploaded they suiting fbx mesh file? So basically I should export the motion in .fbx from blender I wouldn't rely too...

nice one !

MarieRose1301 wrote:The rotate 90 feature affects the animations only

since the skeleton is in the mesh file, I guess.
If so it could be helpful if you uploaded it, too.

, and couldn't find any of the vert numbers using hex2obj, I hope someone can help. from MOB_Cerberus_0 I can say that the vertex data (at 0xC00 or 0xC14?) isn't easy to solve - maybe compressed. There are 47 "frames", 64 bytes sized with floats, starting at 0x2c and a DWord face indices ...

nearest hit I had:

wrong subforum! did you try all comtypes? create a bat or cmd file with this line contained: call comtype_scan2 D:\test\comtype_scan2.bms D:\test\zoya_face.fbi D:\test [10000000] where D:\test is the folder which contains quickbms.exe, comtype_scan.bat, comtype_scan2.bms and zoya_face.fbi , the file...

Why you do 64 bytes offset on vertices data ? dunno what you mean by offset - mean vertex stride? It's 40 bytes (all params for hex2obj are decimal values except the startaddresses 0x...) From one 00 00 80 3F pattern to the next one it's 40 bytes - as simple as that. You'll learn it by experience a...

Roman wrote:But mesh look like boom.

It's the way orcs look like

RoadTrain wrote:Must have missed something..

nope - it's low poly models:

for barracks_damaged_01 the vertex stride is 28
but there are too many submeshes here - you'll need a script to build the whole mesh:

by this do u mean that the item have holes in it? if it is so then yes. I don't know what it means. A bounding box is the smallest box the object just fits into. is there any thing u want me to edit or to try at this vkm? we need to understand the meaning of the header data (DWORD at 0x18 might be ...

would make sense header Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000 56 4B 59 4D 69 00 00 00 01 00 00 00 00 00 00 00 VKYMi........... 00010 01 00 01 00 00 00 00 00 34 16 00 00 43 6C 6F 6E ........4...Clon 00020 65 66 72 6F 6E 74 20 66 61 63 65 00 00 00 00 00 efront face..... 00030 00 00 00 00 00 00 ...

having a look at PC18Body.vkm reveals: first submesh "PC18_Upper Body" vertex start: 0x78, 307 vertices, vertex stride 44 0x353C, 410 faces, 0x3540..0x4878, DWORD face indices 2nd submesh 0x6095 "PC18_Lower Body" There's unknown data from 0x4890 to 0x607C. You could overwrite the...