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

Where is the "Normalize Reflection Probe" option?
i have never seen this thing in unity...

Edited:
Never mind i found it.
it's under the HDRP Globe Settings - > Frame Settings -> camera - > Lighting - >Probe Volume.

But i didn't find it is working as what i expected, everything is still very shiny in the dark area...
i will do more research.

 

Thanks for the reply! I don't think I am using different assets, but admittedly I'm not 100% sure what you are referring to. The only way I saw how I could use different HDRP assets would be in the quality overrides, is that what you mean? If so, I don't have any overrides there.

 

Hello

I was able to produce a simple repro of this situation that occurs both in the player and editor:

• Create a new HDRP project
• Enable Probe Volumes
• In the sample scene:
  • Disable Directional Light
  • Create Sky Volume as show in the screenshot
  • Disable baked lighting
  • Create cube
• You can see the cube is black, doesn't seem to be using the ambient light from the sky
• Disable light probes in the Quality UI as shown in the screenshot
• You can see the cube is now being lit by the ambient light

Before I submit a bug, just wanted to confirm that I'm not missing something obvious. I tried this simple project on a number of versions from 2021.2.18 to 2022.1.0b15.

 

It would be great, if probe volumes will not be bound to scenes and would work like reflection probes now, where you can bake them and use later in any scene and any place. It is very useful for games, that consist from premade rooms, that are procedurally placed.
The only way to do something like this right now was described in this talk: https://m.youtube.com/watch?v=KbxiGH6igBk

 

I still hope that runtime generated/modified scenes, dynamic geometry and dynamic lighting support are long term goals for APV so the system can be used as a full scope real-time GI solution in the future.

 

I'm getting great results so far from APVs in multiple scenarios, but is it normal behaviour for the exposure of material ball preview in inspector to become really blown out? It's happening in all the projects I've enabled and baked APVs and can't seem to correct it?

 

This feature works fantastic with vegetation! Looks amazingly good. Hopefully support for the terrain will come soon!

 

Hello,

We are currently using APV but have noticed on some machines (about 50% of our developers), probe volumes leaking significantly (many GB) until Unity crashes.

We have tried 2021.3.1f1, 2021.3.0f1 and 2021.2.11f1.

The issue seems to be ProbeReferenceVolume LoadPendingCells creating a texture3d (line 1033), then returning at line 1058 without removing the loading cell, which causes it to be loaded again, then another texture3d created etc. I have also noticed visually that streaming of probes often fails in strange ways, and gets stuck not loading further probes.

I have not yet investigated deeper into why this sometimes fails, but I'll hopefully find the time to do so.

Our scene is quite simple. A few hundred meshes, sparsely placed in a 1000x1000x1000 volume.

This has made APV quite unusable for us.

Thanks,
Chris

 

I have been trying to make a minimal repro (I know its what you'll want ), and honestly, its quite difficult.

The issue doesn't happen on all of our computers, and we have encountered some tests where when we delete the ProbeVolumeData.asset file, the problem is solved (as expected), but adding the file back does not reintroduce the leak. It seems to be very difficult to reliable reproduce

 

Thanks so much for the fast reply.

I'll test 22.2 ASAP and let you know how it goes

 

Thanks so much

 

I have a question
If we can bake apv's at runtime, cant we in theory get all nearby probes of a light that moved, stagger the bake over several frames and thus get dynamic gi ?

 

But in theory my suggestion could work right? Is it possible to expose some sort of API so we can do our own baking implementation ?

 

Hey that looks handsome

 

@francescoc_unity

Does APV can be moved at runtime? Could it be used to bake prefabs? (think about a semi-procedural dungeon where rooms are prefabs).
If it's still linked to scene, I hope you seriously consider decoupling this. It's already a pain that lightmaps are linked to scene, and decoupling lighting data from scene (Bake Prefabs) is under consideration by Unity to fix that, so better to prepare this to work with this feature. With APV locked to scene only, there would still be no way to natively support a randomized environment in Unity, and decoupling lighting data from scene would be useless without a solution for dynamic lighting.

 

Hi,
I'm going to ask since it's sort of new technology and I'm a little confused: I understand that APV does work as an "automated" probe solution and do work with lightimapping in mind, but is it possible to setup them in a way to achieve a realtime GI solution? I mean, imagine having an interior map, is it possible to make walls and floors lit just by APV and have the probes update in realtime to achieve day/night cycles etc?

Thanks in advance

EDIT: after looking a bit around, I think the answer it's no!

 

@francescoc_unity
Not sure if this a bug or not, when the sun are under the horizon the baked APV result are so bright. This is happened at sunset and sunrise time

 

I don't understand the issue. Why we could not move them at runtime? There is obviously an array of volume and/or probe position somewhere that we could probably change at runtime. What the point of considering backing prefabs in the future if there is no solution to light dynamic objects? We need volume to be attached to prefabs directly.

We are now in 2022 and there is still no solution to move light probes, being locked behind this LightingData black box linked to scene. How many years we need to wait before this basic functionality will be available? When Unity will support randomized worlds without having the need to use extremely costly realtime lighting or create our own workaround lighting solution?
I'm sorry for the rant but I don't get why Unity insist to lock all lighting solutions to be static. It's archaic and not future proof considering prefabs baking. I hope you will seriously reconsider this before it's too late.

 

Hello,

Is there an edit time scriptable way to bake the APV data? We currently use Lightmapping.Bake to generate lighting data for our scenes during build, but as I understand it, this is not the same as "Generate Lighting" in the probe volume settings window.

Thanks,
Chris

 

Hi,i noticed that in Unity2022.2.a13 when you switch Light Probe System to APVs in HDRP quality settings,you will lose the ambient occlusion on the materials with non-black Emissive Color.
the ambient occlusion i mean is the mask map based one in materials, not the screen space one.

is this a known issue or i have broken Unity again...?

 

When will full features of APV come out? Will 2022.2 beta come soon?

 

Are those features are the current features that exist in alpha? or there's more to come?

Regarding workflow i do hope it will be improved, baking light scenarios are bit a chore currently. Especially when light scenarios are tied to time of day or scene configuration

 

Fantastic thanks so much, everything just works

 

Im still confused about the concept

So the APVs are an upgrade to light probes
But do I still need to bake lightmaps? Or can the Probes replace the lightmapping?
In the enemies demo there was no lightmapping done I read(?), so this implies I can light my scenes with these without any lightmap UV setups mesh independent?

(Playing with it but haven't got it to work yet)

 

You can use both, but if you don't want to use lightmap, change the contribute gi settings to lightprobe instead of lightmap for the static object

 

I had APVs cause this issue across all my scenes, restart did not fix, I reverted my git
cant say much to this, just leaving it here

Haven't got it to work yet but only tried for one hour so far

 

Hi all. I'm interested in not baking any lightmaps at all (I don't want to use them). In Horizon Zero Dawn (2016) they use something like APV that Natalya invented for the Ruby tech demos way back when. I was wondering if these would satisfy the use case of improving indirect and AO for open world / Time of day games in the scenario I mentioned.

The key here is that it works on static as well as dynamic geo, and replaced lightmaps which aren't a good idea for the world size I have in mind.

Or am I barking up the wrong volume?

What about origin shifting? This is something I am doing in DOTS/Entities, and it seems like a trivial offset for your data?

(Also, I hope to use it on URP eventually)

 

That's what APV tryring to do isn't? and about AO you mean this one https://portal.productboard.com/8ufdwj59ehtmsvxenjumxo82/c/1248-bake-sky-occlusion
i'm not sure about that roadmap if it's will be part of APV or not though

 

No, I'm just making sure it doesn't lean on lightmaps and works on static geometry. I guess being stuck on 2020 is no fun! Hope entities 0.51 comes soon.

 

Would love a no bake workflow.

For APVs you potentially could use it for TODs, but you'd still have to create a few different profiles for it for specific times of days and the lerp between them, similar to reflection probes in that essence.

With your capability in general you'd probably be able to extend what's already there for that, but I think dynamic TOD and massive worlds will still have a lot of memory use for it.

I think many are looking for it as it tends to complete the external scene look and feel really well.

Either in the limited documentation for this or the op, I believe it was mentioned "not for true dynamic TOD" hence the aforementioned lerp between "sets" I think it's called in the tool.


Similar to a 2 ref probe with time slicing (2022) set up for dynamic TOD I do generally hope that this can completely that particular workflow.

Being backdated to 2020 or patching it though, I'm not sure.

Are you currently version locked because of DOTS with ECS support?

 

Yep, I will be moving to 2021 when 0.51 is out and 2022 when 1.0 comes. I'm committed to getting to DOTS 1.0, whatever version of Unity that might be.

The lerp stuff sounds about right to me. It seems Unity MUST know what most people really will use it for (game scenarios outdoors and inside mixed). So I think my strategy might be something like baking reflection probes once but relighting them by normals + APV for large scale spaces - I might have it cover a large area to reduce memory pressure. Close up details? Honestly I think I'll have to use some hacks and lean on local reflection probes to patch up lighting issues. Open to thoughts really.

But I think we're reaching a time when Unity *finally* has the potential to handle something like Horizon Zero Dawn from 2016 - but with more expensive than necessary techniques to get there. So probably won't be anywhere close as optimised, but that's something I can live with as I can't afford to reinvent the whole wheel.

 

I do agree with you there. Unity tends to be on the quiet side with open worlds generally and focuses more on the inside environments following the "typical" lighting and baking scenarios.
The end results of that, are absolutely fantastic for high fidelity.

APV is definitely the next step for that particular workflow,
simplifying the light probe workflow and more.

But it absolutely has the potential to fill that open-world void for visual fidelity and with hope dynamic scenes. if it's not out of scope for them.

in terms of high fidelity details on close up objects, i think you're right, for large worlds in this kind of workflow, i'd say you'd just have to balance between dynamic environments<->probe accuracy.

I'd definitely sacrifice some close up reflection accuracy if it meant I could have dynamic tod, larger maps and APVs

The step-up with 2 probes lerping with APV and SSGI alone is ( well heavy) but for open scenes, really does some justice IMO, even if you just wanted to prototype like that, it's still a very fast workflow

 

It's a worry that Enemies needed a 3090 ti job to get to 30fps, but maybe that's just because of SSGI. In any case, completely unrealistic expectation for a game. Even AAA only have a small % of customers that can afford that. If we could get to a place where a game could run on PS4 Pro hardware, at 30fps 1080p pre upscale, that would be a brilliant place to start and grow upward from.

I mean it's generous. AAA games all still sell on that platform and work fine. It's hardly a switch. Why not Unity's?

My ideal world is getting to a position where I could *render* a game with loads roughly like Horizon from 2016, in 2022. It's not completely bizarre for me to expect a game engine to have evolved to that point 6 years after that game's launch. Or is it?

I even am willing to push the min spec higher too. But it illustrates the gap between real perf and open world problem solving and the reality of Unity today.

 

It's very likely because of DXR and DX12 (which is still not as performant as DX11), and also SSGI. APV is not very resource heavy compared to the beforementioned stuff.

 

It'd be interesting to test the 1 2 3 and console cards with enemies tbh.

We often test on a 1070ti 2070 super and 3070ti, arguably I'd say most gamer density is still on 1 or 2 series Nvidia cards ( I can't speak for AMD)

I don't know if you saw any of the in engine stuff in enemies, but as far as editor performance, it was pretty snappy, hair physics and all running. But yeah absolutely pushing the max for sure.

We've definitely had some next gen console surprises that were unexpected performance wise when benchmarking with limited third party solutions present.

I know Pierre mentioned the amount of precomputed efforts going into red dead 2 was absolutely massive.

But it's certainly the fact that large world's, need a massive amount of TLC to be able to get to HZD/RDR levels.

Id assume hippo, that you're using DOTS and ECS for both streaming and vegetation management, which are massive hurdles for sure.
Add TOD on there with runtime updates I think unity just starts to hang back visually in favour of taken more performant routes instead.
Hence why there's never a large world showcase ( HDRP URP terrain samples are a very minimal count imo)

I feel even higher spec cards run into the same performance issues with larger worlds.

I don't think it's farfetched at all to feel that unity is ready/close to ready to push it's large world scale at all.
I just think the workflow for fidelity at that scale is limited.

Unity would certainly be explosive if BoTD fidelity and performance could be met @~16ms at scale.

And I'm sure it can, just workflow


I think if we threw Virtual Texturing, Instancing indirect, batching Dots and ECS, asset bundles, streaming systems, better culling and ToD at scale we'd still very much struggle at that BoTD level, at least with vistas in mind.


But, don't give up supporting

 

Exactly why I'm targeting a well-documented resource like Horizon over something that required render farms (for authoring AND runtime perf). HZD 1 would not need render farms (for authoring today with that scope), just a 2070S, decent CPU by todays standards for the development side.

And bang for buck it's more realistic for us to target than something mind boggling like RDR2... and anyway, that's a level of realism far more than we could afford.

But yeah, everything is DOTS throughout. IMHO no choice (but that's for the runtime, not authoring).

 

What is minimum bottom GPU to use for APV in production?