Skip to content

Conversation

@pcwalton
Copy link
Contributor

Currently, if a fragment overlaps multiple reflection probes and/or irradiance volumes, Bevy arbitrarily chooses one to provide diffuse and/or specular light. This is unsightly. The standard approach is to accumulate radiance and irradiance as a weighted sum. In most engines, light probes have an artist-controllable falloff range, which causes the weight of each probe to diminish gradually from the center of the probe.

This PR implements both falloff and blending for light probes. Reflection probes and irradiance volumes are blended using a weighted sum. In the case of reflection probes, if the weights sum to less than 1.0, and an environment map is present on the camera, than the environment map receives the remaining weight necessary to bring the total weight up to 1.0. This is useful for reflection probes that correspond to building interiors, to allow smooth transitions between the indoor building and an exterior environment map when exiting the building.

Falloff is specified as a fraction of the interior of each light probe that applies gradual falloff, instead of specifying a distance outside the light probe over which the influence diminishes. (See the documentation comments in LightProbe for more detail.) The reason why I chose to do it this way is that the voxel contents of an irradiance volume would be ill-defined within the falloff range otherwise. Clamping to the edge of the 3D voxel cube inside the falloff region (i.e. extending the edge voxels out) is likely to be incorrect, and extending the voxel region to encompass the falloff range plus the interior range would complicate the calculations in the performance-critical PBR shader.

This needs an example, so it's a draft for now.

Currently, if a fragment overlaps multiple reflection probes and/or
irradiance volumes, Bevy arbitrarily chooses one to provide diffuse
and/or specular light. This is unsightly. The standard approach is to
accumulate radiance and irradiance as a weighted sum. In most engines,
light probes have an artist-controllable *falloff* range, which causes
the weight of each probe to diminish gradually from the center of the
probe.

This PR implements both falloff and blending for light probes.
Reflection probes and irradiance volumes are blended using a weighted
sum. In the case of reflection probes, if the weights sum to less than
1.0, and an environment map is present on the camera, than the
environment map receives the remaining weight necessary to bring the
total weight up to 1.0. This is useful for reflection probes that
correspond to building interiors, to allow smooth transitions between
the indoor building and an exterior environment map when exiting the
building.

Falloff is specified as a fraction of the *interior* of each light probe
that applies gradual falloff, instead of specifying a distance *outside*
the light probe over which the influence diminishes. (See the
documentation comments in `LightProbe` for more detail.) The reason why
I chose to do it this way is that the voxel contents of an irradiance
volume would be ill-defined within the falloff range otherwise. Clamping
to the edge of the 3D voxel cube inside the falloff region (i.e.
extending the edge voxels out) is likely to be incorrect, and extending
the voxel region to encompass the falloff range plus the interior range
would complicate the calculations in the performance-critical PBR shader.

TODO: talk about the new example.
@alice-i-cecile alice-i-cecile added A-Rendering Drawing game state to the screen S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged C-Refinement Improves output quality, without fixing a clear bug or adding new functionality. labels Jan 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Rendering Drawing game state to the screen C-Refinement Improves output quality, without fixing a clear bug or adding new functionality. S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

2 participants