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
    • Baked lighting
      • Baking with the High Level Build System
        • Baking parameters
        • Bake lighting configuration
        • Bake instance types
        • Per-mesh lightmaps
        • Vertex baking
        • Level of detail and baking
        • Directionality and baking
        • Transparency and baking
        • Baking file types
        • Baking light masks
        • Final Gather
      • Baking with the low level bake API
    • 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.
/
Transparency and baking

    This is the documentation for Enlighten.

    Transparency and baking

    Nov 21, 2019

    Introduction

    Transparency is supported when baking direct light. The transparency value is a colour vector between 0-1. A mesh can be uniformly transparent, or a texture can be applied where the transparency is proportional to the intensity of the texels. In other words, black texels block all light, white texels allow all light through, red allows red, and so on. GeoRadiosity does not render material with this transparency, but it does attempt to show the regions affected:

    Sample transparency texture

    Baked result

    Transparency does not affect ambient occlusion or indirect lighting output. This means that environment lighting and indirect lighting do not travel through transparent portions of a scene. However, direct lighting travelling through the transparency will result in subsequent indirect lighting within the scene.

    In order to author transparency, a material description must be supplied with the geometry when constructing the Enlighten::IBakeInputSystem.

    Assigning material descriptions

    In order to supply the material descriptions to the baking API an Enlighten::IBakeInputMaterial instance must be created. This object holds all materials (consisting of Enlighten::BakeMaterialInfo instances) for the baking system in question. This is in turn passed to Enlighten::IBakeInputSystem::AddGeometry when adding the geometry to the baking system. The API picks out the appropriate materials from this object.

    Handling textures

    The Enlighten::BakeMaterialInfo instance contains the filenames of texture files used for transparency. In order for the API to load the material data, you must supply an implementation of Enlighten::IBakeTextureManager that is responsible for loading and supplying textures to the API while baking. It is crucial that Enlighten::IBakeTextureManager::GetTexture caches textures so that textures are not reloaded every time they are requested (this can literally happen millions of times during a bake). The sample framework contains such an implementation, GeoRadSample::BakeTextureManager.

    Output textures

    The alpha channel in the irradiance light maps stores information about the validity of the pixel. If it is set to 1., the pixel is valid and contains computed irradiance values. If it is set to 0.5, the pixel value can be used for rendering, but it was generated from nearby pixels using a dilation algorithm. This dilation is done for invalid pixels, e.g. because they see too many back faces, or for edge pixels, to avoid interpolation artefacts. Dilated pixels never overwrite valid pixels. An alpha value of 0. signifies invalid pixels, their other values will be black.

    Note that the directional output light maps use the alpha channel for the renormalisation coefficient. Use the alpha value of the corresponding irradiance light map for validity checks.

    Shadowface Behaviour

    Normally, both front and back faces of a mesh cast shadows. If you want only the front or back faces to cast faces, set the shadowFaces type to front or back respectively. Use the bothWithInvalidBack option to have both front and back faces cast shadows, but with back faces being considered "invalid". If the ratio of valid to invalid hits falls below the threshold set with backfaceTolerance then the pixel is marked as invalid. Invalid pixels will be extrapolated from surrounding, valid pixels. Shadowface behaviour can also be set with material properties of each instance or mesh in the scene.

    , multiple selections available,
    {"serverDuration": 10, "requestCorrelationId": "cba6737d107b446aa28e7bbcfad8b3c9"}