Fix: Use the auxiliary entity (associated camera view)’s position via ViewUniform for gpu visibility range culling

[kfc35]

Note: a newer alternate PR using immediates is here: #24197. Decisions made between the two PR’s can be mixed and matched, just let me know.

Objective

• Fixes Shadows disappear abruptly in visibility range example #23991

Solution

• Store the render entity for the auxiliary entity (represents a regular viewing camera for directional lights). Use it to query for the auxiliary entity’s world position when it’s time to build the ViewUniform, which will be used for visibility range culling.
• Added bitflags to the ViewUniform to ensure that ExtractedViews for entities that aren’t also ExtractedCameras and do not have auxiliary entities are not used for visibility range culling. Such ExtractedViews should only be Point and Spot lights.

Note

As a consequence, if meshes have NoCpuCulling, have a VisibilityRange defined, and are being illuminated by a Point or Spot light, their shadows currently won’t disappear if an ExtractedCamera goes outside the meshes visibility range! I am looking for guidance on what to do in this case…

• Note: Regular cameras have their position data duplicated in both world_position and primary_world_position.

I actually do not know if this is the best way to send information to the gpu; I just tacked stuff onto ViewUniform. If there is a different, more preferred way to do this work, you’ll have to give me some guidance as I’m not too experienced with rendering!

NOTE: There’s also code that touches calculating the dithering level that I haven’t touched in the wgsl. Let me know if that should be changed too….

If anyone wants text on me explaining what the concrete changes are and why I did them, or just a different wording: https://discord.com/channels/691052431525675048/743663924229963868/1501630877082325062

Testing

• cargo run --example visibility_range -- --no-cpu-culling works as desired without shadows popping in and out
• cargo run --example visibility_range works as desired without shadows popping in and out
• checked cargo run --example spotlight and cargo run --example async_channel_pattern for regressions; they seem fine.

[Br3nnabee]

Just a learning question if you wouldn't mind: Why do directional light shadow views need to cull based on the camera's world position rather than the light's position?

[kfc35]

Just a learning question if you wouldn't mind: Why do directional light shadow views need to cull based on the camera's world position rather than the light's position?

I don’t mind at all!

As far as I understand, visibility ranges are only meant to define distances at which meshes start to fade out from view / fade into view when viewed from a user defined camera, as opposed to a shadow camera. This is specifically about visibility range culling as opposed to the more general frustum culling, even though the logic is in the same block in the wgsl file.

In the specific example for visibility_rangeon main, you can observe the results of the existing behavior (where it doesn’t use the user defined camera). When the user moves their camera at certain angles at distances, the shadow starts to cull even though the object hasn’t. I don’t know much about shadow cameras (I’ve really only dove into this part of the code within the past few weeks!), but I assume it’s because the distance from the shadow camera is not within the visibility range of the shadow, which shows up as premature fading on the user camera. The mesh and its shadow also end up using two different cameras to do visibility range culling instead of the same user camera, which means the mesh and shadow could end up disappearing/reappearing at different times.

[kfc35]

@pcwalton just review requesting you since i think you might be most familiar with the things this code is touching / have strong opinions. please look whenever most convenient for you!

[kfc35]

I opened an alternate solution to the bug as #24197

[kfc35]

closing this since we will most likely go the way of the revert

people also weren’t really fond of this option anyway!