Will you explain how HDR is rendered?

[reptile]

actually i don't see how that 'carrying over' can be done in the first place. the only thing i know of that helps simulating HDR on non-HDR hw is scaling + renormalisation of the color ranges, during which you (severely) lose precision.

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.

 

[ShootMyMonkey]

negative range for color?
which is the interest?

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).

 

[Inane_Dork]

negative range for color?
which is the interest?

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.

 

[SMarth]

0-1.0 isn't a big range

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

 

[darkblu]

actually i don't see how that 'carrying over' can be done in the first place. the only thing i know of that helps simulating HDR on non-HDR hw is scaling + renormalisation of the color ranges, during which you (severely) lose precision.

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.

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?

 

[darkblu]

0-1.0 isn't a big range

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

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

 

[reptile]

actually i don't see how that 'carrying over' can be done in the first place. the only thing i know of that helps simulating HDR on non-HDR hw is scaling + renormalisation of the color ranges, during which you (severely) lose precision.

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.

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?

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

 

[SMarth]

0-1.0 isn't a big range

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

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

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.