DarioCiao!

01-17-2015, 05:44 AM

How can I pack more than 4 components into a RGBA (128 bits total, floating point) texture?

My GPU only support RGBA32 texture in vertex texture fetch, so I'm forced to use that pixel format

I need to pack ~8 bit and ~16 bits values so that I can access them in vertex shader after a texture fetch. It is ok for me to lose few bits of precision here and there, but I need to know how much I lose and where,

a dummy implementation would be (unpack RGB values from R channel of the texture), but I'm not aware of possible issues hided by GL abstraction (for example does the floating point conforms IEEE and so has 23 bits of mantissa?):

//unpacking

vec3 grb = vec3( floor(R/65536.0f), floor(R/256.0f), mod(R,256.0f) ); //green has 7 bits precision here. Additional precision by eventual leading zeros.

//packing

float Rpacked = floor(256.0f*b) + floor(65536.0f*r) + floor(8388608.0f*g);

My above implementation is quite stupid (assuming it is correct, I'm not even sure it is correct), because it relies only on the mantissa (well If I'm lucky enough so that the final resulting number has some zeroes in last positions in the mantissa I gain some bit of precision but hoping for luck is not a efficient encoding), while I could still exploit the exponent to store some additional info.

Actually I have 32 bits to store just 23 bits of information.

My GPU only support RGBA32 texture in vertex texture fetch, so I'm forced to use that pixel format

I need to pack ~8 bit and ~16 bits values so that I can access them in vertex shader after a texture fetch. It is ok for me to lose few bits of precision here and there, but I need to know how much I lose and where,

a dummy implementation would be (unpack RGB values from R channel of the texture), but I'm not aware of possible issues hided by GL abstraction (for example does the floating point conforms IEEE and so has 23 bits of mantissa?):

//unpacking

vec3 grb = vec3( floor(R/65536.0f), floor(R/256.0f), mod(R,256.0f) ); //green has 7 bits precision here. Additional precision by eventual leading zeros.

//packing

float Rpacked = floor(256.0f*b) + floor(65536.0f*r) + floor(8388608.0f*g);

My above implementation is quite stupid (assuming it is correct, I'm not even sure it is correct), because it relies only on the mantissa (well If I'm lucky enough so that the final resulting number has some zeroes in last positions in the mantissa I gain some bit of precision but hoping for luck is not a efficient encoding), while I could still exploit the exponent to store some additional info.

Actually I have 32 bits to store just 23 bits of information.