Will you explain how HDR is rendered?

For example, i'm doing it by converting the rgb value of the light contribution to a 'greyscale' scalar, modulating it with a user-tweakable parameter and passing it to the alpha component of the fragment. This way, destalpha will hold the accumulated lighting contribution factor, which is of course less precise than a real hdr buffer, but enough for 'more correct' glows.

 

If you have some sort of blending operation that involves partially adding and partially subtracting, you can instead of using multiple segmentations of a mesh and texture, you can just use one signed texture.

Also, with signed color data, you can store normal maps without having to bias and scale them to fit in a positive-valued format (e.g. 0 is actually 0 instead of 0.5).

 

Black hole rendering without changing state.

Also, I'll bet several algorithms that do not specifically deal with color might use the negative numbers. The penumbra wedge algorithm comes to mind.

 

And all this time I though there was an infinite range between 0 and 1.0, damn, I need to go back to school

 

ok, that could deliver higher precision than scaling/rescaling as you don't get to tinker with your original RGB ranges. i.e. you do it only once. still, how do you handle transparencies in this case? if you have a pixel with HDR info and you alphablend it with another such pixel, you need to carry the whole HDR factorisation right there, therefore alphablending becomes a rather expensive op, no?

 

better late than never! ; ) range and power/cardinality are fairly different things.

 

Right, the alpha portion (the "hdr info") will be correctly blended, but the rgb not - this is something i'll just have to live with. The point is, this is only to get correct glows, im not using it for anything else (no tone mapping). Kind of hack-ish, i know, but realtime graphics always is

 

That's not what I meant. 1.0 is not different then 3.4, 7.3x10^6745 or infinity. 0-1.0 alone doesn't give you a small or large range.