high_dynamic_range.rst 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110
  1. .. _doc_high_dynamic_range:
  2. Light transport in game engines
  3. ===============================
  4. Introduction
  5. ------------
  6. Normally, an artist does all the 3D modelling, then all the texturing,
  7. looks at their awesome looking model in the 3D DCC and says "looks
  8. fantastic, ready for integration!" then goes into the game, lighting is
  9. setup and the game runs.
  10. So at what point does all this "HDR" business come into play? To understand
  11. the answer, we need to look at how displays behave.
  12. Your display outputs linear light ratios from some maximum to some minimum
  13. intensity. Modern game engines perform complex math on linear light values in
  14. their respective scenes. So what's the problem?
  15. The display has a limited range of intensity, depending on the display type.
  16. The game engine renders to an unlimited range of intensity values, however.
  17. While "maximum intensity" means something to an sRGB display, it has no bearing
  18. in the game engine; there is only a potentially infinitely wide range
  19. of intensity values generated per frame of rendering.
  20. This means that some transformation of the scene light intensity, also known
  21. as *scene-referred* light ratios, need to be transformed and mapped to fit
  22. within the particular output range of the chosen display. This can be most
  23. easily understood if we consider virtually photographing our game engine scene
  24. through a virtual camera. Here, our virtual camera would apply a particular
  25. camera rendering transform to the scene data, and the output would be ready
  26. for display on a particular display type.
  27. Computer displays
  28. -----------------
  29. Almost all displays require a nonlinear encoding for the code values sent
  30. to them. The display in turn, using its unique transfer characteristic,
  31. "decodes" the code value into linear light ratios of output, and projects
  32. the ratios out of the uniquely colored lights at each reddish, greenish,
  33. and blueish emission site.
  34. For a majority of computer displays, the specifications of the display are
  35. outlined in accordance with IEC 61966-2-1, also known as the
  36. 1996 sRGB specification. This specification outlines how an sRGB display
  37. is to behave, including the color of the lights in the LED pixels as well as
  38. the transfer characteristics of the input (OETF) and output (EOTF).
  39. Not all displays use the same OETF and EOTF as a computer display.
  40. For example, television broadcast displays use the BT.1886 EOTF.
  41. However, Godot currently only supports sRGB displays.
  42. The sRGB standard is based around the nonlinear relationship between the current
  43. to light output of common desktop computing CRT displays.
  44. .. image:: img/hdr_gamma.png
  45. The mathematics of a scene-referred model require that we multiply the scene by
  46. different values to adjust the intensities and exposure to different
  47. light ranges. The transfer function of the display can't appropriately render
  48. the wider dynamic range of the game engine's scene output using the simple
  49. transfer function of the display. A more complex approach to encoding
  50. is required.
  51. Scene linear & asset pipelines
  52. ------------------------------
  53. Working in scene-linear sRGB is not as simple as just pressing a switch. First,
  54. imported image assets must be converted to linear light ratios on import. Even
  55. when linearized, those assets may not be perfectly well suited for use
  56. as textures, depending on how they were generated.
  57. There are two ways to do this:
  58. sRGB transfer function to display linear ratios on image import
  59. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  60. This is the easiest method of using sRGB assets, but it's not the most ideal.
  61. One issue with this is loss of quality. Using 8 bits per channel to represent
  62. linear light ratios is not sufficient to quantize the values correctly.
  63. These textures may also be compressed later, which can exacerbate the problem.
  64. Hardware sRGB transfer function to display linear conversion
  65. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  66. The GPU will do the conversion after reading the texel using floating point.
  67. This works fine on PC and consoles, but most mobile devices don't support it,
  68. or they don't support it on compressed texture formats (iOS for example).
  69. Scene linear to display referred nonlinear
  70. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  71. After all the rendering is done, the scene linear render requires transforming
  72. to a suitable output such as an sRGB display. To do this, enable sRGB conversion
  73. in the current :ref:`Environment <class_Environment>` (more on that below).
  74. Keep in mind that the **sRGB -> Display Linear** and **Display Linear -> sRGB**
  75. conversions must always be **both** enabled. Failing to enable one of them will
  76. result in horrible visuals suitable only for avant-garde experimental
  77. indie games.
  78. Parameters of HDR
  79. -----------------
  80. HDR settings can be found in the :ref:`Environment <class_Environment>`
  81. resource. Most of the time, these are found inside a
  82. :ref:`WorldEnvironment <class_WorldEnvironment>`
  83. node or set in a Camera node. For more information, see
  84. :ref:`doc_environment_and_post_processing`.