Puting it into a 16 float is the hard problem. If you would have a 16 bit int you could use a 5:5:6 distribution. I don't know what your scatter value means and what value ranges they have, but there are other options.
One option is, that you can reconstruct one value from the other two (maybe using a mapping to transform the scatter value in a better representation). This way you only have two values, which could be saved as decimal number like "left_value + (right_value/MAX_RIGHT_VALUE)". This way you save the right value as fraction. Though you need to ensure that your base values are integer values and don't get too high.
He can do that trick with normals and store just xy (even though he has to be careful in which space they are as z can be negative or positive).
for several ways of compressing your normals in gbuffer.
But since he is talking about inscatter I would guess maybe he means the accumulated direct lighting and in that case we are in the context of manging hdr values.
So I would suggest if you are on PC just go for a 16bits frame buffer and use CIE to RGB conversion while tonemapping your luminance and then convert from CIE back to
RGB with the adjusted/tonemapped luminance. That will preserve your hue and saturation as it will allow you to work on just the luminance.
The need to store or compress values in smaller buffers is more relevant on consoles where the bandwidth problem is more present and, also, in the case in which you don't
support floating point blending (which is the case on PS3 if I don't remember wrong). A good approach is described in shaderx7, using LogLuv color space compression to
store HDR value in 8888 unsigned. The only disadvantage is that you can't blend in LogLuv space but there is a trick to do it and that is explained in that article.
Also you can couple that approach with a light prepass renderer scheme to reduce the bandwidth requested to your gbuffers even more, but at the cost of making two
Edited by MegaPixel, 27 September 2012 - 02:12 AM.