I had the pleasure to talk with @Pema-Malling regarding APV.
We were comparing a custom GI probe system i made in Birp.
You can have a look at the discussion here.
I am having an issue with Unity 6 URP.
As you can see on the image below, the emissive material is not taken into account at all.
This thing should lit up my tunnel.
Any idea why this is happening?
I looked for all baking setup possible but still can’t find the reason why…
What shader / material are the emissive meshes using?
@sacb0y Oh man spot on!
Thanks a lot!
Another issue i am having, is how harsh some of the transitions are. (Almost feel like the transition is vertex based and not pixel based.)
In my tunnel you can see the outside vs inside transition is super harsh.
This might be the case there is a setting to force it.
This might be the case if you set an android build target, the default setting is “auto” and android seems to trigger vertex mode.
Oh Interesting.
I am on iOS tho, any idea where this setting is on Android?
One thing i feel super frustrating with URP in general is how the settings are all over the place.
There are at least 3 different place to look for AVP Probes settings etc…
Its super time consuming.
It can make sense when you get used to it, it really comes down to what’s needed or benefits from localized (volume) settings vs global settings especially when it comes to multiple platforms.
In this case vertex vs pixel is a performance issue so it’s in your universal pipeline asset so that it can change with quality settings or per platform.
Under light settings, SH Evaluation mode. If you don’t see it you may need to enabled advanced settings.
If it helps to gain some perspective on how things seem to be designed I made a thread about better utilization.
Hey @sacb0y Thanks a lot for the answer.
Sadly, i have looked everywhere, in Unity 6 URP lastest version, this setting cannot be found anywhere.
It looks like it is evaluating the SH probes per vertex…
I literally looked at every option available with no luck.
You can quickly find your pipeline asset by going to your quality settings.
inspecting that you will find the lighting section, you may need to hit the three dot menu to enable advanced settings.
Then at the bottom of lighting you’ll find the settings I pointed out.
@sacb0y Damn dude! Spot on!
What the hell, its so hidden lol…
Ok that fixed the issue! Thanks a lot its looking the way it should now!
Man why having things so hidden blow my mind.
yeah I’m not sure why they hide that setting, I do understand for like android it makes sense but it just look weird. To me it’s just a low settings thing.
Finally taking a look at the API 
I copy-pasted the example code and had to add bool bakeProbeOcclusion to Initialize as well as to define the occlusion property for it to compile. I’m glad the occlusion probe values are now writable!
LightingBaker/SkyOcclusionBaker APIs are nice, I had no problem with these. I managed to compute my own SHs/light occlusion/sky occlusion.
However, things get weirder when trying to configure bake settings. How do you set a baking set? How do you add scenes to a baking set? I managed to do it via reflection, but it could be better.
Baking Sets in general seem like a needless complication. And I gave up tweaking the scene list, because, for reasons unknown, I often get “Assertion failed” from BakeAsync after touching it. Even worse, there’s no stack trace to explain where it failed, and BakeAsync returns true. After it fails, it also breaks URP completely, and I have to reload domain to fix it…
BakingSet also takes scene GUIDs when adding/removing, but there’s no public guid API to get it in the same format (only internal property).
TryAddScene API is also confusing… why try? Why does it fail? What should I call to actually add it?
I also got “Trying to load Adaptive Probe Volumes data bakedwith an older incompatible version of APV. Please rebake your data.” once after creating my BakingSet from code…
Baking Sets being separate assets, yet having to reference mutually exclusive scenes generally seems to lead to many bugs if there’s a collision. I’ve found everything to work much smoother if I just delete all Baking Set assets in my project and keep one…
Now I see that apparently TryAddScene fails if this scene is already added to another asset… so to bake a scene, I have to modify existing assets in the project that I possibly didn’t create. This design decision is very questionable…
I also get a NullRef randomly from RemovePendingScene() when trying to set a Baking Set.
it would be much nicer if one could just supply a list of scenes and a settings structure to BakeAsync.
How do you set a baking set?
ProbeReferenceVolume.SetActiveBakingSet()
How do you add scenes to a baking set?
ProbeVolumeBakingSet.TryAddScene, ProbeVolumeBakingSet.RemoveScene
BakingSet also takes scene GUIDs when adding/removing, but there’s no public guid API to get it in the same format (only internal property).
I think this should work:
AssetDatabase.AssetPathToGUID(AssetDatabase.GetAssetPath(scene))
I also got “Trying to load Adaptive Probe Volumes data bakedwith an older incompatible version of APV. Please rebake your data.” once after creating my BakingSet from code…
Check the code in ProbeVolumeBakingSet.SetDefaults()… this should probably be public. You need something like that.
I agree in general that the design of baking sets is a bit… undercooked. Thanks for the feedback and for pointing out these issues. I’d like to rework them a bit in the future to make them more flexible, and to incorporate more kinds of lighting, rather than them being an APV-specific thing. I can’t give an ETA, though. FWIW, most of your complaints about the design are tracked internally.
Programmatic baking / customizing the baking process haven’t been high priority use cases thus far, so it doesn’t surprise me much that you are running into issues.
For the issues you’ve listed that are straight up bugs, such as the silent failures or random nullrefs, I urge you to file a bug report or at least post clear repro steps, so we can investigate.
Thanks for the reply!
Ah, nice. I guess I didn’t fully understand what ProbeReferenceVolume is. The docs say “it defines the structure in which volume assets are loaded into”, but its unclear what does it “own” compared to the AdaptiveProbeVolumes class. Like, it’s not really a “volume”, but a global manager of all volumes (?). Perhaps the naming confuses me.
Is this the expected workflow to add a scene?
(could it be improved?)
Yeah, that’ll also work, thanks.
For now I’m not 100% sure if they were caused by an odd combination of events using the proper workflow, or if I used the API incorrectly. But I’ll report if there is a guaranteed error I can reproduce only using proper public APIs.
I guess I didn’t fully understand what ProbeReferenceVolume is
Yeah the naming isn’t great. ProbeReferenceVolume is the main singleton that manages the runtime aspect of the system. AdaptiveProbeVolumes contains the in-editor baking logic and is mostly just static functions. Unfortunately their responsibilities are a little bit intertwined in some places.
Is this the expected workflow to add a scene?
I think that’s more or less how you’d have to do it if using only public API. To be honest, the use case of programmatically manipulating baking sets is evidently not very well fleshed out yet. You might want to take a look at ProbeVolumeBakingSet.MoveSceneToBakingSet. It’s internal but might still be of interest to you. It also shows the way to get the baking set for a scene without scanning everything, but that too is internal API.
I’m going to put an item in our backlog to enable the usecase of programmatic baking set manipulation in a less inane way.
I checked it before, and it uses GetBakingSetForScene, which is in turn just a dictionary lookup from sceneToBakingSet, which in turn is filled in SyncBakingSets(), which in turn… just scans the whole project As I’m creating a new set, I’d have to re-sync it again anyway.
Found the cause of my mystery issue: turns out, you can’t use EditorUtility.CopySerialized on the Baking Sets (even if you remove all scenes from them before overwriting them). Somehow it completely breaks ProbeReferenceVolume and consequentially rendering. I can copy values one by one, but perhaps CopySerialized incompatibility should be mentioned somewhere (at least in this post for future googlers…).
I also found you can’t bake APVs with approximately < 0.5 Min Probe Spacing.
Trying to bake Sponza with 0.2 spacing (Progressive GPU) results in this:
Today I also tried it with my own baker and 0.15 Spacing, got similar results:
The baking itself is fine, but when it gets to FinalizeCells, it spams these to console:
Thread group count is above the maximum allowed limit. Maximum allowed thread group count is 65535.
It looks like it’s doing some compute work after the bake and fails trying to spawn too many thread groups.
Not sure, but ProbeBrickPool uploader could be related:
If you want probe spacing that dense it probably needs to be very localized. I only use .5 min, but it’s in very specific areas.
Doing more increases memory a ton, and yeah I think breaks things a bit.
If you make some volumes just around the pillars for example, and have a higher probe spacing elsewhere it will likely work much better.
Makes sense, but I think it should then prevent you from attempting the bake it cannot use (or run that compute multiple times for smaller amounts). I’m just stress-testing. If I’m going to provide a custom baker, people will blame me for any unexpected results
