relmas

07-13-2004, 01:30 AM

I had this idea and I'd like some feedback from you guys:

for volume rendering I need to use greyscale textures with more than 256 levels (8 bits) so I figured out I could use a RGBA texture to encode 32 bits fixed point levels using a "base 256 encoding", each greyscale level would be encoded as

level = R*256 + G*256^2 + B*256^3 + A*256^4.

The thing is that I need to reconstruct a float value ranging from 0 to 1 from these RGBA coordinates in the fragment shader, this involves a sum of products followed by a division (pretty expensive)

Then I would perform my computations on that greyscale level for volume rendering (colorization and opacity attribution).

So my question to you guys is: is this reasonable, when you take into account the limitations of the output display (number of colors, number of pixels) I can't figure out where is the precision bottleneck in the pipeline. Even if I manage more precision on the input data, I have the feeling that the results will be scaled/truncated/quantized so that more than 8 bits textures will be useless. Are the fragment computation done with full 32 bits float precision per channel? is it possible to use an offscreen 128bits per pixel framebuffer and to perform 32 bits float alpha composition, and then scale and quantize the results for display?

for volume rendering I need to use greyscale textures with more than 256 levels (8 bits) so I figured out I could use a RGBA texture to encode 32 bits fixed point levels using a "base 256 encoding", each greyscale level would be encoded as

level = R*256 + G*256^2 + B*256^3 + A*256^4.

The thing is that I need to reconstruct a float value ranging from 0 to 1 from these RGBA coordinates in the fragment shader, this involves a sum of products followed by a division (pretty expensive)

Then I would perform my computations on that greyscale level for volume rendering (colorization and opacity attribution).

So my question to you guys is: is this reasonable, when you take into account the limitations of the output display (number of colors, number of pixels) I can't figure out where is the precision bottleneck in the pipeline. Even if I manage more precision on the input data, I have the feeling that the results will be scaled/truncated/quantized so that more than 8 bits textures will be useless. Are the fragment computation done with full 32 bits float precision per channel? is it possible to use an offscreen 128bits per pixel framebuffer and to perform 32 bits float alpha composition, and then scale and quantize the results for display?