History: HDR (High Dynamic Range)
Source of version: 8
Copy to clipboard
!!What is HDR and why do I need it for?
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 [https://en.wikipedia.org/wiki/Photographic_film|the light burns through the photographic film], or [https://en.wikipedia.org/wiki/Charge-coupled_device|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!
!!You said "1" is a very dim light, but what does this mean?
In Ogre 2.1's HDR sample we use [https://en.wikipedia.org/wiki/Lumen_(unit)|lumens], which is a measure of light. For example direct sunlight on a perpendicular surface during a bright day is [https://en.wikipedia.org/wiki/Sunlight#Summary|~97.000-98.000 lumens].
This means you can start using [http://lumennow.org/lumens-vs-watts/|parameters] from [http://www.greenbusinesslight.com/page/119/lux-lumens-and-watts|real life] to set how bright your sun & lightbulbs should be.
In code you would set the light in lumens:
{CODE()}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 );{CODE}
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 [https://en.wikipedia.org/wiki/Optical_aberration|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 [https://en.wikipedia.org/wiki/Exposure_value|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.
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 set in lumens.
!!Do you need to apply bloom and tonemapping right away?
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.
{IMG(src="http://2.bp.blogspot.com/-dX6CsmhX5DU/USPGozzLl4I/AAAAAAAAAXs/FaucAFTGVJY/s1600/DSC00835.JPG",thumb="y",width="600",desc="Light affects motion blur. Notice how the upper right side and the phone itself isn't blurred, while there are extremely visible light streaks (real life photo)")}{IMG}
The same happens to other operations that work on light instead of colour, such as Depth of Field. CryTek has a SIGGRAPH from 2011 "[http://www.crytek.com/cryengine/presentations/secrets-of-cryengine-3-graphics-technology|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.
!!Do I need HDR to apply bloom? Can it be done in LDR?
Bloom can be done to LDR. In fact we have ((Faking HDR|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.
!! More info.
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.
Some screenshots:
{IMG(src="http://i.imgur.com/5iYMXRT.jpg",width="600",thumb="y")}{IMG}
{IMG(src="http://i.imgur.com/alRYcDm.jpg",width="600",thumb="y")}{IMG}
{IMG(src="http://i.imgur.com/5uDDnyw.jpg",width="600",thumb="y")}{IMG}
{IMG(src="http://i.imgur.com/8j9jgRQ.jpg",width="600",thumb="y")}{IMG}
{IMG(src="http://i.imgur.com/wxfQnXP.jpg",width="600",thumb="y")}{IMG}
{IMG(src="http://i.imgur.com/MAQkzg3.jpg",width="600",thumb="y")}{IMG}