Thread: Representing floats with color?

Storing colors as floats is not about high dynamic range unless the hardware can use floating point textures. Normalizing colors is an ancient art that has been around for a long time. It's far easier to do color calculations on normalized rgba's than it is to do them on concrete values within a certain range.

In ALL of my recent shaders colors are ALWAYS sent to the card as floats. You gain nothing except extra memory consumption when you store bitmaps in memory as floats. High dynamic range comes from post-processing on a scene or image and has nothing to do with how the data is originally stored unless you have some very very specific hardware I've not heard of.

High dynamic range is accomplished by taking an original scene and applying a post-process luminance pass. Then the result is run through a gaussian filter on a floating point texture. The final result is then mixed back into the original scene and the result is rendered to the screen as a screen-sized quad or screen-aligned quad. Some techniques also do a tone map pass and several other passes for different type of post process effects. I suggest you do some googling on high dynamic range rendering and faked high dynamic range rendering. The Shader X series of books all cover this as well as a host of other shader-based books like GPU gems.

Textures when sent to the video card are already converted into floats but you gain NOTHING from this except ease of calculation. You cannot represent an infinite amount of values between 0 and 255 just because you use floats and you also do not gain ANY color depth unless your system supports floating point textures and/or render targets. Your video card would have to support a floating point primary buffer in order to actually gain color depth. This also would depend on your display's ability to reproduce these discrete values. Even IF your card does support a floating point primary buffer there is still a finite amount of color representations available.

I'm still completely lost as to what you gain here, why you need it and why it is any different from what has been done in games since DirectX 9 and floating point textures were introduces. Even in DirectX 8 at the shader level colors were represented as 4 floats. I see nothing revolutionary here.

If you could store an infinite amount of data in a floating point array then I would store my terrain height maps as floats. However storing them as unsigned char arrays yields plenty of information. All I do is then scale the data in the array to arrive at the final world height. The theory is the same whether it be color or heights you are representing. Array...IE textures have a finite resolution and a finite color depth. Nothing you do can or will change that. The only way I know of to get extremely smooth hills (IE: extremely smooth color variations in your case) is to filter the data in the array.

Also you are killing your bus here by forcing it to pass in 4 floats that are 32 bits each. That is 128 bits of data per texel going across the bus to the video hardware as opposed to 4 bytes or 32 bits. You are passing 4 times more data across the video bus than you need to and with no benefit.
With the main slowdown and bottleneck these days being the video bus I fail to see how this is a smart move. If you want high dynamic range rendering then do it on the card and not in software.

The reason he do what he does is so he won't have to allocate another buffer for his per-pixel-float-value (thickness). Instead he stores it in the bitmap memory (since those colors are of no further use after the thickness has been calculated).