Edges of sprites appear to have thin white lines.

[Cassumbra]

These appear to be thinner than a pixel, and are a bit difficult to see. Rotating the sprite might help to see them better. They're also more apparent when the sprite is transparent. There's a chance that this is due to some part of my graphical set up, but I'm not sure what would be causing it if that was the case.

[FraserLee]

I'm not quite able to see what you're referring to in that image. Do you think you could you circle some place it's apparent, or post a zoomed in version, or post a bevy project in which it happens?

Other questions:

• what wgpu backend are you running on?
• Does the sprite itself have a hard edge, or is there anti-aliasing?
• Any chance of bleed in the texture (does the sprite go right up to the edges)?

[Cassumbra]

Is this of any use? INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce GTX 1050 Ti", vendor: 4318, device: 7298, device_type: DiscreteGpu, driver: "", driver_info: "", backend: Dx12 } Also:

It is a bit hard to see with the dark sprites on the black background, but the problem worsens as i use brighter colors and more sprites.

Here's the tileset I'm using for these:

Let me know if there's any other information that would be helpful.

EDIT: Looking over all of this myself, it does look like the tile below is bleeding over. Is this the sort of thing that I could/should fix myself and isn't actually an issue with bevy_sprite3d? Sorry if so.

[FraserLee]

Ah yep, this is a fairly common problem with rendering tilemaps. The way GPUs sample things, you can get bleed-over from adjacent tiles where you would expect a hard edge. I think there are ways to go about fixing it with a custom shader with more case specific sampling behaviour, but that'll always be slow and finicky and have a tendency to regress when on different platforms.

The usual way people in gamedev deal with this is by adding some "padding" to the tile-map, copying the rows of pixels that form the boundary over a few times so that any lookup past the edge still gives you what you would expect.

This isn't really something we would try to fix with bevy_sprite3d, but luckily I was running into this exact same issue when writing one of the demos, and already have written a python script to automatically adjust tilesets. It's in the assets folder, here:

https://github.com/FraserLee/bevy_sprite3d/blob/main/assets/dungeon/padding.py

I used it to transform this tileset in the following way:

I also made a PR into bevy a while ago to support this exact case, lol. Small world. https://github.com/bevyengine/bevy/pull/4836

Basically call TextureAtlas::from_grid_with_padding with your padding set to the number of pixels buffer you give that script, and offset set to half that value.

[FraserLee]

A screenshot from an old unity project of mine to better show visually what I'm talking about with those bleed pixels

[FraserLee]

If you need help figuring out how to run that python script lmk. If not I'll close the issue in a day or so.

[Cassumbra]

This works! Thank you. For some reason, I do have to add 1 to my index when im selecting the tile I want now. Not sure why that is. I am using bevy_asset_loader and I wonder if I'm doing something wrong or something.

`

[asset(texture_atlas(tile_size_x = 10., tile_size_y = 10., columns = 32, rows = 8, padding_x = 1., padding_y = 1.))]

[asset(path = "tilesets/dejavu10x10_gs_tc_transparent_padded.png")]

pub dejavu_transparent_padded: Handle, `

[FraserLee]

That is a bit weird. Also just be aware that padding_x and padding_y are the total distance between sprites on the sheet in pixels (I'm guessing = 2 after you run the script) and you'll probably also want to set offset_x and offset_y to be half the value of the respective padding values.

[FraserLee]

but so long as it looks like it's working, everything should be fine