Bevy 0.5 Sprite Sheet Animation Sprite Leak

[selfup]

Bevy version

bevy = "0.5"

Operating system & version

Windows 10

Can test on Ubuntu 20.04 as well as MacOS Catalina

What you did

Upgrade to Bevy 0.5 from 0.4

What you expected to happen

Expect sprite sheet animation to work the same as before

What actually happened

Once upgraded, when I full screen the window the sprite animation has artifacts from another position in the sprite sheet

Additional information

Here in my player_setup.rs: https://github.com/selfup/ionized_earth_rpg/blob/main/src/systems/player_setup.rs#L13

let texture_atlas = TextureAtlas::from_grid(texture_handle, Vec2::new(16.0, 16.0), 5, 5);

This now has to be changed to:

let texture_atlas = TextureAtlas::from_grid(texture_handle, Vec2::new(16.1, 16.1), 5, 5);

To avoid the other sprite from leaking in.

Here is a small screenshot of the feet leaking in above the player. Looks like two black bars:

Short video showing the artifacts leaking through when moving around.

2021-04-17.01-59-52.mp4

[mockersf]

I could not reproduce, either using your code or trying a smaller example 😞

[cart]

Hmm could you both share your graphics cards (and driver if relevant)

[selfup]

@mockersf

I have updated my repo to have the latest 0.5 changes so you can try it out without checking out to a different branch:

https://github.com/selfup/ionized_earth_rpg

---

@cart

GPU: 1660ti

Currently on 461.72 - Going to upgrade to 466.11

Edit: Same issue with new driver.

---

Rust version and target info on Windows 10:

stable-x86_64-pc-windows-msvc - rustc 1.51.0 (2fd73fabe 2021-03-23)

---

Tried 1080p max window, same issue.

Fine when window is in the original size.

Let me know if you need any additional information!

[cart]

I'm able to repro on my computer (nvidia gtx 1070, arch linux, proprietary drivers), but only if I vertically resize the window. Some vertical scales produce the artifacts (identical to the screenshot above), and others don't. This bug is identical to one that this commit resolved, which was later removed. Re-adding that offset resolves the issue in ionized_earth_rpg. Ideally shaders shouldn't need to compensate for this (as custom user shaders won't be aware of the need). We should try to fix the problem in a "global" way instead of re-adding the shader hack.

[CptPotato]

Not sure if I'm understanding the source of the problem correctly.. but if it's the surrounding sprites bleeding into the current one then I think 1px of transparent padding and TextureAtlas::from_grid_with_padding() might be the way to go here.

[tatref]

I'm running into the same issue. Win 10, last updates, Nvidia RTX 2060, drivers 511.79.

The issue is happening regardless of window resize and of sprite size.

The leaking edge is not always the same, depending on the position of the sprite. I made a video with adjacent tiles colored pink:

out.mp4

Any idea how we could help to track down this issue?

[cart]

Yeah padding sprite sheets is a "generally accepted" resolution to this. I'd like to sort out a fix for unpadded sheets, but resolving these rounding errors has been pretty nasty (and sometimes platform specific?). As mentioned in StarArawn/bevy_ecs_tilemap#123, one option is to move to a texture array representation internally, but off the top of my head idk what the full implications of that move would be. For example, im pretty sure the array would need each layer to be the same size, so each sprite would need to take up the space of the "largest" sprite in the array. TextureAtlases can be more "compressed".

Pulling in @StarArawn as this is relevant to what they're doing.

[StarArawn]

Texture atlas bleeding

Causes

• Floating point precision issues - f32 is notoriously bad at precision and on GPU's its almost worse. When you start to add zooming and differing screen resolutions to this issue it becomes even worse than before because the texture pixels that can fit in the small triangle need to be squashed together.
• Texture filtering - This is probably the biggest culprit. There are two main types of filtering techniques used by GPU's: Nearest Neighbor and Linear. Both techniques work by sampling surrounding pixels in the texture. Nearest uses the pixels directly next to the current pixel where as Linear uses the 4 closest pixels to the current pixel being processed. When you have a sprite or tile directly next to one another you end up sampling into the neighboring pixels regardless of what filtering method you use. A good way around that is to add spacing. Usually you can get away with 1 pixel of spacing but if you require Linear filtering you'll likely need way more.
• Mipmapping - Bevy doesn't have mipmapping yet, but that's soon to change so I think its important to add some info here. As soon as you need mipmapping with an atlas I would advise to run away from atlases completely. The reason being that there is no ideal way of sampling an atlas at a given spot. For example typically mipmapping works by halving the size of the texture continuously until you are left with a 1x1 pixel. How can a 1x1 pixel represent multiple tiles or sprites in an atlas? You can manually generate mipmaps up until a certain point so you have roughly 1 pixel per item in the atlas but its messy to do. Further more the same texture filtering issue from before manifests itself in an even worse way as filtering occurs across the mipmap layers. In the past this was bypassed by increasing the size of your padding in some cases you had to increase it to more than double the original size of the texture in the atlas. There's obvious downsides to this approach.

Array Textures(Also known as Texture Arrays if you've used D3D)

Array textures can be best described as a texture that has layers. The texture's size remains constant throughout the layers which is one of the biggest disadvantages of using them. The advantages are you can filter and mipmap them just like you would a single texture meaning you don't need padding, you don't need weird filtering rules/setups or even manually filtering in shader(ew), and depending on your art style you may want linear filtering!

My sprites/tiles are different sizes can I still use an array texture?

Yes! The cost of using the array texture with differing sizes is that every texture has to be the max size of your largest sprite. This leads to some funky sizing of sprites as well since you'll want the size of the sprite to match the size of the array texture not the actual sprite texture size. Since the extra pixels are transparent this usually isn't an issue. The increased memory is a bummer but fairly minimal when working with 2D!

Wait why do I want mipmapping for 2D?

You probably don't, but you might? If you implement any sort of zooming you'll soon see artifacts where the GPU has a hard time picking a good texture pixel for a given screen pixel. This results in all sorts of weird looking artifacts like this:

A hybrid solution?

In bevy_ecs_tilemap I use a hybrid approach where I support both atlases and texture arrays. I think it should be possible to do this in your own code or even in bevy code. There's no reason why we can't have both! :)

[StarArawn]

I meant to say something about pixel perfect cameras which can also help with these things especially reducing floating point inaccuracies for 2D games.