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

Still not working for me

 

The warning on the probe about it needing to be baked is a known bug I believe. It basically always says it. I have documented the exact cause somewhere in this thread. The warning itself is harmless though, and doesnt impact probes working.

 

The flickering issues have completely gone away since removing lightmapping completely from the project/changing all renderers to light probes only.

 

This is a big improvement!

I would really like to see some kind of runtime "update" support, not only for procedural worlds but also for supporting less static environments.

 

Can somebody create a brief video of how to get this going on a simple scene please?
I simple cube, open on one side would do I think...

I'm still not able to get a simple setup going and dont see ANY probes in viewport or any change in lighting in a HDRP scene in 2023.1 alpha

 

Here:

No audio but you should be able to follow along.

- When using global mode for APV placement, you just need to CTRL + S (to save project) then APV global mode will update to cover all objects that receive probe lighting.

In the scene, all walls/floors/ceilings are lightmapped, everything other (all the props, debris, etc) are receiving APV lighting. Even though they're static, this has a massive increase in bake times.

Basically, you need to enable APV in your active HDRP asset, HDRP global settings, and camera.
Then create a probe volume in the hierarchy, mark it as global and save your project or manually adjust it to cover your objects.

Make sure your sun is set to mixed, otherwise there won't be any indirect light, thus APV wouldn't be able to do its job.
or any lights you want to be included in GI.

 

I ported a game level to 2022.2 to test APV, results are pretty good!
Best part is I don't have to worry about UVs, or LODS. Runtime performance is good enough that I don't even think about it at all. I can also offload a lot of objects/props to APV, that way bakes can be faster & some scenes that previously were hard or impossible to bake become doable.

If you're using APV for props, and not just dynamic chars, you need some really heavy SSAO to add detail. wish APV had an ambient occlusion mode similar to the lightmapper.

I do realize these point lights don't have shadows, which plays a big part. You still need SSAO though even with them on.

With big closed off objects though, like buildings (modular, APV for everything, not just props), it struggles. There's a lot of noise and I think light leaking.


All props are APV lit, open images and switch between them to see the difference
SSAO on and off:

 

Thanks I will take a look at yuour vid a bit later, just busy currently

All my stuff is static in scene. I dont want to bake anjy lightmaps or do any baking other than APV. I'm still trying to understand if this aids in any way if I use raytracing / pathtracing

 

I think we can get a form of real-time GI solution with the following new features and improvements:

First, we need this:


It's too expensive for real-time when using multiple probes, even with slicing, and you only care about the lighting

Second, and just as important, SSGI improvements. It's clearly lacking, there's a few assets currently with better visuals and similar or better performance.

Finally, APV improvements. Unfortunately, APV is limited by severe performance limitations and URP.. even though we use HDRP to escape that hell.

Obviously APV isn't real-time GI, but it's capable of blending lightmaps, and bakes are fast that it's not a bother for the most part, plus no need to worry about lightmap UVs.

And the beauty of APV is you can easily add multiple volumes to increase or decrease probe count, no matter how big your scene is.

You can already get good GI with SSGI + APV, and it's hassle-free compared to lightmaps. Unfortunately, it falls short for a full-blown replacement for lightmapping, currently you can get good results with small objects/props and exterior scenes, but struggles with complex meshes, and interiors. Light leaking starts becoming a problem, and noise/artifacts becomes quite severe. One of the ways to mitigate noise are the parameters exposed in the APV post process volume, but they're like a trade, you sacrifice quality for less noise, and once you go too far it becomes almost unusable.

With SSGI and APV improvements, this could be a really good solution as a full replacement for global illumination.


And SSGI has APV fallback.
The secret is SSGI performance, (and to a lesser degree, APV), but I believe the biggest performance cost will be SSGI. For the most part, SSGI will be there to further improve APV results and add small details that APV misses.

 

To fur

further thoughts, excuse my excitement but lightmap hell is real, APV is my only possible saviour
And it's so close to replacing lightmaps, so close you can almost feel it. Don't tell me you don't see it, look up at the sky, it burns.


in this asset, most meshes have 2-4 LODs, making lightmapping worse than previously thought possible, but in comes APV.

Slap a volume, fit to scene, reduce size slightly, bake, done. No UV issues, no overlap hell, bake's done in less than a minute with all these LODs. (The terrain is lightmapped though)

Best of all, lightmap transition between LODs is seamless.
Results are far better than no GI, but the current issues in particular are noise/light leaking.

Comparisions in this video:
Note: One big difference you'll notice right away is ambient occlusion, the lightmap had AO enabled, that's not available for APV so that part does change things up quite a bit.
If it was disabled, the result would be closer between the two.
Also, APV feeds volumetric fog with color info so that changes up as well.
- Sky GI not included in the video, just indirect sunlight
-

As you can see the indirect lighting is great, and this is an exterior scene so all the better for APV.
About SSGI, in particular the denoiser included in SSGI helps reduce APV noise, but SSGI improves quality in some places, while decreasing it in others, video:
-

(Forgot to hold mouse so SSGI didn't accumulate in the first example)


Honestly, even without Realtime GI/blending, I would be content with this replacing lightmaps.
Another thing, check this out:


Size in the bottom is quite high, maybe 1 probe density is considered very dense, but you do need quite a few probes when using it as a full lightmap replacement solution. In some of my tests I even used 0.5 density (crazy )
Is scenario size disk size, or VRAM?

Ticking APV streaming in HDRP settings seems to help, but I'm not sure about the details, currently no documentation about it.



I do think this scene is one of the easier ones for APV in a way, the cliff textures can somewhat hide the noise, but at the same time there's a ton of detail and indirect lighting going on here, and as you can see APV does very well here all things considered. The real challenge would be interiors and buildings, when I tested it a while ago (unfortunately forgot to post/record) the light leaking and noise was much, much worse than this scene.

 

Thanks for this detailed writeup!

 

Will SSGI be supported for URP?(because it seems necessary for APV support)

HDRP SSGI does need some improvements in terms of performance, quality and denoising. The team behind ssgi must take some notes from this asset https://assetstore.unity.com/packag...mera-effects/h-trace-gi-occlusion-hdrp-233762

 

Yeah... experimental releases are something

 

What happened to the option of baking probes without recalculating placement? I couldn't find it in 2023.1.a15. Maybe it's enabled by default now?

Also, dilation & virtual offset don't have default values anymore, played around with the settings for a while. The probe volume rendering debugger is great!

 

I remember old probe volume had default values for dilation & virtual offset, very easy to enter bad settings and make the results worse (search radius & search distance multiplier and geometry bias)

 

One more thing I forgot to mention
I was hoping to maybe use probe lighting for All LODs after LOD0, but it looks like the way lightmapping and APV light up objects is different. Maybe they treat normal maps differently, sort of like directional mode. This means you can't really do a smooth transition from lightmapping to probe lighting or vice versa, as the switch in lighting becomes noticeable. And so, each object has to decide whether to go all lightmapping, or all probe lighting. Although a fair distance away it's probably doable, especially with some fog.

One more reason APV should take over for good

>> from lightmap to probe lighting:

 

another scene baked with APV, lots of LODs

 

Facing some issues born from dilation and virtual offset:

I wish virtual offset was more reliable at moving probes correctly, it tends to mess up sometimes and move probes inside of geometry, creates serious issues.

In this scene, with the following settings:


probes going in geometry by virtual offset:



If only they moved to the left:




I tried to improve it with probe adjustment volumes, invalidate&custom virtual offset, still can't get rid of most of the artifacts.

- Disabling dilation mostly fixes it. but then I have no dilation :/
and APV adjustment volume doesn't have dilation settings, so it's baked only


This is using dense probe placement (0.5), with a large value for probe indirect/env samples.

- BTW, "display probes" visualization is broken in 2023.1.a17 - error:



-- edit: decreasing dilation "validity threshold" helps alleviate the issue, decreasing it means less probes will be marked as invalid, and so less probes are being affected by dilation. Which might create issues in other places but oh well

 

I've been trying to remove the following light leaks for an embarrassingly long time
No matter what the settings are, there's always some tiny light leaking going on.
Removing the one in the picture, creates 3 other light leaks, removing those creates other areas with light leaks lol

(On the ground, one tiny spot), this is the best I got after many setting changes and experimentation



Not being able to see probes makes things a bit more difficult as you can imagine
(Not complaining about Probe visualization, it's an alpha, just sharing my pain )

One idea is to place some light prop over that area to hide it, but that's a slippery slope

 

I wish the probe volume had a green zone for placement, sort of like reflection probe placement (and the probe adjustment volume).
It's really hard to tell if it's under a mesh, over, and so on without it.

APV:
Ref Probe:

My eyesight would be forever grateful

 

Is it normal/expected that increasing bake samples produces new light leaks?
For my scene, baking with 5k samples produces far more light leaking than 2k samples.

 

I give up on using APV as a full lightmap replacement in its current state.

The amount of light leaking is frustrating, and even worse is that every second thing you do seems to create new light leaks and issues.

I set up one volume to cover my interiors/building with dense probe count, baked, alright there's quite a few light leaks. No worries, using APV debugger I visualize probes and place probe adjustment volumes to invalidate the problematic probes. Alright, this interior now looks okay, a few issues but usable.

I place another volume to cover the exterior, less probes compared to the interior, Bake, and all of a sudden, my interior now has a ton of new light leaks. Even though the second volume doesn't touch it, there shouldn't be a single probe from that exterior volume effecting the interior one.

Increasing samples/decreasing them creates new light leaks, worst part is the problematic probes are also new, so you need new adjustment volumes. And most likely, the old ones are now useless. Repeat.

For some reason, some probes are super bright, can't find anything that would cause them to go crazy, not inside of geometry, no bad probes around them, but here they are, 20 times brighter than any probe near it, causing issues.

And some light leaks are harder to get rid of then others, even with light adjustment volumes, and sometimes getting rid of that one light leak with a probe adjustment volume will create other issues.

Spoiler: complaints

It's like I traded the issues of unity's lightmapper for different issues in APV.
APV gets rid of most of the usual pain points, with APV you get fast light baking, quick iteration, no lightmap UVs, and so on.
But then there's noise, light leaks. And the features it offers like virtual offset, dilation, all feel like a hack. Both dilation and virtual offset issues can cause issues for me, even with the right, most pristine settings for my specific scene.
View bias/normal bias, same story, feels like fighting a losing battle sometimes. Increasing normal bias might get rid of some issues, but then creates a few issues in different spots. Same thing with view bias. You'd try to find a balance for the two, not too much, but usually it'll still not be enough.

Sorry for the rant, I know a lot of work went into it, probably over years, not to take away from the achievements of those who worked on it and so on but man, I refuse to use unity's lightmapper and I was hoping APV would be my way out. APV is amazing when it works, but it's proving to be extremely difficult to get it to work as a full Gi solution, In particular with interiors. And they don't have to be completely closed off, just a few walls, and a good chance you'll face issues.

This post discusses APV when using APV for all objects, not just small props and dynamic chars, it does that very well and easily replaces the old probe system. Also does exteriors pretty well.

Sorry for invading this thread the last few weeks

 

APV seemed to work well in the enemies demo and Unite's sponza...

 

This is a perfect summary of my experience with APV. Lots of it feels hacky and barely working, it's currently far from being usable in a real production. Can't wait for a version that is actually usable though, so we lightmap haters can finally rejoice
My only concern is, as always with Unity, how long will it take...

The Enemies demo also uses SSGI which helps quite a lot to mitigate APV artifacts. I'd actually be curious to see how it looks without SSGI.
As for Sponza, if you are referring to this post, then you can clearly see some dark spots on the walls that shouldn't be there.

 

I realize that my posts the last few weeks often mentioned probe density, all my interiors are baked with very dense probe count, which isn't always a solution. Since dilation and virtual offset are so inconsistent, sometimes more probes even cause issues somehow. All my walls are reasonably thick, not too much, not too little.

I also have tried countless different samples, from max, middle, to low.

Sounds like this is the way APV intends to stay at, just a light probe replacement. Well, that's frustrating. Especially since unity's lightmapper is a joke.

 

Looking forward to SSGI + APV (as a fallback to SSGI).
Is it wrong to expect SSGI + APV as an alternative to lightmap baking?
I don't think anyone misunderstands that"APV only" can be replaced with Lightmap baking.

I would like UnityDev to focus more on real-time GI solutions than lightmap baking.
The words bake and bake are lined up on the roadmap, and I'm worried.

However, this may be a selfish desire. Because I think lightmap baking is still necessary for mobile.

 

So if I only use pathtracing, does APV help in any way or its not needed in that case?

 

Out of curiosity, can you share any screenshot of what kind of light leaking that you getting?

Edit : oh that tiny spot. . . i totally missed that, my bad

 

i don't think APV as a replacement for lightmaps, maybe is my ignorance but lightmaps are still a very valid GI technique specially for mid or low-end devices, right now if i'm making a AAA game with amazing realistic graphics just for high-end Pcs i'll prefer to use lightmaps in static areas. I also think APV is not that accurate.

Why you think unity's lightmapper is a joke for games?

Please don't. that will be a mistake at least for me

 

Apv didn't use depth map like ddgi, which solve leaking, because of that mean a n^3 x map size^2 memory pressure.

But given they already have an indirection structure, where the grids doesn't own the probe, but a reference to a packed structure, why not have a tag system that only hold depth map or any tie breaking equivalents FOR ONLY probe that need it? The worse TYPICAL case becomes n^2 memory pressure, since we would only store for probe that need it. Also can disable it if the hardware is low enough, or we need the extra space.

We could even have a kind of tile system in which we don't store the full cubemap worth of data, but only the useful cone direction of the map.

Also depth map aren't the only solution, just the most effective. Typically probe are interpolated along a cube sampling, invalid neighbor is whatcauses leaks. We need data about the neighborhood links to validate interpolation, instead of a full depth map, just a depth and a normal along the links with a tag to invalidate that link. Maybe? I'll try it for myself, if I figure out the issue I'm having with my gi solution.

 

Hi all, I started to investigate the use of Probe Volumes for my project. From what I read, I was assuming that it would be possible to handle the following scenario:
- split the world in multiple scenes
- bake each scene separately
- load multiple scenes at runtime using additive mode
- have lightmaps and probe volumes work in that context

From my early tests, loading two scenes works with lightmaps, but not with probe volumes: I only get probe volumes generated by one of the two scenes loaded, but not the other.

Am I missing something ?

 

Congrats on the paper, it's neat!

 

@francescoc_unity thanks for the heads up.
I think I see how to do that in code (using Lightmapping.BakeMultipleScenes), but I'm not sure how to proceed from the Lighting editor. I can't find anything that resembles the notion of a baking set where I can gather all my scenes. How do you set up your scenes to be in the same baking set ?

[EDIT] After a few tests, I can see that I can bake a set of scenes at once by simply opening them in editor, and I will get a single set of Probe Volume data for all these scenes. I see that the lightingData asset now has a list of all my scenes. That's a good start.

Now I need to figure out how I can rebake ONLY ONE of those scenes (rebaking the whole set after a simple local change in one scene would stall my workflow).

 

We've tried to switch from lightmapping + probes to APV.
The result is.. weird. In tests, we've been getting quite nice lighting, but when we switched to the real scene, everything went in a weird direction.
All objects have black bottom part (obviously, because some APV probes is under ground), but it wasn't an issue in our previous tests where ground were simulated by a mesh. Is there anything we're missing to get the APV working well? Terrain is using lightmapping



Image from test:

 

Is there/will be there any public API for the ProbeVolumeAsset? I wish it to not repeat the fate of the blackbox LightingDataAsset. It would be great to be able to specify probe positions and colors manually, or even have more fine-grained methods, e.g. ask the editor to compute the positions but set your own colors.

 

We've tried with both on, and with virtual offset off, here's the result:



It looks even worse.

Btw, we're on 2022.1.22

 

In my current project (unity 2022.2.13), I have two baking sets, each with one scene and one scenario: when I change between baking sets the lighting data seems to change from the last time that set was baked. I generate lighting in one set for the one loaded scene. I switch sets, generate lighting in this new set, all is good, but then when I go back to the first set, it seems than things have shifted. Am I missing something?

 

so now in 2023.1. Where does one find the leak reduction mode setting?

 

How can I add lighting scenarios and bake them from script?

Edit: Ah, I see the source here:
Packages/com.unity.render-pipelines.core/Editor/Lighting/ProbeVolume/ProbeVolumeBakingWindow.cs

 

unity 2022.2.0b12, all settings is hight