yep alternating.... my mxs code faceindices = for f = 1 to nindices collect ( 1 + ReadShort bstream unsigned; ) faces = for f = 1 to faceindices.count - 2 collect ( face = [0,0,0]; face.x = faceindices[f+2]; face.y = faceindices[f+1]; face.z = faceindices[f]; if mod f 2 == 0 then swap face.x face.y face )
it's not big endian, I was expecting at least 2 byte alignment (it makes it easier to "read" in a hex editor) but it's byte aligned which threw me :) (I think it's because they don't pad the texture name :/
Hey all! so I'm making a set of mod tools for a couple of video games as the tools are either non existent or outdated and no longer work on modern systems. I'm starting off with a simple converter for the game's model files that will convert them to Wavefront OBJ and then back again. These are proprietary file formats…
it also seems to be in big endian byte order or there is some very odd alignment going on :/ the raw data suggest first five faces would be... 1 2 3 4 5 6 7 7 8 8 9 10 9 11 12 that's one bad "chunk" file implementation..... the point of the doom chunk file format is the sizeof chunk in bytes (4 bytes after the 4 byte tag)…