[2021.2] New Features in Lighting

kristijonas_unity · November 1, 2021, 3:39pm

Make sure to check out the What’s new for artists and designers in Unity 2021.2 blog post for a complete list of features.

Enlighten Realtime Global Illumination

This feature was implemented by: @KEngelstoft

This feature enables Unity creators to enrich their projects with indirect lighting that responds to real time changes in light and material properties. Interactive visual feedback makes it possible to significantly reduce lighting design iteration times.

In the 2021.2 release we have re-enabled support for Enlighten Realtime Global Illumination in HDRP and the Built-In Render Pipeline, and added support to URP. We’ve also extended support for Enlighten Realtime Global Illumination to the Apple silicon, PS5, and XSX platforms.

Progressive GPU Lightmapper Tiling

This feature was implemented by: @ADufay

This new feature makes it possible for users to utilize the Progressive GPU Lightmapper for faster bakes at larger lightmap resolutions.

The tiling technique helps reduce GPU memory requirements by breaking down lightmaps into tiles sized to match the amount of GPU memory available. This feature reduces the risk of the GPU lightmapper running out of memory and falling back to the CPU. It activates automatically, requiring no input from the user.

Note that tiled denoising has not been implemented yet. Certain denoising configurations can still cause out of memory issues. We are working on it.

Lightmap Compression in the Lighting Settings Asset

This feature was developed by: @rasmusn and @Pema-Malling

This improvement introduces a Lightmap Compression property in the LSA. This replaces the previous Compress Lightmaps checkbox. As a result, lightmap compression quality is no longer tied to Lightmap Encoding project setting. Instead, generated lightmap textures derive their compression quality from this drop-down.

You can access Lightmap Compression drop-down in the Lighting window. There are four options available:

None
Low Quality
Normal Quality
High Quality

Each setting will result in an appropriate texture compression quality setting. You can verify this in the texture importer settings.

High Quality setting is chosen by default for new and upgraded projects.

Feature access & feedback
You can get access to the feature by downloading the latest 2021.2 build via the Unity Hub, or via this link. We are looking forward to hearing your feedback!

AcidArrow · November 1, 2021, 5:14pm

1st of all, I appreciate the updates.

But:

I mean I believe you that you’ve implemented this, and I feel like bakes have become faster, but… I don’t think I’ve seen the memory requirements drop.

~2+ years ago, (on 2018LTS and/or latest 2019 version at the time) I could barely bake 2k maps on a 2070 with 8GB, but as soon as I bumped the anti-aliasing samples higher than default, it would fall back to cpu.

Now, 2+ years later, on 2021.2.0f1, I can barely bake 2k maps on a 6800XT with 16GB, but as soon as I bump the anti-aliasing samples higher than default, it falls back to cpu.

So… is this feature working? Am I doing something wrong? If I understand correctly it should be able to split the lightmap in small enough tiles to fit the gpu ram, and yet it still falls back a lot? And 16GB is above average and my scenes are not big.

Ruchir · November 2, 2021, 6:37am

This feature would indeed be useful for systems like mine (3060 6GB, laptop GPU)

Currently I had to use bakery which is really inconvenient to use in HDRP compared to built-in light mapper. So, really excited to test this out.
Although some features in bakery were just really usefull, like baking maps partially, baking prefabs l, etc. It would be really helpful to see these implemented inside unity at some point

kristijonas_unity · November 2, 2021, 8:13am

AcidArrow:

1st of all, I appreciate the updates.

But:

I mean I believe you that you’ve implemented this, and I feel like bakes have become faster, but… I don’t think I’ve seen the memory requirements drop.

~2+ years ago, (on 2018LTS and/or latest 2019 version at the time) I could barely bake 2k maps on a 2070 with 8GB, but as soon as I bumped the anti-aliasing samples higher than default, it would fall back to cpu.

Now, 2+ years later, on 2021.2.0f1, I can barely bake 2k maps on a 6800XT with 16GB, but as soon as I bump the anti-aliasing samples higher than default, it falls back to cpu.

So… is this feature working? Am I doing something wrong? If I understand correctly it should be able to split the lightmap in small enough tiles to fit the gpu ram, and yet it still falls back a lot? And 16GB is above average and my scenes are not big.

Your understanding of the feature is correct. Technically, you should have been able to bake 4K lightmaps with 16GBs of VRAM even prior to the introduction of lightmap tiling. I suspect that AA is to blame here. I will reach out to someone with deep technical knowledge of this area, and ask them to get back to you.

Selective baking, and baked prefabs are in our backlog. Both of those features will be implemented at some point in the future. We can’t provide an ETA yet, unfortunately.

Reanimate_L · November 2, 2021, 11:00am

For the GPU lightmapper tilling this is always enabled isn’t? and we don’t have to do any changes on the settings?

kristijonas_unity · November 2, 2021, 11:29am

That is correct, nothing needs to be done on the user side. It all works automatically. I will update the post with this information.

AcidArrow:

1st of all, I appreciate the updates.

But:

I mean I believe you that you’ve implemented this, and I feel like bakes have become faster, but… I don’t think I’ve seen the memory requirements drop.

~2+ years ago, (on 2018LTS and/or latest 2019 version at the time) I could barely bake 2k maps on a 2070 with 8GB, but as soon as I bumped the anti-aliasing samples higher than default, it would fall back to cpu.

Now, 2+ years later, on 2021.2.0f1, I can barely bake 2k maps on a 6800XT with 16GB, but as soon as I bump the anti-aliasing samples higher than default, it falls back to cpu.

So… is this feature working? Am I doing something wrong? If I understand correctly it should be able to split the lightmap in small enough tiles to fit the gpu ram, and yet it still falls back a lot? And 16GB is above average and my scenes are not big.

@AcidArrow , while we are at it, could you attach an editor.log from one of your recent failed due to OOM bakes? Chances are it’s either AA, denoising, or both which are preventing you from baking larger lightmaps. Keep in mind that tiled denoising has not been implemented yet.

AcidArrow · November 2, 2021, 11:36am

I’m not using denoising, or any kind of filtering, so it’s probably AA. I’m away from a computer now but I’ll attach logs next chance I get (which might not be today).

AcidArrow · November 4, 2021, 5:55pm

I believe this is the relevant part of an editor log, but let me know if you need to attach a full one anyway.

[00:26:49] Precompute started.
-- Listing OpenCL platforms(s) --
 * OpenCL platform 0
    PROFILE = FULL_PROFILE
    VERSION = OpenCL 2.1 AMD-APP (3302.6)
    NAME = AMD Accelerated Parallel Processing
    VENDOR = Advanced Micro Devices, Inc.
-- Listing OpenCL device(s) --
 * OpenCL platform 0, device 0 
    DEVICE_TYPE = 4
    DEVICE_NAME = gfx1030
    DEVICE_VENDOR = Advanced Micro Devices, Inc.
    DEVICE_VERSION = OpenCL 2.0 AMD-APP (3302.6)
    DRIVER_VERSION = 3302.6 (PAL,LC)
    DEVICE_MAX_COMPUTE_UNITS = 36
    DEVICE_MAX_CLOCK_FREQUENCY = 2090
    CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE = 14360458035
    CL_DEVICE_HOST_UNIFIED_MEMORY = false
    CL_DEVICE_MAX_MEM_ALLOC_SIZE = 14360458035
    DEVICE_GLOBAL_MEM_SIZE = 17163091968
    CL_DEVICE_BOARD_NAME_AMD = AMD Radeon RX 6800 XT
-- GPU Progressive lightmapper will use OpenCL device 'gfx1030' from 'Advanced Micro Devices, Inc.'--
   use -OpenCL-PlatformAndDeviceIndices <platformIdx> <deviceIdx> as command line arguments if you want to select a specific adapter for OpenCL.
-- OpenCL device board name 'AMD Radeon RX 6800 XT' (AMD only extension).
[00:26:50] Finished 1 Layout Systems job (0.35s execute, 0.00s integrate, 0.97s wallclock)
[00:26:50] Finished 1 Tetrahedralize Probes job (0.00s execute, 0.00s integrate, 0.06s wallclock)
[00:26:50] Precompute took 1.027036 seconds.
Enlighten scene contents:   0 geometries.   0 instances.   0 systems.   0 probe groups.   0 cube maps. Scene is up-to-date.
[00:26:50] Bake started.
[00:26:51] Finished 1 Create Input Lighting job (0.18s execute, 0.00s integrate, 0.19s wallclock)
[00:26:51] Finished 1 Bake Runtime job (0.18s execute, 0.00s integrate, 0.19s wallclock)
[Optix] removing context.
[00:26:51] Bake took 0.382577 seconds.
[PathTracer] Loaded OpenCL shaders in 10.437 secs -> Timestamps: [3599.505 - 3609.942].
Request Asset Garbage Collect because used heap size increased from 377.1 MB to 0.62 GB, exceeding the threshold of 256.0 MB.
Unloading 2 Unused Serialized files (Serialized files now loaded: 0)
Unloading 105 unused Assets / (5.1 KB). Loaded Objects now: 10278.
Memory consumption went from 0.62 GB to 0.62 GB.
Total: 25.110000 ms (FindLiveObjects: 0.996200 ms CreateObjectMapping: 0.633200 ms MarkObjects: 23.369500 ms  DeleteObjects: 0.110300 ms)

Not enough GPU memory to fit an entire lightmap, trying tiled baking mode: 1. Available GPU memory: 15.60 GB
Not enough GPU memory to fit an entire lightmap, trying tiled baking mode: 2. Available GPU memory: 15.57 GB
Not enough GPU memory to fit an entire lightmap, trying tiled baking mode: 3. Available GPU memory: 15.57 GB
Not enough GPU memory to fit an entire lightmap, trying tiled baking mode: 4. Available GPU memory: 15.57 GB
OpenCL Error. Falling back to CPU lightmapper. Error callback from context: Not enough GPU memory to fit lightmap in memory, even in tiled baking mode. Available GPU memory: 15.57 GB

*********************************************
* Lightmapper - GPUMemoryStatistics - START *
*********************************************

-------------------
Overview:

Category     Overview     34.369     MB    
RadeonRaysMeshManager     2.010     MB    
OpenCLEnvironmentBuffers     2.096     MB    
OpenCLCommonBuffers     30.262     MB    

-------------------
Details:

Category     RadeonRaysMeshManager     2.010     MB    
instanceIdToAlbedoTextureProperties     0.004     MB    
instanceIdToEmissiveTextureProperties     0.004     MB    
instanceIdToTransmissionTextureProperties     0.004     MB    
instanceIdToTransmissionTextureSTs     0.004     MB    
geometryUV0sBuffer     0.366     MB    
geometryUV1sBuffer     0.366     MB    
geometryPositionsBuffer     0.550     MB    
geometryNormalsBuffer     0.183     MB    
geometryIndicesBuffer     0.508     MB    
instanceIdToMeshDataOffsets     0.002     MB    
instanceIdToInvTransposedMatrices     0.017     MB    

Category     OpenCLEnvironmentBuffers     2.096     MB    
env_mipped_cube_texels_buffer     2.096     MB    

Category     OpenCLCommonBuffers     30.262     MB    
goldenSample_buffer     12.000     MB    
blueNoiseSampling_buffer     0.063     MB    
blueNoiseRanking_buffer     1.125     MB    
blueNoiseScrambling_buffer     1.125     MB    
sobol_buffer     0.203     MB    
albedoTextures_buffer     14.494     MB    
emissiveTextures_buffer     0.001     MB    
transmissionTextures_buffer     1.250     MB    

*********************************************
* Lightmapper - GPUMemoryStatistics - STOP *
*********************************************

LightingSettings: switching bake backend from 2 to 1.
Not enough GPU memory to fit an entire lightmap, trying tiled baking mode: 1. Available GPU memory: 15.57 GB
gi::BakeBackendSwitch: Clear() active clients.
[EnlightenBakeManager] m_Clear = false;
[PathTracer] Total bake time: 0.064716, raw bake time: 0.000000
gi::BakeBackendSwitch: switching bake backend from 2 to 1.
[00:27:04] Bake started.
[00:27:04] Finished 1 Create Input Lighting job (0.18s execute, 0.00s integrate, 0.19s wallclock)
[00:27:04] Finished 1 Bake Runtime job (0.17s execute, 0.00s integrate, 0.19s wallclock)
[00:27:04] Bake took 0.383528 seconds.
[PathTracer] Loaded OpenRL shaders in 1.000 secs -> Timestamps: [3613.737 - 3614.737].
Request Asset Garbage Collect because used heap size increased from 0.52 GB to 1.69 GB, exceeding the threshold of 256.0 MB.
Unloading 2 Unused Serialized files (Serialized files now loaded: 0)
Unloading 2 unused Assets / (96 B). Loaded Objects now: 10280.
Memory consumption went from 1.69 GB to 1.69 GB.
Total: 35.038700 ms (FindLiveObjects: 1.201700 ms CreateObjectMapping: 0.528500 ms MarkObjects: 33.226500 ms  DeleteObjects: 0.080000 ms)

Request Asset Garbage Collect because used heap size increased from 1.69 GB to 2.69 GB, exceeding the threshold of 432.0 MB.
Unloading 2 Unused Serialized files (Serialized files now loaded: 0)
Unloading 2 unused Assets / (96 B). Loaded Objects now: 10280.
Memory consumption went from 2.69 GB to 2.69 GB.
Total: 28.750100 ms (FindLiveObjects: 1.387800 ms CreateObjectMapping: 0.866800 ms MarkObjects: 26.387100 ms  DeleteObjects: 0.106200 ms)

Request Asset Garbage Collect because used heap size increased from 2.69 GB to 3.69 GB, exceeding the threshold of 0.67 GB.
Unloading 2 Unused Serialized files (Serialized files now loaded: 0)
Unloading 2 unused Assets / (4.6 KB). Loaded Objects now: 10282.
Memory consumption went from 3.69 GB to 3.69 GB.
Total: 35.463700 ms (FindLiveObjects: 1.484400 ms CreateObjectMapping: 1.022400 ms MarkObjects: 32.863200 ms  DeleteObjects: 0.091400 ms)

ProgressiveSceneManager::Cancel()

Lymdun · November 28, 2021, 10:40pm

Do you plan to upgrade Enlighten to the latest version? What is the current one being used? https://www.siliconstudio.co.jp/en/news/pressreleases/2021/en2109enlighten/en2109enlighten.html

kristijonas_unity · November 29, 2021, 1:21pm

We are currently using 3.09p1. We do not have plans to upgrade it at the moment.

Thomas-Mountainborn · December 6, 2021, 10:15am

Why is the lighting so utterly different between 2021.1 and 2021.2? Same lighting and scene settings.

2021.1.11f1:

2021.2.2f1:

Ruchir · December 6, 2021, 12:28pm

This does look like different exposure values to me, are you using HDRP?

Thomas-Mountainborn · December 6, 2021, 6:01pm

Built-in, no post.

runner78 · December 7, 2021, 7:38am

If you have backed lights you should try to bake again.

Thomas-Mountainborn · December 7, 2021, 8:29am

These are all new bakes.

Zergling103 · February 4, 2022, 1:36pm

I can’t help but wonder about the apparent… wavering or hesitant support for Enlighten. It has been marked altogether as deprecated in 2020.1.0f1, has no support for SRP on some newer versions of Unity, and has missing features present in other games that use Enlighten (e.g. spot and point light indirect support), but is now being adopted again.

Is the code base difficult to work with for the Unity graphics guys? Some kind of legal or lisencing issue?

I watched one of Unity’s presentations about GI and there was motivation to move away from surface-based GI and towards probe-based GI. With Englighten, lighting data is recorded onto surface textures, and is propigated based on baked inter-surface visibility calculations I believe. The probe-based GI solution Unity was developing used light probes created at runtime, using hardware raytracing to calculate how light propigates between them, then when rendering geometry will sample from these probes (via proxy volumes) as they accumulate lighting data.

While the raytracing angle is interesting, it seems like the baking aspect is still useful. Enlighten bakes the visibility calculations between surfaces (which is, as I understand it, the most expensive issue with GI), so it’d still be in my estimation very valuable to somehow bake this data into probes as a way to avoid needing raytracing queries. (This data could be omitted or supplimented by raytracing for machines that support it and for users who are okay with the performance hit).

Getting to the point, I understand if the hesitation around Enlighten support is based on the desire to move away from surface-based GI baking (though baking is still a good performance saving alternative to raytraces imo).

Wolfos · February 9, 2022, 1:15pm

Enlighten is available in SRP now, but it’s still the same antique version and IMO not really usable in real games. Using light probes for accelerating ray traced lighting is exactly how Unreal’s Lumen works, but it’s also not really feasible on today’s hardware - save for the latest Nvidia cards - unless you like barely reaching 30FPS.
Honestly SSGI is your best bet right now. It’s not perfect, but it’s something.

We don’t need yet another solution for baked lighting. It doesn’t really work unless you’re doing either archviz or making a game set in an unchanging set of corridors.
It’s time to focus on a real-time solution. Unity’s been neglecting that for far too long.

cgDoofus · February 23, 2022, 5:10pm

Huh? unreal’s lumen works by a combination of SSGI, marching through SDFs for off screen traces and scene irradiance representation using discs.
I think what you’re referring to is their automatic probe placement feature

imDanOush · March 26, 2022, 8:39pm

It would be great if Unity adds a native robust SSGI to the built-in (non-hdrp) version.

Mauri · March 26, 2022, 9:16pm

This won’t happen. The built-in RP is considered done. No new features will be added to it as the focus is on the SRPs nowadays.

Topic		Replies	Views
Update on Global Illumination 2021 Unity Engine Global-Illumination , Official	34	25260	January 10, 2022
I'd like this GI solution in Unity, thanks a lot :) News & General Discussion Feedback	292	39335	September 26, 2022
So Enlighten really turned out to be a waste of everyone's time. News & General Discussion	124	28042	September 19, 2018
Enlighten deprecation and replacement solution Unity Engine Global-Illumination , Official	431	108492	March 1, 2021
Lighting Survey - seeking your feedback. Unity Engine Global-Illumination	26	4236	November 6, 2016

[2021.2] New Features in Lighting

Related topics