Thin line in 9-sliced texture when sprite resolution is high #14183
Comments
Litttlefish
added
C-Bug
alice-i-cecile
added
A-UI
|
Running into the same issue. @Litttlefish did you find a workaround for it? |
nope, no idea why this happens |
|
Also running into the exact same issue after upgrading to 0.14.0. Smaller buttons using 9-slices have the lines as shown in the image. |
janhohenheim
added
the
C-Regression
|
Bisecting the issue, I think it's caused by the shader changes from #13523. It's reproducible in the Digging in more it looks like the fact I'm using a scale factor if 4 is important. It doesn't happen if I use 1 or 2. Finding #13814, I changed the aliasing in my local branch to be I'm wondering if we could have AA be a flag or something in that shader. My game has pixel art so I want to turn all AA off. |
|
I observe this in the examples rendered in WebGL on the bevyengine website:
At default UiScale, I also observe this with my own 9patch button on 0.14.1. It is even worse at higher UI scales. |
|
I noticed this same issue but worse in a non UI or sprite renderer. I noticed the resulting slices from the slicer can have a lot of precision this can easily result in errors like this. |
I did the same thing, except I changed the "0.5" to "1.0", as I think you need to double all terms in this calculation to change the AA threshold on the distance. This seemed to fix the problem, but I don't really know why. Maybe this change effectively disabled the anti-aliasing. To highlight the change at UI scale factor of 8: with "0.5" and "2.0" (the original values): with "1.0" and "4.0" (this is precisely how my button should look): I agree with @MScottMcBee, anti-aliasing is hard-coded to be enabled in bevy_ui, but probably shouldn't be? However, this form of anti-aliasing doesn't seem to be effective anyway, as the artifacts show for any scale or art style (not just pixel-art), so maybe it just needs correcting. |
|
This issue also applies to non 9-sliced textures In my game I have this issue with regular ui images that are close to each other: This issue was not there in 0.13 |
|
Ah, I saw something like this happen when my desktop scale was not 1.0. |
# Objective Fixes #14183 ## Solution Reimplement the UI texture atlas slicer using a shader. The problems with #14183 could be fixed more simply by hacking around with the coordinates and scaling but that way is very fragile and might get broken again the next time we make changes to the layout calculations. A shader based solution is more robust, it's impossible for gaps to appear between the image slices with these changes as we're only drawing a single quad. I've not tried any benchmarks yet but it should much more efficient as well, in the worst cases even hundreds or thousands of times faster. Maybe could have used the UiMaterialPipeline. I wrote the shader first and used fat vertices and then realised it wouldn't work that way with a UiMaterial. If it's rewritten it so it puts all the slice geometry in uniform buffer, then it might work? Adding the uniform buffer would probably make the shader more complicated though, so don't know if it's even worth it. Instancing is another alternative. ## Testing The examples are working and it seems to match the old API correctly but I've not used the texture atlas slicing API for anything before, I reviewed the PR but that was back in January. Needs a review by someone who knows the rendering pipeline and wgsl really well because I don't really have any idea what I'm doing.
Now this issue is closed, you can try on 0.14.2🤔 |
|
Well, once we release 0.14.2 😂 Not out yet! |
Fixes #14183 Reimplement the UI texture atlas slicer using a shader. The problems with #14183 could be fixed more simply by hacking around with the coordinates and scaling but that way is very fragile and might get broken again the next time we make changes to the layout calculations. A shader based solution is more robust, it's impossible for gaps to appear between the image slices with these changes as we're only drawing a single quad. I've not tried any benchmarks yet but it should much more efficient as well, in the worst cases even hundreds or thousands of times faster. Maybe could have used the UiMaterialPipeline. I wrote the shader first and used fat vertices and then realised it wouldn't work that way with a UiMaterial. If it's rewritten it so it puts all the slice geometry in uniform buffer, then it might work? Adding the uniform buffer would probably make the shader more complicated though, so don't know if it's even worth it. Instancing is another alternative. The examples are working and it seems to match the old API correctly but I've not used the texture atlas slicing API for anything before, I reviewed the PR but that was back in January. Needs a review by someone who knows the rendering pipeline and wgsl really well because I don't really have any idea what I'm doing.
Bevy version
0.14
What you did
Update to 0.14
What went wrong
As the picture shown, there are thin lines in the background.
Additional information
The original picture resolution is 4x larger than the sprite, I don't know if this is the reason
The text was updated successfully, but these errors were encountered: