How do you make it easy for your artists to author content for an HDR renderer? What kinds of tools should you provide, and what workflows need to change, in going from LDR to HDR?

Note that I'm not asking about the technical aspects of implementing an HDR renderer, but about best practices for creating materials and lighting in HDR. I've googled around a bit, but there doesn't seem to be much about this topic on the web. Can anyone point me to some good resources on this, or share their own experiences?

Some specific points:

  • Lighting - how can lighting artists pick HDR light colors? Do they have a standard LDR color picker and then a multiplier? Is the multiplier in gamma or linear space? Maybe instead of a multiplier it's a log-luminance? Or a physical brightness level, like the number of lumens? How will they know what multiplier/luminance/brightness is "correct" for a given light?
  • Materials - how can texture artists make emissive color maps, such as neon signs, TV screens, skyboxes, etc? Can you paint one as a regular LDR (8-bit-per-channel) image and apply a multiplier (or log-luminance, etc.)? Are there cases where it's necessary to actually paint HDR images? If so, how do you go about this in Photoshop (or other software)?
  • 3
    \$\begingroup\$ This might be helpful: developer.valvesoftware.com/wiki/HDR_Skybox_Creation \$\endgroup\$
    – Tetrad
    Oct 11, 2011 at 18:46
  • 1
    \$\begingroup\$ @Aralox, I haven't found out anything about how other teams/companies do this. We have been working on this subject at my company, but I can't publicly reveal anything about it either (yet). I hope to eventually be able to talk about our workflow, though! \$\endgroup\$ Dec 19, 2011 at 18:06
  • 1
    \$\begingroup\$ I'd really like to see what people have to say about authoring HDR content without using photo sources. \$\endgroup\$
    – user14497
    Mar 27, 2012 at 0:51
  • 1
    \$\begingroup\$ Remember that this is ancient history, but yes the lights outside were literally just set much brighter than those in the cave and the rendering engine had to cope. Volumes were used for ambient and tone controls. The idea was that a rock doesn't itself become HDR, it's just a rock and the light hitting it is what makes it really bright or dark relative to what the render thinks is a gray exposure. I'm sure you've seen early HDR where the "exposure" keeps adjusting to where the player is; a fad of the time. \$\endgroup\$ Mar 27, 2012 at 22:03
  • 2
    \$\begingroup\$ I have a photography background, just an instinctive call that "outside" is maybe 4-5 f-stops brighter than "inside" a moderately lit cave entrance. \$\endgroup\$ Mar 27, 2012 at 22:47

3 Answers 3


I think we're still somehow in the "caveman days" Patrick Hugues describes in his comments.

You don't want details about renderer implementations, but let me clarify things a bit anyway: you'll understand why. HDR in game engines is mostly about having "wider" values for the rendering output (the framebuffer). Typically 16 bits floating point that can go above 1.0, instead of 8 bits integers that just give us 256 values in the [0,1] range. This output is then converted to LDR using a tone mapper, so the screen can display it. To me, the real "HDR authoring" would be in tweaking this tone mapper, so you'll want to give as much control as you can to your artists on this. There will be some kind of shader involved, so either you've got technical artists that can deal with it, or you hardcode it and expose the most useful parameters.

I'm not sure that you'll necessarily need 16 bits lights, except maybe to create lights that emit "whiter than white". But if you want to, in whatever editor you use for your lights, you'll need some kind of color picker or a bunch of sliders that gives you those floating point values. Oh, that's if you want a GUI, you'll probably just start with plain text floating point values in a file.

HDR textures (16 bits per channel) exist but aren't widely used, maybe just because that would take so much more memory than regular LDR textures (8 bits per channel). I also suspect more hardware limitations on current-gen consoles, so most of the big game engines around don't push this too much. For instancce, it seems that it's a bit tricky to import a HDR texture for use with the UDK. Nevertheless, to author 16 bits textures you'll need software that supports it, such as Photoshop. There are probably others, but it doesn't seem that frequent, e.g. it's it was a long-standing request for GIMP that's still pending. You'll also have to use a 16 bits aware image format, such as PNG.

  • 1
    \$\begingroup\$ I just checked how lights are edited within the UDK. It appears that they use a classic RGB color picker with 8-bit color values, with an added "brightness" factor that can go above 1.0 and scales all three colors at the same time. \$\endgroup\$ Apr 2, 2012 at 9:38

like lorancou said, you dont really author hdr content since it generally dynamic to the amount of light. But, you could probably mimic it in a lightmap which would just involve modifying any precalculation shaders to take that into account.


Well, three years later and I've just written a blog post about authoring HDR content, so now I can answer my own question. :)

To summarize,

  • A good way to handle the wide range of HDR brightness values is by using a logarithmic scale. Photographers have such a scale that they've been using for decades, called exposure value or EV.
  • Using EV in your engine/tools is handy since values measured in real life with a photographer's spot meter can be used as reference data for setting up in-game lighting. Photoshop also uses EV (although it doesn't call it that) in its 32-bit mode.
  • Color pickers for light sources, emissive materials and so on can have the usual LDR RGB components combined with an EV component that scales their overall HDR brightness. This is handy to prevent accidentally changing color when you only wanted to change brightness, or vice versa.
  • It's not necessary to have HDR textures for the usual diffuse and specular maps, but it is useful for emissive textures. BC6 compression is needed here, because BC1 textures show horrible banding and artifacts if they're scaled up to a high brightness (e.g. for neon signs).
  • It's usually not necessary to actually paint emissive textures in floating-point. Photoshop 16-bit mode (which is fixed-point) will probably suffice for emissive textures. However, Photoshop 32-bit mode does provide pretty good floating-point image editing support if it's needed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .