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
        • 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.
/
Multiple systems at runtime

    This is the documentation for Enlighten.

    Multiple systems at runtime

    Nov 21, 2019


    Overview

    The example code in the Low level runtime walkthrough assumes a scene with a single system. If there are multiple systems in a scene, the situation is more complicated because light can now transfer between systems.

    Reading from multiple input lighting buffers

    To account for the light transfer between systems, all of the relevant input lighting buffers are passed to each instantiation of a solver function (for example SolveIrradianceTask).

    Internally, each system knows via its precomputed data which other systems to read from, and matches up the inputs using system GUIDs. This is a two stage process:

    1. First, you must call the helper function Enlighten::PrepareInputLightingList to create a correctly ordered list from an unsorted list of input lighting buffers.
    2. This list can then be passed to the solver function via the task structure. Note that the list could also be cached for use over several frames/solves. It does not matter if too many input lighting buffers are passed to Enlighten::PrepareInputLightingList - it silently ignores any it does not need to read from. The function also succeeds if there is a system missing; however, no light is transferred from missing systems, which may produce odd results. SolveIrradianceTask only fails with an error if the input buffer for the system it is trying to compute output for is missing.

    Updating multiple systems

    You must ensure that all of the required input lighting has been generated before starting to run any of the radiosity tasks.

    To put it another way, the pseudo-code for updating multiple systems should look like this:

    • Loop over all the systems
      • Update the input lighting for each system (see Providing input lighting).
    • Loop over all the systems for a second time
      • Run SolveIrradianceTask for each system (see Solving for irradiance).
    • Solve as many probe tasks as required (see Solving for probe points). These can be run in parallel to SolveIrradianceTask.

    The three loops can be individually parallelised, but the first loop must be complete before the others start - the solvers read input lighting from all of the systems.

    Multi-threading

    With a little bit of care, the Enlighten runtime can be parallelised very successfully. The key pitfall to avoid is updating input lighting for a system while it is being read by a Solve function. The simplest strategy for achieving this is to completely separate input lighting updates from solving updates, as in the pseudo-code above.

    GeoRadiosity has a multi-threaded PC runtime. Enlighten uses Intel Threaded Building Blocks to run input lighting for several systems in parallel; afterwards, it runs radiosity solves for several systems in parallel. While all the threads are busy, the performance scales extemely well with the number of processors. Because the systems define the units of work, the best performance is achieved when the systems are all roughly the same size (and there are enough systems to occupy all of the available threads).

    , multiple selections available,
    {"serverDuration": 8, "requestCorrelationId": "6b6a38c52d4e4584a6ba0cf3e85b0606"}