Official Adaptive Probe Volumes (APVs) experimental release for HDRP in 2021.2

You need to go to Window > Rendering (or analysis) > rendering debugger > APV (or probe volume) > click on Show/display Probes
the option in the lightmapper is for the old probe system

 

Hah I just figured that out and wanted to edit my post. I assumed it was moved there from 2021.3 since I've read somewhere that there are plans to move some stuff into the lighting tab

Thanks anyway!

 

EDIT : Solved / Sort Of (follow up beloow)

Hi there, I'm trying to create an addressable / asset bundle of a scene that has probe volumes baked in it but the sizes that its spitting out seem crazy high (even with LZ4 compression on) in comparison to the sizes in the probe volume window and windows explorer before compressing.

For comparison sake :
Probe Volume Settings reports 44,6MB :


Windows explorer shows all the lighting data combined to be 42.5MB (The scene file itself is 7KB)


(Out of curiosity I tried LZ4 compressing these manually (with level 6 compression) and came out around 10MB so the data is compressible at least)

For the sake of testing I deleted every object in my scene but left the baked set alone, so it is an empty scene but just with light probes in it :


and the asset/addressable bundle comes out around 108MB which is ~10x the hoped compressible data size.
Is there something I'm doing wrong or am not aware of? Perhaps its a bug? It does say its stripping debugging information from probe volume during asset bundle creation, but the size still comes out at 110MB.

Many thanks!

 

Sorry for the long post and quick follow up, I found the issue but it has uncovered another oddity :
I used a 192MB HDRI exr to perform the baking in the volume profile that is setup when the baking happens. When exporting the scene I replace the profile in the Enviornment setting of the lighting window to one with no Static Lighting Sky and then do the bundle.
But for some reason when doing an addressable build. The enivonment profile switches back to the one with the large hdri sky. I can probably solve it by creating a dependency addressable with the hdri in so it wont be included multiple times, and I can brute force it by deleting the hdri sky override in the component before building addressables (and it does come out at 10MB in this case) but am now just curious if this was expected behaviour?

 

The option to Display APV Probes is in the Rendering Debugger. The Rendering Debugger now has a dedicated tab for all kinds of APV Debug options

 

I'm taking Probe Volumes for a spin at the moment, and for our interiors they're very promising.

The main outstanding issue at the moment is that our interiors aren't axis-aligned, so the corners of the PV bricks poke outside and apply lighting to other objects, some of which are significantly outside of the defined PV's volume. Is there anything I might have missed which would allow us to keep the PV's influence strictly inside the defined PV volumes?

Edit: Further experimentation, in 2023.1.0b3. I'm now baking the whole landscape with a coarse probe density, and an interior with its own probe volume at a higher density. I had thought that this would solve the issue as the outside areas now have their own probes, but I'm still getting exactly the same issue. As can be seen in the image, the discrepancy lines up with the orange cell borders near the second ProbeVolume with the higher density.


If I disable that ProbeVolume then the lighting in that particular spot works as intended, but I notice a new, different odd patch a bit further up the hill. In this case, the broad ProbeVolume shows neither an orange nor a blue grid cell, even though the terrain definitely intersects those cells.


Edit 2: At first I thought that these were light leaks, but now I'm not so sure? The object is a matte black box inside a larger matte black box, both made of scaled cubes. The bright white strip is inside the purple PV grid, though only just. Even so, I notice that this artifact is near the end of the purple, blue and orange grids, i.e. it is bordered on an area with no data. The same is true of the two other bright white strips visible elsewhere in the scene.

 

As a separate question: we'd love to have a day/night cycle, but our interior lighting in at least some areas won't change at all along with that.

At the moment, as far as I can tell each Lighting Scenario re-bakes the entire set of ProbeVolumes. It would be awesome if we could exclude ProbeVolumes from a scenario, and re-use their data from another scenario. This would save a bit of baking time but, more importantly, potentially save a lot of data in our build sizes.

 

It's definitely possible, I did it when I was experimenting. Happy to post the code later on.

 

Here's that code I mentioned the other day. It's just unfinished, experimental stuff tossed together while messing around.

• Needs you to specify "TimeSamples" which are associated with a time of the day, and determine a) what light values to use and b) which lighting scenario to use.
• Based on the TimeSamples, rotates a sun around and sets the intensity, and interpolates between the relevant lighting scenarios. Also partially supports 2 moons (assumes they're a child of the sun).
• An Editor Coroutine which, for each TimeSample, applies the lighting and then requests a bake.

You probably need to pre-define the scenarios in the lighting window, as there's no code here to do that.

WARNING 1: This sets the scenario but it does not change the baking set. So if you have multiple baking sets make sure the correct one is selected BEFORE you click the context menu item!

Code (CSharp):

1. using System;
2. using System.Collections;
3. using UnityEngine;
4. using UnityEngine.Rendering;
5.  
6. #if UNITY_EDITOR
7. using Unity.EditorCoroutines.Editor;
8. using UnityEditor;
9. #endif
10.  
11. [ExecuteInEditMode()]
12. public class TimeOfDayController : MonoBehaviour
13. {
14.     [SerializeField]
15.     [Range(0, 1)]
16.     private float normalisedTime = 0.0f;
17.  
18.     private float prevNormalisedTime;
19.  
20.     [SerializeField]
21.     private float dayDuration = 96.0f;
22.  
23.     [SerializeField]
24.     private bool editorAdvanceTime = true;
25.  
26.     [SerializeField]
27.     private bool editorRealTimeApply = true;
28.  
29.     [SerializeField] private Light sunLight = null;
30.  
31.     [SerializeField] private float baseSunIntensity = 13000f;
32.  
33.     [SerializeField] private Light moonLight1 = null;
34.     [SerializeField] private float baseMoon1Intensity = 350.0f;
35.  
36.     [SerializeField] private Light moonLight2 = null;
37.     [SerializeField] private float baseMoon2Intensity = 350.0f;
38.  
39.     /// <summary>
40.     /// WARNING: I have NOT hooked this up.
41.     /// </summary>
42.     [SerializeField] private ProbeVolumeBakingSet bakingSet = null;
43.  
44.     [System.Serializable]
45.     public class TimeSample : IComparable<TimeSample>
46.     {
47.         /// <summary>
48.         /// What time during the day does this sample apply to?
49.         /// </summary>
50.         public float normalisedTime = 0.0f;
51.  
52.         /// <summary>
53.         /// What is the name of the associated probe volume scenario?
54.         /// It is likely that the scenario has to be manually entered into the Lighting window, I haven't
55.         /// done anything specific to create them, and I had pre-created them before I wrote this.
56.         /// </summary>
57.         public string scenarioName = "";
58.  
59.         public float sunIntensityMultiplier = 1;
60.  
61.         public float moon1IntensityMultiplier = 1;
62.  
63.         public float moon2IntensityMultiplier = 1;
64.  
65.         public int CompareTo(TimeSample other)
66.         {
67.             return normalisedTime > other.normalisedTime ? 1 : normalisedTime == other.normalisedTime ? 0 : -1;
68.         }
69.  
70.     }
71.  
72.     /// <summary>
73.     /// List of TimeSamples.
74.     /// I didn't write code to sort this, so you need to put them in order manually for now.
75.     /// </summary>
76.     [SerializeField]
77.     private TimeSample[] timeSamples = new TimeSample[0];
78.  
79.     [SerializeField] private int blendRequestFrameInterval = 30;
80.     private int blendRequestFrame = int.MinValue;
81.  
82.     #if UNITY_EDITOR
83.     /// <summary>
84.     /// Editor coroutine which requests the bakes.
85.     /// This means that the code relies on the EditorCoroutines package.
86.     /// You could of course do this some other way, e.g. with an EditorWindow which has an Update().
87.     /// </summary>
88.     private EditorCoroutine bakeRequestCoroutine = null;
89.     #endif
90.  
91.     // Update is called once per frame
92.     void Update()
93.     {
94.         bool doAdvanceTime = Application.isPlaying;
95.         bool doApplyLighting = Application.isPlaying;
96.  
97.         #if UNITY_EDITOR
98.         if (bakeRequestCoroutine == null)
99.         {
100.             doAdvanceTime = editorAdvanceTime;
101.             doApplyLighting = editorRealTimeApply;
102.         }
103.         #endif
104.  
105.         if (editorAdvanceTime) normalisedTime += Time.deltaTime / dayDuration;
106.  
107.         if (doApplyLighting && normalisedTime != prevNormalisedTime)
108.         {
109.             while (normalisedTime >= 1) normalisedTime -= 1;
110.      
111.             ApplyLighting();
112.         }
113.  
114.         prevNormalisedTime = normalisedTime;
115.     }
116.  
117.     void ApplyLighting()
118.     {
119.         if (timeSamples == null || timeSamples.Length <= 0) return;
120.         if (!ProbeReferenceVolume.instance.isInitialized) return;
121.  
122.         int currentSampleIndex = 0;
123.         for (int i = 0; i < timeSamples.Length; i++)
124.             if (timeSamples[i].normalisedTime <= normalisedTime)
125.                 currentSampleIndex = i;
126.  
127.         int nextSampleIndex = currentSampleIndex + 1;
128.         if (nextSampleIndex >= timeSamples.Length)
129.             nextSampleIndex = 0;
130.  
131.         TimeSample curTimeSample = timeSamples[currentSampleIndex];
132.         TimeSample nxtTimeSample = timeSamples[nextSampleIndex];
133.  
134.         if (ProbeReferenceVolume.instance.lightingScenario != curTimeSample.scenarioName)
135.             ProbeReferenceVolume.instance.lightingScenario = nxtTimeSample.scenarioName;
136.  
137.         float startTime = curTimeSample.normalisedTime;
138.         float endTime = nxtTimeSample.normalisedTime;
139.         if (endTime < startTime) endTime += 1;
140.         float t = normalisedTime - startTime;
141.         float d = endTime - startTime;
142.  
143.         float l = t / d;
144.  
145.         if (sunLight != null)
146.         {
147.             sunLight.transform.localEulerAngles = new Vector3(normalisedTime * 360.0f - 90.0f, 0, 0);
148.      
149.             sunLight.intensity = baseSunIntensity * Mathf.Lerp(
150.                 curTimeSample.sunIntensityMultiplier,
151.                 nxtTimeSample.sunIntensityMultiplier,
152.                 l
153.             );
154.         }
155.  
156.         if (moonLight1 != null)
157.         {
158.             moonLight1.intensity = baseMoon1Intensity * Mathf.Lerp(
159.                 curTimeSample.moon1IntensityMultiplier,
160.                 nxtTimeSample.moon1IntensityMultiplier,
161.                 l
162.             );
163.         }
164.  
165.         if (moonLight2 != null)
166.         {
167.             moonLight1.intensity = baseMoon2Intensity * Mathf.Lerp(
168.                 curTimeSample.moon2IntensityMultiplier,
169.                 nxtTimeSample.moon2IntensityMultiplier,
170.                 l
171.             );
172.         }
173.  
174.         // We probably don't want to submit new volume blend requests every frame, but do want to request them
175.         // often enough that the lighting doesn't obviously jump.
176.         // This just assumes to put them X frames apart, which probably isn't a great strategy.
177.         int frame = Time.frameCount;
178.         if (frame >= blendRequestFrame + blendRequestFrameInterval)
179.         {
180.             ProbeReferenceVolume.instance.BlendLightingScenario(timeSamples[nextSampleIndex].scenarioName, l);
181.             blendRequestFrame = frame;
182.         }
183.  
184.     }
185.  
186.     public TimeSample GetTimeSampleByIndex(int i)
187.     {
188.         if (i >= 0 && i < timeSamples.Length)
189.         {
190.             return timeSamples[i];
191.         }
192.         else
193.         {
194.             Debug.LogError("Attempting to access TimeSample at invalid index " + i, this);
195.             return null;
196.         }
197.     }
198.  
199.     #if UNITY_EDITOR
200.     [ContextMenu("Request bake light scenarios")]
201.     public void RequestBakeProbeVolumeScenarios()
202.     {
203.         // Start a coroutine which requests a light bake for each of the "Samples" we've listed.
204.         bakeRequestCoroutine = EditorCoroutineUtility.StartCoroutine(PerformLightScenarioBakes(), this);
205.     }
206.  
207.     private IEnumerator PerformLightScenarioBakes()
208.     {
209.         // If auto-generate is enabled then abort, because we can't request bakes.
210.         if (Lightmapping.lightingSettings.autoGenerate)
211.         {
212.             Debug.LogError("Automated light scenario baking only works with auto bake disabled.", this);
213.             yield break;
214.         }
215.  
216.         // For each of our listed time samples:
217.         for (int si = 0; si < timeSamples.Length; si++)
218.         {
219.             Debug.Log("Preparing to bake lighting scenario " + timeSamples[si].scenarioName);
220.      
221.             // Apply the desired light settings.
222.             // The desired lighting scenario is set in the light manager as a part of ApplyLighting()
223.             // I've not checked whether or not it has to be created in advance, or if this will create it.
224.             normalisedTime = timeSamples[si].normalisedTime + Mathf.Epsilon;
225.             ApplyLighting();
226.      
227.             // Request a bake.
228.             // The bake still happens in the background, so the Editor is still active.
229.             Lightmapping.BakeAsync();
230.      
231.             // Wait until the current bake is finished before requesting the next.
232.             while (Lightmapping.isRunning)
233.             {
234.                 yield return null;
235.             }
236.         }
237.  
238.         Debug.Log("All lighting scenarios baked.", this);
239.     }
240.     #endif
241.  
242. }
243.  

 

For me, APV is one of the most impressed feature from Unity recently because the result is good and learning curve is much lower compare to lightmapping. Thank you for your hard work and good luck.

 

Hi everyone!
I am just started testing the system and it looking nice so far, great work!
But I have problems with multiple volume setup, I have done 1 global and two volumes with values according to documentation but still it generate the probes only for the smallest one, does anyone faced some similar issue?


Also I think its worth to share a difference with APV on and off on the scene with terrain and foliage with 11 meters between probes, it still add a nice GI feel to the view, I wanted to increase a probe density in interesting areas but cant find out the proper way

 

I actually reported this bug a while ago (1 month), and talked about it here in this thread -- bug report: IN-30979
If I'm understanding QuadArt's issue correctly then it's what I talked about, probe volume ignores layer mask when there's more than one probe volume, so you can't tell it to be dense for certain layers/meshes and use a different density for others.

Local override works when you have one probe volume, but once you have 2 and up, it seems to be an issue and in particular when using layer masks. (Which is important as I was trying to increase probe density to decrease light leaks from walls, but didn't want it to apply to everything else)

more info in thread: https://forum.unity.com/threads/ada...or-hdrp-in-2021-2.1238824/page-8#post-8778994

 

I'm not sure if QuadArt is using layer masks, but I was for my bug report -- I was using two probe volumes, one for "walls" and the other is for everything else except walls.

It seems QA might be a bit confused as the title doesn't make it clear that the issue is layer masks.
It's been in limbo for a month with QA, even though it has a reviewer assigned for a while now.

 

Thanks for the answers, I was not used layer masks on that example, I think the problem caused by editor version, I am not sure how the update procedure works for experimental features I am using 2021.3 (as a publisher its important for me to use widely used version) but I guess it should recive at least a bug fixes, is that correct?

Because I tried everything as you described but still the probes generates only for smallest volume

 

Hmm, got it working fine on the main level with same volume setup, problem solved I guess


Couldn't resist to post some more images with APV and without, the tech is so great!

 

Hi @adrien-de-tocqueville !! I would like to ask about the urp support of APV, whether they support mobile devices and webgl or not? If yes,than does it support all mobile devices just like lightmaps?

 

I'd love for something like this for procedurally generated scenes. Anyone have any clue how that could be possible?

 

Your only choice is using the real time stuff.
SSGI, Raytracing, or other GI solutions from asset store, combine with time slicing realtime reflection probe or Raytrace reflection. All of these have a significant impact on frame budget btw. min spec for Lumen is also applied here as well.

 

Have a test with APV. Result is nice.
I have 2 point lights with indirect multipiler only at 0.1

 

small feedback after a brief use with it, please add a "Add current scene" button, instead of this long list.
A huge project with tons of demo scene from asset store, picking via a list is not easy, especially scenes can have same name.



Also, is there no way to debug to see the effect of AVP toggle between on and off?

 

Hi, what is this noise that I'm getting with APV? It's visible across entire screen where direct light isn't present. Only if APV is enabled and I don't have any raymarching effects active. Highes APV settings in hdrp.

APV disabled on camera, no other change:


EDIT: It reduces if I decrease the amount of probes but remains visible and I don't want to reduce amount of probes. The screenshot is with 0.5 meter distance between them.

 

That's the sampling bias APV uses to hide seams. You can find it and adjust the values in the post process override "probe volume options".

It has an option to be animated, but only if you're using TAA (to see that in action, press play with TAA & animated noise enabled). This will animate the noise and make it less noticeable. Sometimes it can still be noticed though, tough to balance sometimes.

 

Thanks. Unfortunate that it's so bad but not surprising. It won't go away.

 

Thank you! I just download 2023.1
I'm very excited about these showcase

it shows blending to support dynamic lighting change.
Will we get the tutorial for this anytime soon?

 

Our project is a project about digital human . I found that this APVs cannot be used on the Skined Mesh Renderer. So I hoped that the later version will be used on the skin, eyes, hair and clothing of digital human

 

Pretty sure APV works with skined mesh in HDRP from day one.
you better check the shaders you used, maybe it's a shader side problem.

 

Hi,

I posted a lot on this thread but I made a single post that summarises some of my posts here about APV. Was going to post it on this thread but did it in the GI section.

You can read it here: https://forum.unity.com/threads/fee...2023-1-beta-tech-stream.1412454/#post-8889324

 

@adrien-de-tocqueville

Hi,

In 2023.1.b9 - APV virtual offset fails to detect many probes inside geometry, causing severe light leaking.
I've used multiple virtual offset values, including very high values, still doesn't detect some probes.



The white probes are inside the wall.

Virtual offset:




Also, some probes are moved around with virtual offset even when far from geomtry, and not inside any geo:


I tested with somewhat small values for Search Distance Multiplier (0.25), and virtual offset still incorrectly moves these probes.

 

The roof is weirdly shaped so it could be an issue due to shape complexity, but the wall is a simple flat wall - virtual offset should work there, could be a regression as I think it used to work on older versions but been a while since I did it.

 

Hello, everyone. When I tried to use APV, I often saw a ghost at the junction of two volumes. Has anyone had this problem? Large volumes are nested within small volumes, with large volumes set to a distance of 9-27m and small volumes set to a distance of 1-3m.

 

So. . . . . umm can we get more info about this part? it seems you guys already have the system implemented, this is big you know especially when i don't have to deal we blending multiple scenario manually, which i don't mind. But if there's a automated solution built in this would be great since we can choose between manual blend or automatic.

 

@adrien-de-tocqueville hi!
How can I enable specular occlusion for APVs?

 

i'm intrigued, can you show an example for the shadergraph?

 

Wait, that technique also work for APV? i thought it was only for lightmap. . .

 

GI node in Shader graph got APV support recently, so it should work as expected. I forgot exactly which version though.

 

I'm testing the Probe Volume feature and I got an issue in all my scenarios. The baking and generation works ok, probes show up in the debbuger view, but the scene and game views go black whenever there is a non-static object to render in the field of view.

Using Unity 2021.3.21, HDRP 12.1.10

Probe volume feature is enabled in the HDRP asset, the HDRP global settings and the default Frame settings. Lights are baked, probe volume settings are all set to default, probes are present in the scene. I can't see any error or warning anywhere.

Any idea about what's going on here?