OGRE Wiki
Support and community documentation for Ogre3D
Ogre Forums
ogre3d.org
Log in
Username:
Password:
CapsLock is on.
Remember me (for 1 year)
Log in
Home
Tutorials
Tutorials Home
Basic Tutorials
Intermediate Tutorials
Mad Marx Tutorials
In Depth Tutorials
Older Tutorials
External Tutorials
Cookbook
Cookbook Home
CodeBank
Snippets
Experiences
Ogre Articles
Libraries
Libraries Home
Alternative Languages
Assembling A Toolset
Development Tools
OGRE Libraries
List of Libraries
Tools
Tools Home
DCC Tools
DCC Tutorials
DCC Articles
DCC Resources
Assembling a production pipeline
Development
Development Home
Roadmap
Building Ogre
Installing the Ogre SDK
Setting Up An Application
Ogre Wiki Tutorial Framework
Frequently Asked Questions
Google Summer Of Code
Help Requested
Ogre Core Articles
Community
Community Home
Projects Using Ogre
Recommended Reading
Contractors
Wiki
Immediate Wiki Tasklist
Wiki Ideas
Wiki Guidelines
Article Writing Guidelines
Wiki Styles
Wiki Page Tracker
Ogre Wiki Help
Ogre Wiki Help Overview
Help - Basic Syntax
Help - Images
Help - Pages and Structures
Help - Wiki Plugins
Toolbox
Freetags
Categories
List Pages
Structures
Trackers
Statistics
Rankings
List Galleries
Ogre Lexicon
Comments
History: HDR (High Dynamic Range)
View page
Source of version: 12
(current)
!!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. 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__. !!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. !!Do I have to convert my textures to HDR? 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). !!When I am outside it looks nice, but when I enter indoors it looks too dark 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. !!So... I'll just support both LDR and HDR and toggle between the two... 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. !! 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}
Search by Tags
Search Wiki by Freetags
Latest Changes
IDE Eclipse
FMOD SoundManager
HDRlib
Building Ogre V2 with CMake
Ogre 2.1 FAQ
Minimal Ogre Collision
Artifex Terra
OpenMB
Advanced Mogre Framework
MogreSocks
...more
Search
Find
Advanced
Search Help
Online Users
113 online users