2

I'm analyzing an rather ancient 3D mesh format (from 1995 or 1996). Inside the files, there are blocks of what I think are vertices.

For example, the following is a direct hex dump from such a part:

7855DAFF
5BE60E00
353D0200
C82D0B00
5BE60E00
353D0200
C82D0B00
5BE60E00
B61AEDFF
7855DAFF
5BE60E00
B61AEDFF
7855DAFF
59D2FDFF
363D0200
C82D0B00
59D2FDFF
363D0200
C82D0B00
59D2FDFF
B61AEDFF
7855DAFF
59D2FDFF
B61AEDFF

These blocks are introduced by a little header, which has a value that could be the number of vertices that are present in the corresponding data block. For this excerpt, there is a 0x08. Since we have 24 values of 32bit, I think it is safe to assume that these blocks are actual vertices (0x08 * 3 = 24, with xyz). Other headers also have this value and their data blocks also have the exact number of dwords ([value in header] * 3 => number of dwords).

But, now I'm struggling at deciphering the number format that was used. It isn't IEEE754; a friend of mine also pointed out that the hardware that was used these days didn't perform well with floating-point numbers and therefore often fixed-point numbers where used.

So, any idea what kind of format this could be ?

3
  • I wonder if the fact that every word ends with either FF or 00 has meaning? Or are you sure they are not simply 32-bit integers?
    – 6EQUJ5
    Jun 3 '14 at 8:28
  • Do you know, or can you find out, which kind of hardware that was? Knowing which processor was used could help a lot, and even if you just know "it was some kind of bumblebee", there might be someone here who worked with bumblebees 20 years ago and remembers some details. Jun 3 '14 at 9:02
  • It was mainly designed for the 80486 (minimum requirements of 33 MHz), so I think it is safe to assume 32bit dwords.
    – martin
    Jun 3 '14 at 9:18
5

if you reverse the byte order, and assume signed numbers you get these triplets:

-2468488  976475   146741
  732616  976475   146741
  732616  976475 -1238346
-2468488  976475 -1238346
-2468488 -142759   146742
  732616 -142759   146742
  732616 -142759 -1238346
-2468488 -142759 -1238346

these seem like the coordinates of the corners of a 3d cube

x=(-2468488 .. 732616)
y=( -142759 .. 976475)
z=(-1238346 .. 146742)
5
  • Ah, it could be so simple. I'll try it with other, bigger sets of vertices and import them into Blender to see whats going on.
    – martin
    Jun 3 '14 at 9:31
  • Yeah, that's it. Just simple 32bit signed ints. I successfully managed to extract the vertices. Now I need to normalize them. I want the dimension with the largest extend to lie between 0 and 1 and the smaller dimensions to lie between 0 and <0. Aspect ratio should be maintained. Should I ask here or somewhere else? What's the right way?
    – martin
    Jun 3 '14 at 13:05
  • You may want to state why you reversed the byte order, because I was initially slightly confused as to that point. Jun 3 '14 at 13:11
  • 1
    The byte order has to be reversed because the numbers are saved in little endian format.
    – martin
    Jun 3 '14 at 13:14
  • @madmartin: i think that is more a math question, what you are looking for is called translation, and scaling. Jun 3 '14 at 19:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.