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

Yeah it does, I have some questions regarding APV

1- Will Someday APV be considered replacement for lightmap baking? and when? (expected time like this year or after this year)
2- Is there some kind of detailed unity documentation to fix the light leaks of APV? I've seen the video but it doesn't explain it very well
3- Is there preferred settings for APV to get the best result and avoid light leaks?
4- Does these settings affect apv? (Direct samples, Indirect samples, Env samples, Max bounces, Lightmap resolution, Lightmap Padding, Max lightmap size, Albedo boost and indirect intensity)

And thank you!

 

Thank you so much! This would be a great thing for optimizing the performance on low end and mobile devices. I will say, I like the mixed (L0, L1 ver pixel and L2 per vertex) option. It offers a nice tradeoff.

On UE5 their equivalent of APV only does per object (like the old probe system) for all mobile devices. I'm glad Unity is more configurable, since it seems like a bit of a waste to have a new probe volumes-like system under the hood and not utilize any of its improvements.

Good work so far!

 

I believe Light mapping will be around for a long time. This can replace it in some situations, but there will always be cases and scenarios that are better fitted to lightmaps. I don't think it is meant to be a lightmap replacement, but it seems designed to be a viable alternative in many cases, and in others to work together with lightmaps.

 

I still have a problem with enabling (APV)
(Probe Volumes are not enabled. Make sure Light Probe System is set to Probe Volumes in the URP asset in use.)


I have no idea how to enable AV this in (URP(2023.1) the tutorial didn't help

 

For Anyone Want To Test APV in URP

To enable APV in URP, go to the univsesal renderpipeline asset your project currently use.
(can be found via Project settings->Graphics->Default render pipeline).


Once inspect the URP asset. Under Lighting category,
Switch the Light Probe System From Light Probe Groups to Probe Volume.



Then yoo are good to go.



===========================
Feedback to Unity :

1. The UX workflow definetly has space to improve though. I'm using URP for years and it still took me quite a time to find it lol.

2. I really enjoy the result and process of using APV. It require much less time/memory to light the scene with per-pixel probe lighting (WOW!). Looking forward to it.

Another complain :
I've ask somthing like HDRP setup wizard(cuz I love it) for URP in a blitz day post and the URP staff ask me why I'm not create a urp project directly through Unity Hub (I have no words).This is one of the case that a setup wizard can be really helpful.
===========================

 

Thanks a lot this guide helped me to enable (APV)

 

Hey Adrien.Thanks for the quick adjust that was quick! I think the button along will be enough here.

====================
Speaking of wizard. I'm more about the wizard for URP, which does not exist(I think) at the moment. However, since URP and HDRP are moving towards a more unified/coexistent direction, a setup wizard for URP could help people quickly set up and navigate through the required SRP assets. It's just a small suggestion I don't meant to derail this thread from APV topic too much.
====================

 

Any ideas on this still? As far as I can tell the URP version of APV doesn't pass through any APV data through the Baked GI node.

 

One thing I will stress for anyone reading this who is curious, if your scene is fairly dark (ie space themed/moody/shadowy) without much light, you will NOT be happy with using APV on most of your game objects. For this, Lightmapping is going to be the best way to go. For anything that receives even moderate lighting though, you should give this a try. With some other modifications to the scene you can get this working quite nicely.

 

Can anyone confirm that APVs are attached to the first loaded scene with the APV? To give some context, I am loading scenes additively and removing them as they are out of range. However, if the first scene is unloaded the APV is also unloaded for all the scenes despite being part of the same set. Is this intended? Hopefully, I am making sense.

 

I am using 2023.1. My current solution is to keep a dummy scene actively loaded with a Probe Volume. If I allow the scene to unload, the APV disappear from the scenes that are loaded.

 

Using this with Lightmapping as well on URP with Entities package. However, it seems the lightmaps are not converting correctly, but APV is. So probe lit objects look great and lightmapped object are both extremely bright and extremely dark.

 

That's really interesting, what do you mean by "converting"? It's probably a bug from the sounds of it. Do you have a screenshot? Just to help out any unity staff who might be able to investigate the problem for you.

 

I mean Subscene conversion to ECS. The Entities Graphics package seems to have it, but somehow it is not rendering with the lightmaps correctly.

Edit:
FYI, I have narrowed it down to the Entities.Graphics package.

 

I reverted fix and now it works as expected.

 

Will the team continue to improve the light leaking issue?

 

Well APV turning off when certain scenes are unloaded has returned despite all the active and loaded scenes are part ot the same bake set.

 

Will this fix the light leaking problem from thin wall?

 

Is there a way to change the contribution type for MeshRenderer in a editor script?

 

Yes! I am using the Probe Volume gamebobject for each of my scenes.

 

It's still impossible to fix some light leaking issue if I use probe volume only. Is it possible to implement visibility check? Which store depth data of each probe in another texture.

 

I'm using Unity 2022.3.0. From the "Probe Volume Settings" I see that I can create different Lighting Scenario and this is fantastic (I need a scenario for day and another for night), how can I switch from one to another from code? (event without blending... just set the "Active Scenario" from code.

 

Is there any other way to improve the light leaking? For example is it possible to have a system similar to light layer? What problem I have now is if I push the probe on the wall in, the foliages on other side will be very dark; if I push it out, the wall and objects inside will be very bright.

 

Thank you for sharing!

I've just one last doubt. It seems that the BlendLightingScenario is not smoothly blending between the two scene, I actually experience an sudden change from scenario 1 to scenario 2.

I'm also trying to animate the scenarioBlendingFactor variable... but without any success:

Code (CSharp):

1.        
2.         // The active scenario is "Scenario_1"
3.         ProbeReferenceVolume.instance.scenarioBlendingFactor = 0;
4.         ProbeReferenceVolume.instance.lightingScenario = "Scenario_2";
5.         DOVirtual.Float(0, 1, 2, (fl) =>
6.         {
7.             ProbeReferenceVolume.instance.scenarioBlendingFactor = fl;
8.         });
9.  

Is there anything wrong with my understanding of the API? please note I'm on Unity 2022.3.0.

Thank you

 

I'm currently working on a single scene where I dynamically enable and disable GameObjects at runtime. The scene follows a specific architecture with World_A and World_B, which can be activated or deactivated as needed.

Scene Structure:

Code (JavaScript):

1.  
2. Scene
3. |
4. |___Shared_items (active)
5. |       |___Various items
6. |
7. |___World_A (active)
8. |       |___Cubes
9. |
10. |___World B (not active)
11.        |___ Spheres  

To properly bake lighting probes, I manually toggle the activation of World_A and World_B and perform the necessary baking for each scenario, resulting in two different lighting scenarios: "lights_A" and "lights_B." However, I've encountered a challenge where baking probes for World_B marks the previously baked lighting scenario for World_A as "out of date," and vice versa when baking probes for World_A with World_B already baked. This has led me to consider the best approach for handling multiple lighting scenarios in a similar context.

One potential solution I'm contemplating is splitting the scene into separate scenes, each with its own dedicated probe volume. This way, I could maintain the Main Scene and dynamically load the desired subscenes (World_A or World_B) during runtime. In this approach, it would be advisable to utilize different Bake Sets for each "world" scene, ensuring proper isolation and updating of lighting data for each specific scenario... is this the right way to go or can I keep all the "worlds" in the same scene and some how bake the 2 lighting scenario?

 

If anyone else requires the aforementioned architecture, it functions flawlessly when working with additive scenes. It is crucial to maintain a separate "Baking Set" for each additive scene or group of scenes.

The mistake I made initally was attempting to use a single "Baking Set" for different scenes, corresponding to distinct scene structures (World_A and World_B). That being said, instead of a single Baking Set with World_A and World_B and all the lighting scenarios... just split the lighting scenario in 2 Baking Set, one for World_A and one for World_B.

I'm impressed by the fact that you can easily switch between different lighting scenarios and Unity automatically knows which is the current Baking Set to get the scenario from, depending on the scene currently loaded (I hope I'm doing the right thing since it seems all too automatic ).
So at the moment I can have 1 "Day" and 1 "Night" scenario for each World, and Unity automatically picks the scenario from the current Baking Set.

Code (CSharp):

1.  
2. // Change lighting scenario
3. ProbeReferenceVolume.instance.lightingScenario = "Day";
4.  

 

I'm trying to use a Probe Adjustment Volume to invalidate probes but it doesn't seem to do anything.

In this case we have a room with a ceiling that is bleeding light from the outside. The probes on top of the ceiling were invalidated but the ceiling brightness doesn't change even though we can see the probes are invalid in the debug view:



I'm using 2023.1.2f1

 

I faced this issue as well. Ideally I can add fake thickness to walls/floors etc with invalidate adjustment volumes, but it doesn't seem to work. Maybe because the invalidated probes simply replace their lighting with nearby probes which are outside the room and thus still cause leaking, but it's a big issue. Light leaking in APV is the biggest issue for me.

Virtual offset adjustment volumes help, but I would need to place an unbelievable number of them, especially in slightly more complex rooms.

Virtual offset by itself (the global bake setting) seems to miss many probes inside of geometry, not triggered at all. Posted a thread about it in the HDRP section.

 

Thanks, virtual offset does indeed work and kinda does the same thing if you push them into invalid geometry but it is strange how probe invalidation does not work.

It would be better since you can do it without rebaking.

As for the leaking, it is the biggest issue of APV and I think everyone agrees. APV is amazing but this issue is tough to work around.

 

The presentation said "designed for large worlds" but I'm seeing "15 hours left" next to the progress bar. Is there any way to get that down to a reasonable 10 minutes? Because obviously I can't just sit and wait 15 hours (per lighting scenario) after every scene change.

I can increase the minimum probe spacing but at that point I might as well not be using GI.

Don't really see the point of this system. It doesn't seem to solve any use cases Enlighten doesn't. Certainly doesn't fill the need to have a dynamic GI system like every other engine has. Players are already pointing out the bad lighting in Unity games. It's really holding HDRP back.

 

it also completely fails to bake with large worlds. progress completely stops even when left for days. cpu usage goes to 0. and ram usage by unity drops to less than a gigabyte. I assume it hangs internally and never completes. The only solution I found to this, is to bake scenes individually, which leads to some lightning inconsistancies inbetween connecting scenes.

 

Yes, I have noticed this as well. Seems like something that needs fixed asap.

 

I've been having a very strange error.

I'm trying to bake a point light or an area light using APVs to make the room look all nice.

When baking with a direct light, the colours all come out great. In the past, I thought this was the case with points, but it's possible i was being deceived by mixed lighting.

I was trying to bake a darker scene, lit only by point and area lights, and the light came out as red.

This, as you might imagine, was unexpected.



In the spirit of experimentation, I've played around with various settings. Above is the settings I used for test 2 - also red, where i cranked up the lumens to 40,000 to see if it was because the scene was too dark. In the initial picture it was at 1500. When baked in mixed mode, there is no apparent red, but that seems to be because there's nothing on the light probes at all.

The directional light sun still bakes properly.

I tried reselecting the filter and temperature, changing colour mode. Most exciting was making the filter blue, at which point the light comes out as green.

I'm sure I'm missing something basic, but i can't for the life of me work out what it is.


Although with this setting and lighting turned on the scene view I see nothing at all.

I'm using 2023.1.0.b18, HDRP 15.0.5. Has anybody else experienced this, or anything similar? I am very confused.

 

I have 'fixed' this problem.

The solution is rotating the light 90 degrees on the x axis.

This also worked with my area lights - the further from 180 degrees they were, the less orange the light.