I’d like to render a HDR effect to my scene, but I’d like to render it on a Shader Model 2.0 hardware.
I know this is possible, although SM2.0 doesn’t feature floating-point color buffers (see the HDRLighting sample from the DirectX9 SDK).
Can somebody explain to me what are the differences between rendering HDR on a SM2.0 and on a SM3.0 hardware, using OpenGL and GLSL? A mate told me that on a SM2.0 hw, I can’t perform correct blending. Any clues?
Real HDR (high dynamic range) use do need floating point rendering to escape the clamped [0-1] range. (SM 2.0)
But then if you want to add the bloom realisticaly, you need foating point blending (SM 3.0). Or fake it.
If you only want a “HDR effect”, go for the fake : take rendered frame, blur it, add-blend it, all with good old RGBA8.
EDIT : you do know that 100% flash sites are bad right ?
EDIT2 : corrected thanks to Humus remarks.
I know, the website sucks, but I haven’t had time to change it yet.
As for HDR, I’ve heard that it’s possible to store float values in RGBE format (i.e. 4 RGBA8 values to represent a 32 bit floating-point number), hence providing a “true” HDR effect. What about that?
RGBE is not 4 RGBA8. It is red-green-blue-exponent.
It is not too bad for storing HDR values to a RGBA8-compatible format . Interpolation may not be great btw.
Problem is you still need floating-point rendering first…
Originally posted by hardtop: I know this is possible, although SM2.0 doesn’t feature floating-point color buffers (see the HDRLighting sample from the DirectX9 SDK).
AFAIK, all SM2.0 cards support floating point render targets. All ATI cards certainly do, but I think nVidia only support FP RTs as RECTs for the GF5 series.
Originally posted by hardtop: Can somebody explain to me what are the differences between rendering HDR on a SM2.0 and on a SM3.0 hardware, using OpenGL and GLSL? A mate told me that on a SM2.0 hw, I can’t perform correct blending. Any clues?
On SM2.0 cards you don’t have FP blending. This means that you either have to tonemap in the end of the shaders (and get inaccurate blending), or you have to render each pass to a separate buffer then blend the RTs in the shader, or you have to avoid blending at all.
Originally posted by ZbuffeR: Real HDR (high dynamic range) do need floating point blending to escape the clamped [0-1] range.
There’s no clamping when you render to an FP buffer, so it’s not neccesary to use blending to escape the [0, 1] range.
Thank you all for your feedback. I didn’t know what was the difference between SM2.0 and SM3.0 hardware, specifically for the application of HDR technique. This makes things a bit clearer; altough I’m still not sure what can a SM3.0 do and a SM2.0 can’t…
And ZBuffer… uh yeah, sorry about that RGBE thing, I obviously didn’t get it correctly ^^
Tone-mapping is merely the process of remapping your rendering results to [0, 1]. A good formula for that if you want to get close to photographic behavior is 1 - exp(-exposure * value). To find a good exposure for a particular frame you can find for instance the average value of the render target. This can be had by downsampling it in a number of steps until you get down to 1x1.
For blooming you only need to blur the render target. You may want to do some contrast enhancement first though. Depends on how you want it to look.
Could you just please give me an explanation on what are the differences between HDR on SM2.0 and on SM3.0?
I read somewhere that there was a difference between both, and that “true” HDR could only be performed on SM3.0 HW. I think Half-Life 2 and Far Cry both require SM3.0 (GeForce 6800/7800) hardware to run HDR. Am I plain wrong, or did I miss something?
I can render to a FP rendering target on SM2.0 HW, so I can perform tone-mapping. I can also perform blooming by blurring the target.
If I understand correctly, the only difference is the way I’ll blend my blooming over my tone-mapped scene. With SM2.0 I have to stick to 0-1 blending range, whereas with SL3.0 I can perform FP blending. Right?
Well, the blending problem isn’t so much with adding the bloom. Sure you can use blending for that, but it’s probably even simpler to just add the bloom RT and the main RT together in the final tone-map pass. The bigger issue is that you may want to use blending for your lighting or for translucent objects. That’s harder to work around (but doable). For this reason some implementations (such as HL2) simply don’t use any floating point buffer, but put the tonemapping in the end of the shader instead. In that case you have to either choose between poor precision, non-linearity, or both. If the tonemap operator is a simple scaling factor, then blending will work as normal, but 8bits per channels will probably be an issue. If you have a photographic style tonemap operator, like 1 - exp(-k * value), then you’ll get non-linear output which may not look good when added together.
