Real world example where 24-bits isn't enough for graphics.

[bloodbob]

Well not really doing any shader stuff till today ( was fiddling with the shaders in humus' latest demo ) I really didn't expect to hit the 24-bit limit so soon.

Where I hit the 24-bit limit for reference was converting a texture into HSV modifing the hue value and converting back to RGB. There is conditional code based on the hue value but with the lack of precision certain textures ( such as enivorment maps in humus' demo ) end up following the incorrect branching.

Can anyone else give me some real world examples where 24-bits just isn't enough.

 

[tb]

The shader 23 (water colour like rendering) in ShaderMark v2.0 is a real simple shader(summed area tables), but if you run it at high resolutions (1600x1200) you will see some wrong coloured pixel on the r3xx. With the refrast. they are gone, I think because of the 32 bit prec. per component.

Thomas

 

[Humus]

HSV to RGB and back should work just fine with 24bit. Heck, I implemented that using 3D texture lookups in 8bit/channel when I was at ATI, and the results were virtually identical to those using full math. The full math example is included in the latest RenderMonkey if you want to take a look at it.

 

[bloodbob]

My water.shd try it out and notice the pink stuff. Then remove the line of code as mentioned in the comments. I have you a nicer way for me to wrap the range please feel free to tell me.

By the way normal its a range 0-360 but for obvious reasons I've worked with 0-6.

[Vertex shader]

float4x4 view_proj_matrix;
float3 camPos;

struct VS_OUTPUT {
   float4 Pos: POSITION;
   float2 texCoord: TEXCOORD0;
   float3 viewVec:  TEXCOORD1;
};

VS_OUTPUT main(float4 pos: POSITION, float2 texCoord: TEXCOORD0){
   VS_OUTPUT Out;

   Out.Pos = mul(view_proj_matrix, pos);
   Out.texCoord = texCoord;
   Out.viewVec = pos - camPos;

   return Out;
}


[Fragment shader]

sampler Tex: register(s0);
sampler Env: register(s1);
float off;


float4 main(float2 texCoord: TEXCOORD0, float3 viewVec: TEXCOORD1) : COLOR {
float4 texy = texCUBE(Env, float3( texCoord , 0.5 ));

   

   float min = min( min (texy.x, texy.y), texy.z );
   float maxy = max( max(texy.x, texy.y), texy.z );
   float delta = maxy-min;
   float s = delta / maxy;
   float h= ( texy.y - texy.z ) / delta;
  if( texy.x == maxy )
   {

   }
   else if( texy.y == maxy )
   {
   h = 2 + ( texy.z - texy.x ) / delta;
   }
else
   {
   h = 4 + ( texy.x - texy.y ) / delta;
   }


if( h < 0.0 ) h+=6.0;
h=clamp(h, 0, 6.0);//(h,6.0);

h=frac(h/6.0)*6.0; /// THE PROBLEM LIES HERE WHEN I DO MODIFICATION HERE
// AND THEN USE FRAC TO WRAP THE VALUES TO THE RANGE [0,6] I LOOSE TO MUCH PRECESSION
// NO MODIFICATION IS BEING DONE IN THIS CODE REMOVE THIS LINE AND NOTICE THE ARTIFACTS ARE GONE

int i = floor (h);
float r,g,b;
   float f = h - i;       
   float p = maxy * ( 1 - s );
   float q = maxy * ( 1 - s * f );
   float t = maxy * ( 1 - s * ( 1 - f ) );

if( i == 0 )
   {
   r = maxy;
   g = t;
   b = p;
   }
else if( i == 1 )
   {
   r = q;
   g = maxy;
   b = p;
   }
else if( i == 2 )
   {
  r = p;
         g = maxy;
        b = t;
        
   }else if( i == 3 )
   {
  r = p;
         g = q;
         b = maxy;
   }else if( i == 4 )
   {
   r = t;
         g = p;
         b = maxy;
   }
else{
r = maxy;
         g = p;
         b = q;
}

   return float4( r,g,b,0);


}

 

[Humus]

Well, the == operator is always sensitive to precision. Especially since DX9 HLSL implements floor(x) as x - frac(x). So you should be using < instead. Like this:

if( h < 1 ) 
{ 
   r = maxy; 
   g = t; 
   b = p; 
} 
else if( h < 2 ) 
{ 
   r = q; 
   g = maxy; 
   b = p; 
} 

...

 

[bloodbob]

Spanks humus very nice still I guess this is where we need true integer support I assumed incorrectly that it would return the closest float representation of the integer.