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

Hi everyone,

Welcome to the Probe Volume discussion thread. You can use this thread to ask for help, share feedback, and have discussions about this new experimental feature available for HDRP in 2021.2.



Introduction

We are happy to release in Unity 2021.2 our first experimental version of our future light probe system for Scriptable Render Pipelines.

The goal for this new system is to simplify workflows, improve visual quality, and in the future offer new features for global illumination.

Resources

For more information, please have a look at our documentation (work in progress) and these “Quickstart” slides to get an overview.

Getting started

1. Download Unity 2021.2.9 or newer through the Hub.
2. Create a new HDRP Project, using one of the provided HDRP templates, for example, 3D (HDRP) or 3D Sample Scene (HDRP)
3. Enable this experimental feature in your HDRP settings, following the instructions in the documentation (WIP)
4. Create a probe volume GameObjects (GameObject > Light > Probe Volume)
5. Set lights General Mode to mixed
6. Set dynamic objects to Receive Global Illumination from Light Probes and small & mid-size static objects that would influence GI to Contribute Global Illumination
7. Open the Probe Volumes Settings panel (Window > Rendering > Probe Volume Settings) and click on Generate Lighting.

Current state

In this first experimental release, we focused in particular on:

• HDRP support
• Volume-based automatic placement
• Per-pixel lighting of dynamic objects
• Multi-scene workflows: probes stored and loaded per scene + baking sets to manage multi-scene baking

What to not expect in this version:

• Light probes variants management (e.g., baking and blending different lighting setups)
• Use probe volumes to light an entire environment without lightmaps
• Use probe volumes with dynamic lighting or dynamic environments

What you will be able to get with this system:

• Easy probe placement: Choose a default global probe volume, or place your own probe volumes, tweak parameters to optimize the probe density for your needs.
• Faster iteration time, since light probes don’t need to be tweaked when moving objects like walls.
• Improved dynamic objects indirect lighting visual quality: Your objects are now affected per pixel by the probes, allowing for example one side to be lit by the indirect bounce of a red wall next to it and the other side by a green wall.
• Per pixel lighting also allows to reduce the number of small and medium objects lit by lightmaps and hence decrease baking time.
• Improved screen space global illumination: SSGI can use light probes as a fallback when raymarching is bouncing out of screen space.
• Improved volumetric fog visual quality with probe volumes sampling for more realistic lighting
• Improved additive scenes scenarios: Use Scene Sets to bake probe volumes across multiple scenes and load or unload individual scenes at runtime with their probe volumes attached to them.
• Flexible runtime visual quality settings: Use Probe volumes overrides
• Easy debug: Various debug modes are available in the Probe volume window

Design limitations:

• Baking sets are mutually exclusive: scenes cannot be shared across multiple baking sets.

What’s next

Next steps:

• URP support (no plan for Built-in Render Pipeline. URP will come after the first round of user feedback gathering, not before 22.2)
• Improve stability
• Improve UX
• Improve visual quality (light leaking)
• Probes variants management
• Probe blending for time of day scenarios

Other possible future improvements:

• Probe LODs
• Probe disk streaming
• Probe GPU streaming
• Tools to bake different variants of probe volumes
• Tools to switch probe volumes in real-time (requires coding at the moment)
• Debug rendering in the player (only Editor debug tools at the moment)
• Support for additional data (e.g., sky occlusion)

Feedback

In terms of feedback, we’re open to any feedback. Just keep in mind that the goal is not to replace lightmaps.

Please share your feedback in this thread.

To help us prioritize, you can also share the value, importance, and usage of this feature for you and your projects on our public roadmap portal (either through the Global Illumination card, or through the HDRP card if specific to HDRP)

How to report bugs

Ideally, we’d like any bugs reported through the built-in bug reporter tool, as that will automatically provide us with some relevant context.

When reporting bugs, please look at this page for more information and best practices around bug reporting.

Once you have submitted a bug report through the bug reporter, please feel free to start discussing it in this thread.


We hope you will enjoy playing with this new tech, and please share with us your feedback on workflows, UX, and expectations around such a system. Remember, this is experimental and by nature subject to change based on our users’ feedback. We are not recommending using this system in production. Doing so will be at your own risk.


The Graphics dev team

 

@Jes28 Could you give more details on how and when the light probe system breaks batches?

 

Mostly probes will incur into problems that lightmaps don't have, such as for example leaking. If you are OK with the leaking that system let through (in 21.2 there is no explicit mechanism outside of biases, in 22.2 onwards there are some mechanism that can help to a certain extent but not completely) then by all means you can! It is just not the suggested workflow at the moment

 

The new System does not tie up probes with objects so it should work just fine

 

Hey,

Unfortunately the lighting data is not stored in the probe volume themselves, those are just markers to tell the algorithm where to place the probes; once the placement is done, the probe volumes are not used in any way and moving them will not change where the probes are. To make it a bit shorter, we don't current support "relatively static" geometry cases, but only purely static ones.

The probe data lives with the scene and it is only defined by their own spatial position and tied to a specific object/component.

Unfortunately we don't have anything out of the box for your use case, we might have something planned for later on, but it is not even in its infancy of the plan phase, so cannot comment on if or when we will address such situation.

Unless I misunderstood what's going on

 

The plan up until 22.2 are focused on baked data for the time being.

 

The placement needs to be with regular grids unfortunately, in 21.2 you can use view and normal biases to combat some of the issues (Can find those in advanced settings of the Probe Volume Options volume component).

In 22.2 there is an option that relies on probe validity to try and stop a bit the leaking and a tool to allow to manually invalidate probes so that they will try and contribute less in situations when leaking might happen.

 

Not planned for the 22 release cycle, as for the future, undefined yet Depends on many factors that are still not well defined.

 

Not known, the probes are gone or the probe volume components? Can you please file a bug?

 

A bug report would be surely appreciated, thank you!

 

@jjejj87 Sorry if my description was not clear.

It is an entirely new probe system, but it currently uses the same baking backend as light probes and lightmaps, and the data is still stored per scene.

So it is not just a new placement tool on top of existing probes.

The goal is to build a structure which is future proof, but we need to go there step by step.

The first steps are (21.2):
- simplifying placement by using volumes in which probes will adapt automatically to the geometry.
- improving visual quality with
—per pixel lighting, allowing less static objects like medium size rocks to be light mapped (and hence improved baking time and iteration time) and better visual quality on dynamic objects.
— Volumetric fog affected by probes.
— Some Ray marching algorithm (Eg: SSGI) falling back on probes when hitting outside screen space
- improving additive scenes scenarios

Now, we are focusing on stabilization, reducing light leaking, improving UX, supporting probe blending for time of day scenarios, and will work on URP support (not planned for 22.2).

There are many possibilities for the future as mentioned above, but the above steps need to be tackled successfully first before adding more features.

 

I am not sure about the details of terrain tree implementation, but I am going to ask internally, hopefully will come up with a proper answer soon!

At the moment unfortunately APV baking is only seeing whatever the lightmapper sees as the baking go still through it.

The per-renderer normal bias is unfortunately something we cannot do as we can't afford to put more data in our GBuffer.

The parameter being on a Volume component could maybe give you some control, although I 100% understand is not the same thing as it'd be more camera dependent than per-object.

 

The feature is still in expertimental so API is bound to change.

Anything specific you are looking for for which I can give you an update with current status?

 

This looks like a case of leaking. How to go about it depends on your setup and package version; you can start trying changing the bias settings.

 

HAS_PAYLOAD_WITH_UNINIT_GI is an example of something that went away (for unrelated unfortunate reasons).

It is already part of master! You can bake different states of the lighting and change them. A way to blend them is also coming.

I understand, unfortunately it is not something we have planned as it would have very big implications on the whole pipeline; I'll keep the feedback in mind though.

I have been asked to double check that the prefab used for the terrain trees are setup to contribute GI

 

Thank you for the positive feedback too!

Regarding this last point, is it perpetually stalled it is just a matter of very long bake times? What package version are you on?

 

Do you have dilation and virtual offset enabled in the baking window? It could also be very severe ringing. What do the probes look like around that area? (Can use the display probe option in the debug menu)