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
    • The Enlighten scene
    • The precompute process
    • The lightmap UV pipeline
    • Enlighten runtime data
    • Runtime radiosity updates
      • High level runtime
      • Rendering indirect lighting
      • Per pixel probe lighting
      • Per mesh probe lighting
      • Material colour changes
    • Sample implementation
  • Technical reference
  • 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.
/
Material colour changes

    This is the documentation for Enlighten.

    Material colour changes

    Nov 21, 2019

    In some scenarios, the colours of surfaces might change at runtime in ways that should affect the radiosity computation.

    • A surface that becomes obscured by paint, snow or dust.
    • An emissive surface light source that turns off or changes colour.
    • A mesh which is destroyed during gameplay.

    When you need to update material colour data at runtime, to get started quickly, provide uniform or per-sample colours in the same way as for static albedo and static emissive.

    It's straightforward to compute static material colours quickly enough when running on an artist workstation, but more difficult to optimize for your target platform. To avoid the cost of optimization, we recommend to use a different solution for runtime updates tailored to the type of updates you require.

    If a uniform colour for the entire surface provides a good enough approximation, mark surfaces that will change as dynamic. This is known as dynamic albedo or dynamic emissive.

    When only a few surfaces will change at runtime, provide static material colours for the surfaces that do not change.

    Prepare runtime data

    First, modify the additional runtime data you used for static material colours to enable updates.

    Do this at the same time you provide the static material colours. 

    Call MakeSingleSurfaceSelection to create a SurfaceSelection which identifies the surface to modify.

    Call InitialiseMaterialAlbedoAsDynamic with the SurfaceSelection to mark the surface as dynamic.

    To commit the changes to the AlbedoBuffer:

    • if you use per-sample static material colours, call InitialiseAlbedoBufferFromColoursPerPoint.
    • otherwise, call InitialiseAlbedoBufferFromMaterialWorkspace.

    These steps modify the DynamicMaterialWorkspace object. To ensure these changes take effect, save both the DynamicMaterialWorkspace and the AlbedoBuffer objects afterwards.

    Follow the same steps with the Emissive family of functions to enable emissive updates.

    Update colours

    At runtime, use the persistent runtime data to set the colour of surfaces that are marked dynamic.

    Call SetMaterialAlbedoColour as many times as you need to set the colour for each surface.

    Call UpdateAlbedoBuffer to apply changes to the AlbedoBuffer.

    Follow the same steps with the Emissive family of functions to set emissive colours.

    In the high level runtime, enqueue a command to call BaseSystem::SetAlbedoData for the system with the updated AlbedoBuffer.

    To reduce the amount of work to do at runtime, when you prepare the runtime data, store the composite material IDs for the surfaces that will change colour.

    , multiple selections available,
    {"serverDuration": 11, "requestCorrelationId": "52bcc3485e2142b9b12f98495349870a"}