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
          • Allocating working memory
          • Loading precomputed data
          • Providing albedo information
        • 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.
/
Loading precomputed data

    This is the documentation for Enlighten.

    Loading precomputed data

    Nov 21, 2019

    Handling precomputed data

    The data generated by the precompute contains a number of 'opaque' data objects, such as RadSystemCore. These are serialisable blocks of compressed and often immutable data. For convenience, all opaque data objects are relocatable (they do not contain pointers to absolute memory locations). However, some consideration should be taken to ensure correct alignment on all platforms, and correct endian-order when loading data on console hardware.

    All blocks have an internal endian ordering and some alignment restriction (typically 16-bytes). See the Enlighten API Documentation for the specific alignment requirements for an object. Similarly, there are endian-swapping functions in the API to switch the endian ordering after load. Endian handling is ignored for this walkthrough.

    If you are using our memory allocators, you can align memory as demonstrated in this example for creating an input lighting buffer:

    Geo::u32 size = Enlighten::CalcInputLightingBufferSize(inputWorkspace);
    void* memory = GEO_ALIGNED_MALLOC(size, 16);
    InputLightingBuffer* lightingBuffer = Enlighten::CreateInputLightingBuffer(memory, inputWorkspace);
    

    RadSystemCore — core radiosity data

    The simplest way to load the data blocks generated by the Enlighten precompute is to use the corresponding utility functions. Each data block has a core section which is always loaded, and may have optional blocks which may be loaded depending on the sections parameter passed to the loading function. In the case of the RadSystemCore block, for example, to load the optional data block which is required for bounce data to affect this system, pass the appropriate flag:

    Geo::u32 sections = loadBounceData ? Enlighten::Iff::ResamplingDataSection : 0;
    Enlighten::RadSystemCore* radCore = Enlighten::ReadRadSystemCoreFromFile(coreFilename, sections);	// const Geo::c16*
    Enlighten::RadSystemCore* radCore = Enlighten::ReadRadSystemCore(stream, sections);			// Geo::IGeoStream
    

    This returns a pointer which can then be passed to the Enlighten solving functions. However, this method relies on memory allocation performed by the ReadRadSystemCore utility function. The core Enlighten functions never allocate any memory. If you require more control over memory you may replace the allocator used by the SDK (see GeoBase/[GeoMemory.h for more information).

    See the declarations of RadSystemCore and RadDataBlock in Enlighten.h and also the source code in EnlightenUtils.inl for more details.

    RadProbeSetCore — light probe data

    As above, you can use the utility function to load the probe set data into memory. To load the optional probe octree data block (if it exists), pass the appropriate flag in the sections parameter:

    Geo::u32 sections = loadOctreeData ? Enlighten::Iff::ProbeSetOctreeDataSection : 0;
    Enlighten::RadProbeSetCore* probeSetCore = Enlighten::ReadRadProbeSetCoreFromFile(filename, sections);	// const Geo::c16*
    Enlighten::RadProbeSetCore* probeSetCore = Enlighten::ReadRadProbeSetCore(stream, sections);		// Geo::IGeoStream&
    

    InputWorkspace — data required for input lighting

    There are similar function to load InputWorkspace objects.

    Geo::u32 sections = loadDynamicData ? Enlighten::Iff::DynamicInputWorkspaceDataSection : 0;
    Enlighten::InputWorkspace* iw = Enlighten::ReadInputWorkspaceFromFile(iwFilename, sections);	// const Geo::c16*
    Enlighten::InputWorkspace* iw = Enlighten::ReadInputWorkspaces(stream, sections);		// Geo::IGeoStream&
    

    ClusterAlbedoWorkspaceMaterialData — material albedo data

    The Utilities API also has functions to load ClusterAlbedoWorkspaceMaterialData objects. These objects have no optional data blocks, and so don't require a sections parameter.

    Enlighten::ClusterAlbedoWorkspaceMaterialData* cawMaterialData = Enlighten::ReadClusterAlbedoWorkspaceMaterialDataFromFile(cawMaterialDataFilename); 	// const Geo::c16*
    Enlighten::ClusterAlbedoWorkspaceMaterialData* cawMaterialData = Enlighten::ReadClusterAlbedoWorkspaceMaterialData(stream);  				// Geo::IGeoStream&
    

    RadCubeMapCore — data required for dynamic cube map generation

    A RadCubeMapCore contains a single data block which can be loaded as follows:

    Enlighten::RadCubeMapCore* cubeMapCore = Enlighten::ReadRadCubeMapCoreFromFile(cubeMapfilename); 	// const Geo::c16*
    Enlighten::RadCubeMapCore* cubeMapCore = Enlighten::ReadRadCubeMapCore(stream); 			// Geo::IGeoStream&
    

    PrecomputedVisibilityData — precomputed directional light visibility data

    Precomputed InputWorkspace cluster visibility for directional lights can be loaded into PrecomputedVisibilityData objects using the following Enlighten3 utility functions:

    Enlighten::PrecomputedVisbilityData visData = Enlighten::ReadPrecomputedVisibilityDataFromFile(visibilityFilename); 	// const Geo::c16*
    Enlighten::PrecomputedVisbilityData visData = Enlighten::ReadPrecomputedVisibilityData(stream); 			// Geo::IGeoStream&
    

    The ReadXXXFromFile simply calls through to the more generic stream-based Read functions, which take an IGeoStream and therefore can be extended to whatever storage you wish.

    , multiple selections available,
    {"serverDuration": 9, "requestCorrelationId": "8fcd68b89d2445e1be10c507a65d2b81"}