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
fix: incorrect sprite size for aabb when sprite has rect and no custom_size #12738
fix: incorrect sprite size for aabb when sprite has rect and no custom_size #12738
Conversation
Out of interest is there any way to write or update a unit test to prove the existing bug and that this change fixes it? |
Sure I will add a unit test to it |
Here's some testing of this PR which I think shows that it fixes the issue as expected. I think it's worth someone eye-balling the results to check that they match their expectations, but they seem to AFAICT. In the original issue #12736 the reporter mentions anchor being "outside of the range -0.5..0.5", but per the results below the bug appears to exist with standard anchors (also, FWIW, does an anchor outside that coordinate system have undefined behavior or are they also valid?) Examples below run using Note Image is 256x256 With Bevy 5c3ae32 (more or less main due to #12935)Only setting an anchorCode
✅ ResultOnly setting a rectCode
❌ ResultAnchor and rectCode
❌ ResultWith the changes from this PROnly setting an anchor✅ ResultOnly setting a rect✅ ResultAnchor and rect✅ ResultAnchor outside of the range -0.5..0.5 and rect (to prove fix for original issue)Code
✅ Result |
@mgi388 I mentioned the range -0.5..0.5 because when it is outside that range there will be an area of the sprite that is outside of the aabb box. See this picture from running your last example on bevy 0.13.2. When the origin is in the range -0.5..0.5 the aabb box is just bigger then it should be, so it is being rendered when it doesn't have to. Thats probably why it didn't get noticed before since most people have the origin within the sprite. |
@MarcoMeijer makes sense. I probably should have added the "outside the range" test against Anyway, given my test results above, do all the results when the changes in your PR is applied look expected and correct to you? |
@mgi388 yep they look good to me |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good to me, I've tested it too, so giving an approval.
@alice-i-cecile would you be able to help direct this to the right reviewers? I picked this out and reviewed it myself because I was debugging |
@bugsweeper @lennart would the two of you be able to review this based on your work in #12769? <3 I'll take a look too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good little fix, and a nice regression test to match.
I think this problem weakly corelates to my work because my changes fixed problem based on sprite subdivision. But I confirm that bounds of sprite slices similary calculated using texture size, sprite.rect.size or custom_size, but in reverse order (because of using reassignment) for same priorities |
Objective
Fixes #12736
Solution
Use sprite rect to calculate sprite size for aabb when custom_size is None