Hello. I'm deciphering the model structure for an old video game so I can see how my models look in the engine's hardware. The structure uses 6 bytes for a single vertex. Each vertex has 2 bytes for each axis. The vertices are as follows: the first byte takes a value of 255 to make a whole number of the second unit, while…
Hi, RN. 1.) There is some documentation, but it's loosely based and partially reverse engineered by other people; I had to manually edit bytes on my own to see what exactly the data does. The extra work doesn't matter in my opinion because it's been a good learning experience. I will look at the "half-float format". 2.)…
Thank you, sprunghunt. I have been using these, and they've been very helpful... However, I noticed that my values are much bigger than 0xFF - which is the full amount of a byte in a hex editor. Is there a way that I can lower the values instead of having them overshoot? Right now, the bytes are written in 8-bits:…
Another Edit: For those who were wondering, I have solved my problem with the vertex normals. Apparently, they are supposed to be offset from the vertex coordinates themselves. So, I came up with a couple extra Maxscripts to aid me, but this will work for now. Basically, after I create my model, I use a shell modifier on…
Hi, some observations: - How do you know that the format is supposed to be what you think it is, is there any documentation? (It sounds like the half-float format) - "Right now, the bytes are written in 8-bits: 0xAABBCCDD." <---- That's a 4-byte value, like a 32 bit integer or float. If your coordinates use two bytes of…
Hi again, RN. Yeah... That threw me off for awhile; gave me some good headaches. It really is strange, because I have come across no other models that use normals in this manner. Thank you for the extra idea about 'meshVertex.xys + meshNormal.xyz'. I appreciate the extra ideas that you have, and that you keep coming back…
That's odd. So it's not really a normal, it's more like "the mesh vertex offset by its normal", and the game probably derives the actual vertex normals from the vector 'offsetVertex.xyz - meshVertex.xyz'. In order to use your original mesh normals, try exporting this vertex normal data as 'meshVertex.xyz + meshNormal.xyz'…
I see what you mean, you have a byte for the whole part of the number and a byte for the fractional part of the number. You have 256 steps in that fractional byte, so each step could represent that 1.0 / 255 = 0.0039215... increment of the fractional part, like you mentioned. In order to fit those two bytes into a two-byte…
The first thing that I thought of is just to use Python instead of Maxscript. in python you can just use round( myNumber, 3) to round something off to 3 decimal places. This way you can keep you float values from being tool large to fit in a byte…