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

  • Download Unity 2021.2.9 or newer through the Hub.
  • Create a new HDRP Project, using one of the provided HDRP templates, for example, 3D (HDRP) or 3D Sample Scene (HDRP)
  • Enable this experimental feature in your HDRP settings, following the instructions in the documentation (WIP)
  • Create a probe volume GameObjects (GameObject > Light > Probe Volume)
  • Set lights General Mode to mixed
  • Set dynamic objects to Receive Global Illumination from Light Probes and small & mid-size static objects that would influence GI to Contribute Global Illumination
  • 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

21 Likes

Hi

Thanks for sharing
Will new probe system break batches like old one?

2 Likes

Thx for hard working.
just wonder will it be good for open world game.
very excited for “Probe blending for time of day scenarios” and “Sky Occlusion Data”.

3 Likes

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

I do wonder what prevents us from using these probes instead of lightmaps to light the environment.

1 Like

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

1 Like

See this
https://discussions.unity.com/t/804071

[ATTACH=full]1005850[/ATTACH]

7897438--1005850--upload_2022-2-15_7-22-25.png

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

2 Likes

Will runtime mode come in later for dynamic scenes changing all the time in unpredictable manner? Like procedural worlds/planets? or is it still better to just bet on custom DDGI solution for scenarios like this? Full SSGI is just too much overhead.

7 Likes

Hello,

Thanks so much for this feature. It is already proving to be a really great workflow improvement.

I’m super appreciative that multi-scene workflow functions fine, but we are having a slight issue because of how we are specifically using multiple scenes. When we instantiate additive scenes at runtime, we move the contents of the scenes. This seems break the baked probe volume. Is this expected? Is there a correct way to move the volume at runtime?

Thanks,
Chris

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 :smile:

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

1 Like

How can we battle leaking with PV?

How do we place PV when we have irregular, non-boxed environment?

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.

Any chances for runtime baking/rebaking/probe placement features in the 22 release cycle? Or maybe baking/probe placement outside of the editor is not planned/considered at all?

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

Okay thanks a lot, I thought that might be the case. This will probably be a pretty common use case for people using multiple scenes, where rarely they are instantiated in the same place they are authored, so I’m hopeful it might get solved one day :slight_smile:

Thanks a lot,
Chris

I found that probe volume are randomly gone on play mode in latest beta, i take it this is a known issue?

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

This how it happened, it’s like the probe volume data totally gone after pressing play and i have to rebake the gi. Except the terrain any other object are using APV
If this is not a known issue i’ll make a repro and file a bug report
t33gj6

Edit: Oh i think i know what causing it, “Play Mode Options” if i turn it on APV data always get disconnected from the scene.