I finally finished going over the patches submitted to OGRE this weekend, and the permission requests for extending the OGRE license model in Eihort have gone out. In the end there were 60 people we had to approach, from a little over 500 patches. Responses have already started trickling in.
I finally got back to working on a HDR compositor this evening (there are now 13 compositors in the compositor demo, so this will make it 14). There are 2 main components to HDR rendering - tone mapping and bloom. ‘Tone Mapping’ basically means you render the scene at a really high dynamic range (to a texture), and then decide how to map that source information to a smaller dynamic range for display (typically using an exposure setting). This varying mapping range is what makes the amount of detail you can see in the dark change depending on how much other light is in view, just like the adaption of your iris as you go from light to shade. ‘Bloom’ is about faking the glare / light bleeding when looking at very bright areas. So, this is all well and good - with our compositor framework and a few shaders this shouldn’t be too bad. However, there is a caveat to this. Transparency is an utter bitch to do when rendering HDR using tone mapping. That’s because you have to store the rendered scene in a surface capable of storing high range values (e.g. floating point targets), and these targets cannot handle blending on most cards. It’s possible to avoid using a floating point target by using a format like RGBE (common exponent in alpha, mantissas in RGB), but then you realise that regular colour blending math just doesn’t work between numbers with different exponents, and you’ve also burned up your alpha channel so can’t perform alpha blending. This is bad enough when you think about losing transparent objects, but even worse is that multipass shaders can’t work, because they use scene blending too. A knotty problem.
The DirectX and ATI samples avoid this by just not using any transparency or multipass effects. Crafty. Another approach is to skip the tone mapping entirely and just do the bloom (which only requires a separate bright pass, the main render can be performed as non-HDR rendering), although this is not true HDR and you can have problems with transparent objects that should have been in the bright pass. Valve faced these problems when working on their HDR path (and they seem to have tried and discarded several approaches). I’m not sure what their final approach for Lost Coast was (I ‘lost’ it when I reinstalled my machine so can’t analyse it now), but since they clearly use multipass shaders my suspicion is that they separate each layer of the multipass effects and render them one at a time into a render target, then ping-pong to another target to render the next layer, pulling in the previous layer as a texture (if anyone has more accurate info, let me know - I’m just going with what I think they’d do). This allows you to do proper scene blending / multipass even on a floating point target that doesn’t support blending, but is rather more expensive even before taking into account the additional bandwidth a floating point target costs you.
I really don’t want to do just a bright-pass / bloom since I’d feel a fraud calling it HDR then, but I don’t really have time to take the full-on Valve approach either. I think I will take a leaf out of the Dx9 / ATI book and use a scene which doesn’t need any transparency for the sake of performing proper tone mapping. Users will have to take the demo with a health warning that transparency / multipass materials will throw a brand new spanner in the works of any HDR pipeline and ramp up the complexity level.