Fix: Use auxiliary entity (reg view camera) for gpu visibility range culling if defined

[kfc35]

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: 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….

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.