HDR stands for High Dynamic Range. In this article we'll refer to the lack of "HDR" as LDR.
Normally rendering without HDR means your framebuffer contains colour values. 0 stands for black, 1 stands for white.
In comparison rendering in HDR means you will be storing light values like a real camera does when the light burns through the photographic film, or reaches the CCD. 0 means complete absence of light. The kind you would probably get inside a black hole (this is very important! because using 0 to represent dark or shadowed areas is no longer realistic!). "1" is just a measure of light; and normally this means a very, very dim light.
Ogre 2.1 provides an HDR sample under the folder Samples/2.0/Showcase/Hdr. Make sure to read the source code comments!
In Ogre 2.1's HDR sample we use lumens, which is a measure of light. For example direct sunlight on a perpendicular surface during a bright day is ~97.000-98.000 lumens.
This means you can start using parameters from real life to set how bright your sun & lightbulbs should be.
In code you would set the light in lumens:
light->setPowerScale( 97000.0f ); //Note due to floating point precision reasons, the HDR sample divides all lumen values by 1024: light->setPowerScale( 97000.0f / 1024.0f );
You may need to tweak the values a little because real time graphics rendering often don't have a robust Global Ilumination solution, but it gives you a great starting to point to achieve convincing results very quickly.
The problem with LDR is that you have to tweak colour values over and over again until it looks they way you desire; whereas with HDR, using real life values lets you approach that result much quickier, and adapts generically to most scenes.
That LDR lighting setup you spent days tweaking for a scene? You can't clone it to a different scene because now it looks like crap. This doesn't happen with HDR.
How do I enable HDR? I've analyzed the sample and all I see is the postprocessing part. How do I tell Ogre to render in HDR?
HDR often consists of three parts:
- Rendering to a (16-bit) floating point with lighting parameters set in lumens.
- Calculating Bloom (optional) to mimic lens optical aberration (it makes very bright things glow).
- A tonemapping operation that converts the light data into colour data so that it can be displayed on screen. The tonemapping step needs a parameter such as exposure in EV. This exposure is either artist defined or user controlled. High EV values make dark scenes brighter, low EVs make bright scenes darker. Tonemapping also performs eye adaption over time.
So bottom line: there is no "tell Ogre to render in HDR". Rendering in HDR only means you have to render to a floating point RTT, with your light parameters set in lumens.
Not necessarily. In real life motion blur happens because the photographic film/CCV sensor was exposed too long to light, and thus light begins to accumulate in the pixels. This has an interesting property: motion blur affects brighter spots much more than darker spots.
This property cannot be properly represented in LDR or if motion blur is applied after tonemapping. Because you will be working with colour data instead of light data. However, if the motion blur is done to your HDR framebuffer before tonemapping, you will get higher quality blur.
The same happens to other operations that work on light instead of colour, such as Depth of Field. CryTek has a SIGGRAPH from 2011 "Secrets of CryEngine 3" where they describe how they perform motion blur and DoF before tonemapping.
Beware, applying these operations to a 64bpp or 128bpp floating point texture takes a bigger performance hit than operating on the tonemapped result which is often stored in 32bpp.
Bloom can be done to LDR. In fact we have a wiki article about it. However just like Motion Blur and Depth of Field, Bloom works much better on light values (HDR). Because it is light what bleeds through the lenses of the eye or camera, not colour data.
No. While there can be some exceptions for certain diffuse textures, most of the time this isn't needed.
Where HDR textures are useful is for environment cubemaps. The sky is very bright while the ground is not as much; thus HDR cubemaps will ensure they will automatically adapt to your lighting conditions.
If you don't have HDR cubemap textures it's not the end of the world. You can just tweak it with a multiplier; but it won't adapt to every situation automatically as you change sun & GI parameters (in lumens) and exposure, you will also have to tweak the cubemap multiplier.
When the camera looks at bright spots it looks nice, but when I look at mostly shadowed areas, the lit areas are heavily overbloomed and auto-exposure keeps jumping between dark and bright as I move the camera
While sometimes this happens in real life to both eye and camera; most of the time this is caused by lack of proper ambient colour settings or GI. If you forgot to set the ambient colour (i.e. it is at 0 or 0.2), when you look at the shadowed areas you will look at 0-1 lumen which is as dark as the void of the universe. Use sane ambient colour parameters so you never look directly at 0 light (which is impossible or near impossible to witness on earth).
Here Global Illumination would solve the problem. But if you lack GI like most games, you need to write a simple probe system. Once you enter the range of the probe (i.e. when you enter indoors), you have to smoothly change the exposure settings so that it feels right.
I strongly recommend against that. Lighting setups in HDR & LDR tend to look very different. While you can support both, it will have to work more than twice. One to set the HDR parameters, more than twice the work to make LDR look even remotely close to the HDR one.
For more information see the HDR sample under the folder Samples/2.0/Showcase/Hdr
The sample shows how to gather real world info in lumens, and set the exposure values.