Skip to content

Improved coverage estimation for SpotLight3D #107993

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

AndrewB330
Copy link

@AndrewB330 AndrewB330 commented Jun 25, 2025

Problem:
When using SpotLight3D I noticed that engine often picks subdivision quadrant from the atlas that is too small and shadows look blocky and flicker too much. This is noticeable when the beam is narrow and the camera is looking in the direction almost parallel to the beam, then current estimation code will return a very low coverage number for this scenario, while spot light in fact can fill entire screen and have almost 100% coverage. I think the original code assumes that objects are always placed at the very end of the range of SpotLight3D, which is not always the case.

Solution:
The simple solution I came up with is to add one more point for estimating coverage - point that is on the main axis of the SpotLight3D and is closest to the camera. This greatly improves estimate for coverage when the beam is narrow. Here is the drawing to explain it:
image
Corner case explanation: when point happens to be behind the camera we are basically performing an orthogonal projection (same as before) because of the code: points[j].z = -zn, so that estimate still works well.

And a few real examples to compare.
Old estimate (you can see how shadow switches between different resolutions):
AnimationOld
New estimate:
AnimationNew

Important to note, that for wider beams this change will keep their behavior, as for wider beams the diameter at the base of the cone is going to be the largest estimate anyways. And of course this is just an estimate, proper evaluation of coverage area would require much more computations.

@AndrewB330 AndrewB330 requested a review from a team as a code owner June 25, 2025 23:42
@BlueCube3310 BlueCube3310 modified the milestone: 4.x Jun 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants