Very unlikely, unfortunately as APV is still an experimental feature we are not doing backports.
Does this work for realtime enlighten GI? As I saw lights must be set to âmixedâ.
No, enlighten remains a completely different system.
@francescoc_unity Any chance we can get somekind of probe placement preview before baking, either automated or on demand/manual update somekind of update probe placement button on Probe Volume component? having to bake the lighting just to see the probe placement kinda not intuitive
You can already do that!

Some times we observed that a bake never ever happened than the checkbox doesnât work, but we couldnât repro said behaviour. If you baked at least once (even after you clear or change things radically) it should always work.
Oooh i thought that only work with baked data. Thanks for the info!!! iâll test it out
Just test the alpha build, the blend function are nice. What is the best practice for day-night transition though?
Might gonna need a small example for that
blackandwhiteinnocentcuckoo
Itâs amazing!
does terrain support using APVs as indirect lighting in the alpha version?
We might produce samples later on, what the best practices are really depend on your content (how many keyframe you need/can afford for example).
Nice results btw!
Not landed yet, I will notify the thread when the PR lands in our system.
Thanks. Also having a small example could help i think.
It might be just my setup, but i find it hard to get a smooth transition from sunset > night time > sunrise.
Also i find if we keep calling this line everyframe it eating the fps a lot.
ProbeReferenceVolume.instance.BlendLightingScenario(TargetScenario, blendTime);
Might want to add this into the docs if itâs not exist yet, to remind people to call it on demand not everyframe.
Wow, thatâs surprisingly good! Howâs the process? Do you need to bake every lighting conditions and APV just blends between those?
Yeah you need to bake each of the Light Condition (in the APV term it called LightingScenario), then from script you need to define the current active scenario and which scenario to blend.
Iâm using this script for my test, heavily modified of course since iâm using more than 2 scenario.
https://github.com/Unity-Technologies/Graphics/blob/master/TestProjects/HDRP_RuntimeTests/Assets/Scenes/007-BasicAPV/LightScenario.cs
Note that being in alpha we donât consider the feature done
There is a bunch of improvement we already know that are about to land soon-ish.
But yes, weâll need a section in the docs for this too.
Are the light leaking pulls in the latest public alpha?
from my testing I can get pretty nice results with APV + SSGI. Would be a nice and welcome replacement for the regular lightmapping.
I had to mess with the bias quite a bit to get a correct look, which in itself leads to some slight issues, but all in all itâs looking promising ![]()
for me SSGI was a must for good visuals in alpha9, it helps a ton with noise/weird artifacts and better lighting.
The final issue Iâd like to mention is SSGI cost is quite high even at the lowest settings so I canât treat it as a universal solution for public projects. (APV+SSGI that is)
There should be a field in the Probe Volume options called Leak Reduction Mode, by default it is off (we are turning that On soon). I am not 100% sure it is in the latest alpha, but probably it is.
There should be also a Touchup volume, but before we write documentation Iâd steer away from those as they are double edged swords.
Note again that while said option + touchup volumes + biases can get you a fairly good result in some situations, there might be cases where leaking will still be visible â In such conditions either keep lightmaps (hopefully on less objects than before) or increase locally the density of probes and hopefully reduce organically the issue.
The usual recommendation stand (e.g. donât have paper thin walls, favour high density where you thing where leaking might occur, etc)
While APV can greatly help SSGI, SSGI itself (not the APV fallback) is maintained by different developer, I suggest writing SSGI feedback on the main HDRP forum so it can end up to the right eyes ![]()
Could you put that on by default? I mean there isnât any practice where you would want meshes to leak light.
As I wrote in parenthesis it will be on by default in the released version.
Keep in mind while it helps it doesnât fix all the issues (and is super rare cases might lead to undesired effects, tho that we observed rarely)
In 2022.2.0a9 and HDRP, I have a typical exterior architectural scene with only 2 buildings and some hard surface floors, paving, parking etc. (about 600m X 600m). No plants yet. 1 grey material applied to everything for now.
I set everything to static, however in each object, I DID NOT manually set it each objectâs âReceive Global Illuminationâ setting to Light Probes, instead, left it on Lightmaps. There are too many objects to manually switch this 1 by 1
We need a different mechanism to switch this setting, or some kind of editor script to change all selected objects (even if those objects are inside a hierachy)
Anyway, I thought the baking was suppose to be quick?!? In my Ryzen 9 5950X and RTX 3090, its estimating the scene will take 1 hour to bake on default settings. However, it keeps fluctuating between 40 min and 55 min, and the time doesnt get less, but seems more like increasingâŚ
Is this APV, meant to eventually be similar to Unrealâs Lumen system?
EDIT1: Now its already sitting on an estimated 3.5 hours!
EDIT2: It briefly jumped to 16 hours, now its on 4 hours
EDIT3: OK I geuss this is still way too experimental to even be attempted in an actual project sized test. Fine in a scene with 3 cubes, but any real project and seems dont bother for now.
EDIT4: Actually let me hide most obejcts and switch that receive gi setting to probe volume on a handfull of objects and see
Youâre probably just regular light mapping.
No.