Unpack DEC3N & UDEC3

Hi,

I have a small tool that im using to convert some mesh files. The mesh files have the normal's stored in either DEC3N or UDEC3 format. How do i unpack that to 3 regular floats cpu side.

Thanks heaps for any help,

DEC3N =INT_10_10_10_2
UDEC3N=UNSIGNED_INT_10_10_10_2
with x,y,z of the normal have 10bits, w has 2 bits.

Take a look at this here.


Quick idea:
DEC3N
uint32 compressedValue = ...
float x = float((compressedValue>>22) - 512)/511.0f;
float y = float(((compressedValue>>12) & 0x3ff) - 512)/511.0f;
float z = float(((compressedValue>>2) & 0x3ff) - 512)/511.0f;
UDEC3N
uint32 compressedValue = ...
float x = float((compressedValue>>22) )/1023.0f;
float y = float(((compressedValue>>12) & 0x3ff) )/1023.0f;
float z = float(((compressedValue>>2) & 0x3ff) )/1023.0f;


Thanks heaps Ashaman :-)
I didnt make the simple connection with the GL 10_10_10_2 format.

One other question, when using this format with just regular normals is the w component required for anything?
I thought i read somewhere a game (maybe one of the sims) used the w as some sort scalar & they divided xyz/w.

Sorry i am fairly new to c++ and bit shifting and the like is something i am yet to 100% understand. Is this correct for [color=#000000]UNSIGNED_10_10_10_2?


[color=#000088]
float w = float(((compressedValue) & 0x3ff) )/3.0f; //2^2 - 1 = 3


[color=#000088]0x3ff are 12 bits, you only need to use 2 bits:
[color=#000088]
float w = float(((compressedValue) & 0x3) )/3.0f; //2^2 - 1 = 3

To decide if you need to divide through w you need to know more about the format. The w coord is often 1 for positions and 0 for normals. The reason is, that it is more or less a indication if you want to rotate and translate a vector (w=1) or just want to rotate it (w=0) when appling a transformation. When transforming normals you only need to rotate them, so w could be 0.

An other case is, that w gets often !=0 and !=1 after appling projection. In this case you need to normalize the x,y,z values by dividing x,y,z by w. Often this is only encountered in a rendering pipeline and not when dealing with data formats.

I would assume that you can ignore the w coord for now.

Thank you that makes perfect sense now.