Sprites render pixels from cell next to it

[Terry_Sznober]

There appears to be a rendering bug with sprites. It appears as though the sprite renderer is sampling pixels from the cell next to it. This is exhibited in all of the following documentation samples:

1. Sprites from different cells: https://playground.babylonjs.com/#YCY2IL#3
2. Sprite animation: https://playground.babylonjs.com/#YCY2IL#4
3. Slide show animation from JSON file: https://playground.babylonjs.com/#YCY2IL#13
4. Pick And Rotate A Selected Sprite: https://playground.babylonjs.com/#YCY2IL#9
5. Single Layer Sprite Map From A File: https://playground.babylonjs.com/#YCY2IL#14
6. OutputSize Changes Size And Ratio Of Plane: https://playground.babylonjs.com/#YCY2IL#17
7. Color Multipled By Red: https://playground.babylonjs.com/#YCY2IL#19
8. Single Tile Animation: https://playground.babylonjs.com/#YCY2IL#26
9. Far Distance Sprite Map: https://playground.babylonjs.com/#YCY2IL#25

Here is a screenshot the bug in action:

I was really hoping to use Babylon for a top-down pixel art survival-crafting-exploration game

[mawa]

Hi and welcome to the Community,

This looks to me like just a poorly designed spritesheet. The line you are seeing and qualify as’ a bug’ is simply the feets from the sprite above. Say you would change the size to 65px instead of 64px (it would of course mess everything horizontally). But the line is gone. So this is really just when designing your spritesheet. It’s important you create a grid and when working with pixels (obviously) remain consistent and precise (and leave at least 1px, possibly 2px to play it safe for resize/rescale, transparent on each cell). Else, I don’t see anything wrong with the sprite manager.

I hope this helps and reassures you towards your project and…meanwhile, have a great day

Edit: Since I don’t like answering by making just assumptions I quickly double-checked by opening the spritesheet in PSD. Turns out I was right (check out the rulers set at 64px in this SS below from PSD on the original spritesheet).

Here’s a very rushed edited version.
You can see the line is ‘gone with the wind’

https://media-geneva.ch/demos/bjs/forum/spritesheet-debug.html

[Terry_Sznober]

I created a repro PG that exhibits the bug I described earlier today.

Babylon.js Playground

Here is a screenshot showing the source image in Aseprite and the PG. The image is 224 x 96 pixels, and the tile size is 32 pixels. I drew lines one pixel outside the cell of each of the three colored circles. When rendered by the BJS sprite class, you can see these lines even though they should not be part of the sprite cell.

In case that sprite sheet goes missing, I’m attaching it here.

My assumption is that only the pixels inside the tile cell should be rendered, not the pixels outside of it. Is that not correct?

[mawa]

@Terry_Sznober

the tile cell should be rendered, not the pixels outside of it. Is that not correct?

In essence, yes. Should be. In practice… Honestly, I also have the same issue with i.e. svg (non-related to BJS). When I draw a circle at zero pixel on the canvas and then import my svg (even in photoshop) I eventually get a bit of it that’s cropped. Reason why I always leave at least 1px transparent.

You can also see it flickering when zooming in or out. Eventually the line would disappear. I believe it’s because there must be some rounding operation made. Now, I’m shit with maths. May be this can be improved, ensuring it will never round higher than the limit. But that might also mean that the last bit could be cropped 1px (at least from my understanding).

Anyway, the Team will likely have a look at it today and answer. For whatever answer there is, I think I’m gonna stick with my way of leaving 1px transparent. As a designer, this sort of thing doesn’t really strike me . I just find a way to play it safe (but I do understand that it can strike a dev or eng since… as you say, this is just not entirely correct (at least in theory )

[roland]

@mawa

You can also see it flickering when zooming in or out.

Here you can compare the sprite shader with a custom pixel perfect shader. The latter doesn’t flicker.

Babylon.js Playground

EDIT:
With pixelPerfect = true, same result, flickers…

Babylon.js Playground

EDIT END

Original topic:

Pixel perfect for plane with texture?

For sprites, there’s a pixel perfect mode that was added following this thread: Sprite pixel art artifact issue? Is it possible to apply the same technique to a plane with a texture on it (which behaves like a billboarded sprite)? As you can see in this PG: https://playground.babylonjs.com/#4G38H4#2024 there’s artifacts visible when moving the camera. Updated: https://playground.babylonjs.com/#4G38H4#2027 Here is a comparison of the plane with texture, and a sprite that has pixelperfect enab…

[Evgeni_Popov]

The problem comes from the fact that the default blending for sprites is “combine”. If your sprite is alpha-tested only and you don’t want to blend with the screen, you can disable alpha blending (see line 14):

Babylon.js Playground

You can check that turning alpha blending for the shader material makes the artifacts appear:

Babylon.js Playground

[mawa]

This has me confused. Not speaking about the shader, if I use pixelperfect and bilinear sampling with alpha disable, I still have the lines. Not to mention I lost the alpha of course.

Babylon.js Playground

Though, I’m not even sure why I bother. As said, I always leave at least 1px transparent when working with the alpha. This way, there’s absolutely zero issue, so I really don’t see the point… I must be missing something?!

[Terry_Sznober]

Good morning everyone. Thanks for chiming in on this issue.

The original point of my thread here is that I was expecting to have 3 separate sprites rendered on screen, but WITHOUT the lines surrounding them because they are NOT part of the sprite cell. I created the sprite sheet very specifically to show that the inner 3 cells only have filled circles, and the cells adjacent to them have content in them (lines in this case, and they very intentionally are butted up against the cells that I intended to render).

---------------------------------------------------------------------------------------------------
| empty cell | empty cell   | empty cell | empty cell    | empty cell | empty cell   | empty cell |
---------------------------------------------------------------------------------------------------
| empty cell | first sprite | empty cell | second sprite | empty cell | third sprite | empty cell |
---------------------------------------------------------------------------------------------------
| empty cell | empty cell   | empty cell | empty cell    | empty cell | empty cell   | empty cell |
---------------------------------------------------------------------------------------------------

It should not matter if the cells I marked as “empty cell” actually have any content in them. The problem is if the they do have content that is directly adjacent to the sprite cells in the sprite sheet, they are getting incorrectly rendered. I should only see filled circles on the screen, no lines. Does that make things clearer?

[roland]

@Evgeni_Popov

The problem comes from the fact that the default blending for sprites is “combine”

I’ve figured this one also, however ran into the issue as @mawa did:

@mawa

if I use pixelperfect and bilinear sampling with alpha disable, I still have the lines. Not to mention I lost the alpha of course.

I came to a solution by turning out sprite instancing and always applying the epsilon for the offsets:

EDIT:

I’ve added inner borders to test the solution w/o sprite instancing:

[Terry_Sznober]

Do you have a PG link for your final solution? It looks promising!

[roland]

It requires changes to the core library so I have to create a draft pull request. It will trigger a creation of a snapshot build. Once it’s ready, I’ll send you the link to the snapshot.

Wait a minute… or 45 while it builds the snapshot

[Terry_Sznober]

Thanks Roland. I’m at work for the day so will have to wait till this evening to try it out. I very much appreciate your help. Also thanks to everyone else on this thread.

[roland]

@Terry_Sznober

Thanks Roland

You are welcome!

I had to introduce a new property called pixelPerfect to the cellSize options. I need to disable sprite instancing in the constructor of the SpriteManager. This is of of course subject to change. This is just a proposal so actually every change is subject to change

Modifying the pixelPerfect property after creating the SpriteManager does not turn on sprite instancing for now.

Babylon.js Playground

[Evgeni_Popov]

You can disable sprite instancing by doing engine._features.supportSpriteInstancing = false;:

Babylon.js Playground

The offset (0.01 - default value if you don’t pass a parameter for the 6th parameter of SpriteManager constructor) seems to help, although I guess the right value to use will depend on the texture/sprite sizes…

[roland]

@Evgeni_Popov

You can disable sprite instancing by doing engine._features.supportSpriteInstancing = false;:

Thanks, I traced back the source where it is read from, however it would be more convenient to turn it of just for a single SpriteManager instance.

Would you please have a look at the draft PR and express your thoughts? I must confess, I didn’t really think through the condition when to apply a positive or negative epsilon so that part might be not exactly correct.

Another thing is how are we gonna deal with the pixelPerfect setter.

@Evgeni_Popov

although I guess the right value to use will depend on the texture/sprite sizes…

Correct.

Thanks a lot!

more perfect pixel perfection

[roland]

Guys, @Evgeni_Popov came with a much more elegant solution which I have implemented. You can read about the details in the pull request comments

epsilon in sprite.vertex shader

Test PG:

Babylon.js Playground

[Terry_Sznober]

Awesome! This is exactly what I was looking for! Hopefully the documentation samples work with this fix as well.

[mawa]

@Terry_Sznober

Hopefully the documentation samples work with this fix as well

Yes, would be great to check on that. I can review them if needed…

[roland]

Guys, there was another pro tip from @Evgeni_Popov. The final solution was pretty simple:

applying epsilon in sprite instancing mode

Thanks goes to @Evgeni_Popov for letting me to do the PR despite he literally wrote all the necessary code in the comments section of the PRs

[Terry_Sznober]

Unfortunately, it looks like the bug is still in BJS v7.26.3. PG:

Babylon.js Playground

You can still see that the pixels outside the cell are still being rendered.

This earlier PG worked correctly:

Babylon.js Playground

Hmm, when you view them in different browser tabs and flip back and forth, you can also see that the pixels from the cell you do want to render is being possibly cropped (looks like its being shrunk).