Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)

Enlighten SDK 3.10 Documentation
Results will update as you type.
  • Welcome to Enlighten
  • How Enlighten works
  • Artist workflow
  • Install Enlighten
  • Libraries
  • Implementation guide
  • Technical reference
    • Output formats
    • Albedo handling
    • Lightmap lighting models
    • Light probe evaluation
    • Local IBL reflections
    • Light visibility data
    • Custom direct lights
    • Precompute pipeline
    • Low level precompute API
    • Debugging the precompute
    • The low level runtime
      • Low level runtime walkthrough
        • Preparing the runtime
        • Per-frame walkthrough
          • Providing input lighting
          • Solving for irradiance
          • Solving for directional irradiance
          • Solving for probe points
          • Probe interpolation
          • Resampling bounce
        • Multiple systems at runtime
        • Low level cubemap API
      • Input lighting
      • Debug the low level runtime
    • Baked lighting
    • Performance tuning
    • Technical troubleshooting
    • Terrain LOD
    • Probe LOD
    • Lightmap LOD
  • Advanced techniques
  • Tools
  • Enlighten Mobile
  • White papers
  • Third-party licences
  • Release notes
    Calendars

You‘re viewing this with anonymous access, so some content might be blocked.
/
Solving for directional irradiance

    This is the documentation for Enlighten.

    Solving for directional irradiance

    Nov 21, 2019

    There are two options for solving directional irradiance instead of just irradiance alone. For a single directional output texture containing the luminance-based dominant direction of the indirect lighting, add the following to the code sample in the Solving for irradiance section:

    irradianceTask.m_DirectionalOutput       = directionalOutput;
    
    irradianceTask.m_DirectionalOutputStride = radCore->m_MetaData.m_OutputWidth;
    // lazily assuming stride = width, not always true.
    

    Alternatively, to solve directional irradiance separately for the red, green and blue components of the indirect lighting, add the following to the code sample in the Solving for irradiance section (note how m_DirectionalOutput is re-used for red directional output data):

    irradianceTask.m_DirectionalOutput       = directionalOutputR;
    irradianceTask.m_DirectionalOutputG      = directionalOutputG;
    irradianceTask.m_DirectionalOutputB      = directionalOutputB;
    
    irradianceTask.m_DirectionalOutputStride = radCore->m_MetaData.m_OutputWidth;
    // lazily assuming stride = width, not always true.
    

    In both cases, make the same function call (SolveIrradianceTask) as for irradiance alone. The texture format of the directional output data is always 8 bits per channel per pixel. The dominant direction { x, y, z } is stored in the { r, g, b } channels respectively, and the rescaling factor is stored in the alpha channel. The byte order of the output can be controlled with the m_OutputFormatByteOrder parameter of the task.

    The length of the directional vector corresponds to how "directional" the incoming light is. If the light is concentrated entirely from a single direction, then the length of the directional vector equals 1. If the length is less than 1, light is coming from multiple directions. Note that if the light is distributed uniformly across the hemisphere, the length of the directional vector is 0.5 and that in some lighting distributions the length can indeed be 0.

    , multiple selections available,
    {"serverDuration": 9, "requestCorrelationId": "0f42ceb3085446f6b24b9cfbb88f4d0d"}