as I wrote: "I never would" :D Guess you've to code it manually in python with two nested loops for example. I tried string = self.inFile.readBytes(100) index = string.find(b"\xFF") and astonishingly index contained a correct offset address. But iirc find() was intended to be use...

the idx should contain offsets into the bin file, iirc
I can't get fiitting offsets from the bin/idx pair you provided.

But there's much uncompressed data in the bin - search for 'skeleton' to see what I mean.

Got some skeleton at 0x3d50, FVFsize=64:

I really appreciate that you spent your time to help to solve this problem. Thanks again! Your welcome - but it's a workaround only. The problem is solved once we got the formula to skip the bones block. It's 0x12FC..0x1638 = 0x33C = 828 dec. (104) 0x105c..0x13ac = 0x350 = 848 dec. (80) The value i...

it can be done rather simple in this case: skip the bone names and search for the first float value.
You'll need to know how floats are expressed as 4 hex values, first vertex: x,y,z -> 3 floats -> 3x4 hex bytes (little endian):

A48CB837 2099FB40 B2A21441

don't have the time to care for the script but a quick glance at 100201_1_02_0000.dxg reveals that the startaddress of vertices: 0x12fc used by the script is deadly wrong, it's 0x1638. Simply add self.inFile.seek(0x1638) before mesh.vertBuff = self.inFile.readBytes(numCoords * 12) Take care of the i...

to my knowledge the bin file is worth nothing without the suiting idx

did you look here: viewtopic.php?f=18&t=13213&p=108870&hil ... ty#p108870
?

[placeholder2]

[placeholder1]

This thread is a reminder for myself to get the skel2smd extractor released 'til the end of 2017. (I'm struggeling with this idea since 18 + 9 months now and seems I've to push myself a little bit.) It shares the same basic idea like hex2obj , that ugly mesh extractor, that requires to search for &q...

"parsed it"? Looks like autocreating face indices - not reading them from a gmi file (as I thought you did)? That's the reason why there's no shifting of indices (f1=f2; f2=f3) at the end - compare here: http://forum.xentax.com/viewtopic.php?f=16&t=12804&p=116369&hilit=+duplica...

If it is a tri strip then where is the delimiters? be informed that there's tristrip formats which don't use a delimiter (0xFFFF) in face indices blocks. Looking at PC00F_MODEL_P_M_BodyALL_FR_xScAlphaTest.g1m there's no delimiter - but it's tristripped face indices. (You could easily check it using...

Once you've found out that the FVFsize (vertex stride) is 56 here the format appears to be pretty simple:

zaramot wrote:it's using edge compression,

for the face indices, I guess? How did you get them?

Noesis is the only tool I know which handles edge compression: (flatz wrote an edge decompressor but didn't release it, afaik)

startaddress of face indices probably wrong - use 0x10B56 for the body, 0x173a3 for the bow