Properly set size of shadow atlas quadrant when subdivision is 8 or higher. #91545
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: #89312
I still can't figure out why this seemingly regressed between dev1 and dev2. Both of these problems have been present for a long time.
Problem 1: Shadow atlas quadrant allocation
Each atlas stores shadows for up to subdivision * subdivision lights (omnilights count for 2). When we set the quadrant subdivisions we reserve enough space in the shadows array for that many lights. We use the length of this shadows array to validate how many shadows can go in each quadrant.
When we set the size of the atlas, we have to clear the quadrants and then resize them. But there we were reserving enough space for
1 << subdivision
lights. This is not always the same assubdivision * subdivision
! For the last quadrant, this led the system to think that it could store 256 shadows, when it really only had space for 64. So the 65th shadow would try to render outside the framebuffer and cause the error.Oddly enough I caught this bug in the OpenGL renderer when implementing shadows. I remember at the time noticing it, but not doing anything in the RD renderers because it wasn't causing any issues and I didn't have time to investigate why.
Problem 2: No validation for render pass rect size
draw_list_begin
is supposed to validate the size of the render pass rect. But it was missing a pair of parentheses, so instead of checking if the rect was fully inside the framebuffer. It checked if the rect began outside the framebuffer on the X-axis, but otherwise fit within the framebuffer. This bug has been present for a long time.Not every device crashed/froze despite us allowing values that should not have been allowed as different drivers handle breaking spec differently.