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 4.03 Documentation
Results will update as you type.
  • Welcome to Enlighten
  • How Enlighten works
  • Artist workflow
    • Radiosity properties
    • Indirect lighting resolution
    • Simplified lightmap UVs
    • Automatic probe placement
    • Local reflection probes
    • Emissive surfaces
    • Light sources
    • Mesh changes
    • Indirect lighting issues
  • Install Enlighten
  • Libraries
  • Implementation guide
  • Technical reference
  • Advanced techniques
  • Tools
  • White papers
  • Release notes
  • Third-party licences
    Calendars
You‘re viewing this with anonymous access, so some content might be blocked.
/
Indirect lighting issues

    This is the documentation for Enlighten.

    Indirect lighting issues

    Oct 31, 2024

    This page lists ways to address some indirect lighting issues that might encounter when using Enlighten.

    Visible backfaces

    Enlighten uses backfaces to determine areas that are outside the world and do not need indirect lighting. This prevents unnecessary runtime cost and other problems related to areas outside the world.

    By default, the precompute treats backfaces as invalid. When meshes included in the radiosity computation are not closed, invalid back-faces are visible. In areas that see invalid back-faces, indirect lighting is copied from locations that do not see invalid back faces. The indirect lighting result in these areas will be less accurate and may be obviously incorrect.

    To prevent incorrect indirect lighting for areas inside the world:

    • If the surface is opaque and the back-side is only seen from outside the world, make sure that the back-faces of the surface are not visible to areas inside the world.
    • If the surface is translucent or seen from two sides, use the backfaceBehaviourType material attribute to change the way the back-face is treated.

    So that artists can easily check for areas inside the world that have incorrect indirect lighting, we recommend that your world editor provides:

    • A mode that draws only meshes that are included in the radiosity computation, with invalid back-faces shown in a bright color.
    • A mode that draws automatically placed probes, with probes that see invalid back-faces shown in a bright color.

    Inaccurate lighting

    When the indirect lighting resolution is not sufficient to capture the variation in indirect lighting, the lighting result may be visibly incorrect.

    To address this:

    • If the mesh is lit by a lightmap, increase the lightmap resolution, otherwise increase the probe resolution.
    • Use per pixel probe lighting instead of per mesh probe lighting.

    Probe light leaks

    When two probes are placed either side of a wall that separates areas with very different lighting, probe lighting may appear to leak through the wall.

    When both sides of the wall are in an area that does require Enlighten indirect lighting, in the area where the issue is visible, increase the indirect lighting resolution so that more probes are placed.

    When one side of the wall is in an area outside the world that does not require Enlighten indirect lighting, place invisible geometry with invalid front and back faces to remove the probes placed outside the world. So that this invisible geometry incurs zero runtime cost, use an unlit instance and set the material attribute backfaceBehaviourType to doubleinvalid.

    Unless the sky will be visible far below the horizon, to eliminate sky light leaks that appear to come from below the world, use the environmentValidity radiosity parameter to specify that the lower face of the environment cube should be considered invalid.

    LOD lightmap artifacts

    When two meshes share the same lightmap, artifacts can occur due to mesh projection issues.

    These appear as incorrect lighting and sometimes extremely dark or bright areas. The behaviour may change when a different mesh LOD is visible.

    Lightmap seams

    At the boundary between two lightmap UV charts, seams can be visible in the lighting. Enlighten automatically smooths these seems if the pixels along the edge are aligned with each other.

    If you need smooth lighting at this type of boundary, make sure the lightmap pixels are aligned along the edge where the two adjacent charts meet.

    Lightmap pixel leaks

    In the image below shows a simple scene with lightmapped meshes that are included in the radiosity computation. The scene is lit by a single directional light source.

    On the left, the area in shadow from the light source is dark as we expect. On the right, the bright light from the far side appears to leak through to the shadowed area.

    The floor on the right is composed of a single lightmap UV chart, while the floor on the left is split into two charts. When a lightmap pixel spans both sides of the wall, it takes indirect lighting from both the bright and dark areas, causing the leak.

    , multiple selections available,
    {"serverDuration": 16, "requestCorrelationId": "0abadfd462344534bf2c56c9d0129679"}