Official [2021.2] New Features in Lighting

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.

 

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

 

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

 

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).

 

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

Code (csharp):

1.  
2. [00:26:49] Precompute started.
3. -- Listing OpenCL platforms(s) --
4.  * OpenCL platform 0
5.     PROFILE = FULL_PROFILE
6.     VERSION = OpenCL 2.1 AMD-APP (3302.6)
7.     NAME = AMD Accelerated Parallel Processing
8.     VENDOR = Advanced Micro Devices, Inc.
9. -- Listing OpenCL device(s) --
10.  * OpenCL platform 0, device 0
11.     DEVICE_TYPE = 4
12.     DEVICE_NAME = gfx1030
13.     DEVICE_VENDOR = Advanced Micro Devices, Inc.
14.     DEVICE_VERSION = OpenCL 2.0 AMD-APP (3302.6)
15.     DRIVER_VERSION = 3302.6 (PAL,LC)
16.     DEVICE_MAX_COMPUTE_UNITS = 36
17.     DEVICE_MAX_CLOCK_FREQUENCY = 2090
18.     CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE = 14360458035
19.     CL_DEVICE_HOST_UNIFIED_MEMORY = false
20.     CL_DEVICE_MAX_MEM_ALLOC_SIZE = 14360458035
21.     DEVICE_GLOBAL_MEM_SIZE = 17163091968
22.     CL_DEVICE_BOARD_NAME_AMD = AMD Radeon RX 6800 XT
23. -- GPU Progressive lightmapper will use OpenCL device 'gfx1030' from 'Advanced Micro Devices, Inc.'--
24.    use -OpenCL-PlatformAndDeviceIndices <platformIdx> <deviceIdx> as command line arguments if you want to select a specific adapter for OpenCL.
25. -- OpenCL device board name 'AMD Radeon RX 6800 XT' (AMD only extension).
26. [00:26:50] Finished 1 Layout Systems job (0.35s execute, 0.00s integrate, 0.97s wallclock)
27. [00:26:50] Finished 1 Tetrahedralize Probes job (0.00s execute, 0.00s integrate, 0.06s wallclock)
28. [00:26:50] Precompute took 1.027036 seconds.
29. Enlighten scene contents:   0 geometries.   0 instances.   0 systems.   0 probe groups.   0 cube maps. Scene is up-to-date.
30. [00:26:50] Bake started.
31. [00:26:51] Finished 1 Create Input Lighting job (0.18s execute, 0.00s integrate, 0.19s wallclock)
32. [00:26:51] Finished 1 Bake Runtime job (0.18s execute, 0.00s integrate, 0.19s wallclock)
33. [Optix] removing context.
34. [00:26:51] Bake took 0.382577 seconds.
35. [PathTracer] Loaded OpenCL shaders in 10.437 secs -> Timestamps: [3599.505 - 3609.942].
36. Request Asset Garbage Collect because used heap size increased from 377.1 MB to 0.62 GB, exceeding the threshold of 256.0 MB.
37. Unloading 2 Unused Serialized files (Serialized files now loaded: 0)
38. Unloading 105 unused Assets / (5.1 KB). Loaded Objects now: 10278.
39. Memory consumption went from 0.62 GB to 0.62 GB.
40. Total: 25.110000 ms (FindLiveObjects: 0.996200 ms CreateObjectMapping: 0.633200 ms MarkObjects: 23.369500 ms  DeleteObjects: 0.110300 ms)
41.  
42. Not enough GPU memory to fit an entire lightmap, trying tiled baking mode: 1. Available GPU memory: 15.60 GB
43. Not enough GPU memory to fit an entire lightmap, trying tiled baking mode: 2. Available GPU memory: 15.57 GB
44. Not enough GPU memory to fit an entire lightmap, trying tiled baking mode: 3. Available GPU memory: 15.57 GB
45. Not enough GPU memory to fit an entire lightmap, trying tiled baking mode: 4. Available GPU memory: 15.57 GB
46. 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
47.  
48. *********************************************
49. * Lightmapper - GPUMemoryStatistics - START *
50. *********************************************
51.  
52. -------------------
53. Overview:
54.  
55. Category     Overview     34.369     MB    
56. RadeonRaysMeshManager     2.010     MB    
57. OpenCLEnvironmentBuffers     2.096     MB    
58. OpenCLCommonBuffers     30.262     MB    
59.  
60. -------------------
61. Details:
62.  
63. Category     RadeonRaysMeshManager     2.010     MB    
64. instanceIdToAlbedoTextureProperties     0.004     MB    
65. instanceIdToEmissiveTextureProperties     0.004     MB    
66. instanceIdToTransmissionTextureProperties     0.004     MB    
67. instanceIdToTransmissionTextureSTs     0.004     MB    
68. geometryUV0sBuffer     0.366     MB    
69. geometryUV1sBuffer     0.366     MB    
70. geometryPositionsBuffer     0.550     MB    
71. geometryNormalsBuffer     0.183     MB    
72. geometryIndicesBuffer     0.508     MB    
73. instanceIdToMeshDataOffsets     0.002     MB    
74. instanceIdToInvTransposedMatrices     0.017     MB    
75.  
76. Category     OpenCLEnvironmentBuffers     2.096     MB    
77. env_mipped_cube_texels_buffer     2.096     MB    
78.  
79. Category     OpenCLCommonBuffers     30.262     MB    
80. goldenSample_buffer     12.000     MB    
81. blueNoiseSampling_buffer     0.063     MB    
82. blueNoiseRanking_buffer     1.125     MB    
83. blueNoiseScrambling_buffer     1.125     MB    
84. sobol_buffer     0.203     MB    
85. albedoTextures_buffer     14.494     MB    
86. emissiveTextures_buffer     0.001     MB    
87. transmissionTextures_buffer     1.250     MB    
88.  
89. *********************************************
90. * Lightmapper - GPUMemoryStatistics - STOP *
91. *********************************************
92.  
93. LightingSettings: switching bake backend from 2 to 1.
94. Not enough GPU memory to fit an entire lightmap, trying tiled baking mode: 1. Available GPU memory: 15.57 GB
95. gi::BakeBackendSwitch: Clear() active clients.
96. [EnlightenBakeManager] m_Clear = false;
97. [PathTracer] Total bake time: 0.064716, raw bake time: 0.000000
98. gi::BakeBackendSwitch: switching bake backend from 2 to 1.
99. [00:27:04] Bake started.
100. [00:27:04] Finished 1 Create Input Lighting job (0.18s execute, 0.00s integrate, 0.19s wallclock)
101. [00:27:04] Finished 1 Bake Runtime job (0.17s execute, 0.00s integrate, 0.19s wallclock)
102. [00:27:04] Bake took 0.383528 seconds.
103. [PathTracer] Loaded OpenRL shaders in 1.000 secs -> Timestamps: [3613.737 - 3614.737].
104. Request Asset Garbage Collect because used heap size increased from 0.52 GB to 1.69 GB, exceeding the threshold of 256.0 MB.
105. Unloading 2 Unused Serialized files (Serialized files now loaded: 0)
106. Unloading 2 unused Assets / (96 B). Loaded Objects now: 10280.
107. Memory consumption went from 1.69 GB to 1.69 GB.
108. Total: 35.038700 ms (FindLiveObjects: 1.201700 ms CreateObjectMapping: 0.528500 ms MarkObjects: 33.226500 ms  DeleteObjects: 0.080000 ms)
109.  
110. Request Asset Garbage Collect because used heap size increased from 1.69 GB to 2.69 GB, exceeding the threshold of 432.0 MB.
111. Unloading 2 Unused Serialized files (Serialized files now loaded: 0)
112. Unloading 2 unused Assets / (96 B). Loaded Objects now: 10280.
113. Memory consumption went from 2.69 GB to 2.69 GB.
114. Total: 28.750100 ms (FindLiveObjects: 1.387800 ms CreateObjectMapping: 0.866800 ms MarkObjects: 26.387100 ms  DeleteObjects: 0.106200 ms)
115.  
116. Request Asset Garbage Collect because used heap size increased from 2.69 GB to 3.69 GB, exceeding the threshold of 0.67 GB.
117. Unloading 2 Unused Serialized files (Serialized files now loaded: 0)
118. Unloading 2 unused Assets / (4.6 KB). Loaded Objects now: 10282.
119. Memory consumption went from 3.69 GB to 3.69 GB.
120. Total: 35.463700 ms (FindLiveObjects: 1.484400 ms CreateObjectMapping: 1.022400 ms MarkObjects: 32.863200 ms  DeleteObjects: 0.091400 ms)
121.  
122. ProgressiveSceneManager::Cancel()

 

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

 

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

2021.1.11f1:


2021.2.2f1:

 

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

 

Built-in, no post.

 

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

 

These are all new bakes.

 

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).

 

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.

 

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

 

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

 

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.

 

Screen space GI could be fairly easily added to the builtin deferred render pipeline as-is.

 

Yeah, it's just that Unity won't do it. There's Sunfall Global Illumination on the Asset Store, however.

 

There's a lot of SSGI for built in in Github too

 

Built-in is deprecated anyway. Best Unity doesn't spend any time developing additional features for it.

 

Thank you for the update. I am interested in real time GI. I guess I can only use Enlighten for that and can't use progressive, right?

There was this blog post before
https://blog.unity.com/technology/e...obust-solution-for-baked-and-real-time-giobal

So those plans have changed, right?
I just want to make sure that I should be using Enlighten for real-time GI.

 

OK, I think I understand now.
If I do settings like below it means enlighten would be used automatically and realtime GI would be enabled.



If I changed into this, it means realtime gi would still be enabled with enlighten used for precomputation but the progressive would be used for the light mapping, right?


Finally I shouldn't be doing this for new projects (use enlighten for lightmapping)

 

This is the thread you want to read: https://forum.unity.com/threads/update-on-global-illumination-2021.1067015/

Which can be summed up with this image:


The TLDR is:

Enlighten was brought back. Plans for in-house realtime GI didn't work out. I'm not sure what the plans are now, maybe APV is supposed to evolve into a realtime GI solution at some point, or maybe not.

Precomputed realtime GI with Enlighten will be available until 2024LTS. If you plan long term game dev cycle, or supporting your game for a long time, or plan on releasing on mobile, I wouldn't make a game with Enlighten.

Also please note that Enlighten is back, but it's not really fully supported. They won't update the Enlighten backend to something newer or make any improvements to it. It's the same version we've had for years, just brought back from the dead to hastily patch the lack of a "proper" realtime GI solution.

If the paragraphs above didn't dissuade you from using it, then go ahead.

 

Thank you for the detailed answer, I really appreciate it. So I can assume now that, enlighten is the only unity solution for realtime GI, but it's not fully supported, but would be usable until 2024LTS. And I should wait for alternative if I don't want to use enlighten, right?

 

Yeah, seems about right.