Pixi.js: Sprite glitch with antialiasing

[qtiki]

In some situations a Sprite has a visible corner-to-corner glitch with antialiasing enabled. I was able to reproduce this in the playground by first drawing a full-screen sprite and then another sprite on top of it: https://www.pixiplayground.com/#/edit/Kj8yLiP9bFoPIeMvNzyYe

Expected Behavior

Drawing a Sprite on top of a previous Sprite should fully cover the old Sprite without any bleeding artifacts.

Current Behavior

I'm not sure whether the bug is visible with all display resolutions, but it is clearly visible on my QHD display. Here's a 10x zoom of the image where the red Sprite drawn before the white Sprite is bleeding through the polygon edges in the middle:

Possible Solution

I'm not sure what is causing this. It could have something to do with all of the Sprites being drawn with the same z-value but I haven't really investigated this any further than the repro-case in the playground.

Steps to Reproduce

See the linked playground example.

Environment

• pixi.js version: 5.2.1
• Browser & Version: Chrome Version 80.0.3987.122 (Official Build) (64-bit)
• OS & Version: Windows 10 Pro
• Running Example: https://www.pixiplayground.com/#/edit/Kj8yLiP9bFoPIeMvNzyYe
• Display Card: Nvidia GTX 1650 (driver 442.19)

[ivanpopelyshev]

We dont use z-buffer. Nope, its standard webgl antialiasing. Why do you even need it? Of course three are techniques to avoid those kind of things, for example im working on https://github.com/gameofbombs/pixi-blit , it should be smart vector caching system.

[qtiki]

I needed anti-aliasing for an animated Spine mesh. Figured it would be easiest to just enable WebGL antialiasing. I didn't expect it to break with simple Sprite overlays.

[qtiki]

This might be a driver issue or something weird. The problem isn't visible on a different pc with a full hd 1920x1080 display, but when I change my resolution to that I still see it. I'll dig into this a bit more and keep you posted if I find anything interesting.

[ivanpopelyshev]

Spine meshes? OK, then you need it. I actually think every medium-sized game needs settings:

1. enable AA
2. resolution=2 for retina.
3. cap 30FPS

because all those things can affect application performance and quality seriously, and its better leave it to user.

[qtiki]

This is somehow related to the implementation of the WebGL MSAA and drawing two polygons in the exact same position with a single draw call. If I move the second sprite one pixel to the right the glitch is no longer visible. Also if I insert 16 Text objects between the first and the second sprite to force a batcher flush (on WebGL 2.0 renderer) the glitch goes away. Note that it's still there if I have only 15 Texts.

I tried debugging this with Nvidia Nsight but for some reason I can no longer attach it to Chrome without Chrome crashing. Anyway, I'll keep digging...

[qtiki]

Doh! I was quite surprised that this bug happens with forceFXAA flag as well until I went digging in PIXI code and found out that flag isn't used anymore/yet/ever?

[eXponenta]

Hm, it wasn't be depricated, how i know.
@bigtimebuddy what do you think about it?

[qtiki]

This issue was not really about the forceFXAA issue, although I believe using FXAA would have not exhibited the same bug as MSAA. I did some testing yesterday by adding real depth values to the batcher primitives and enabling depth test to see if those extra hints would allow the GPU/drivers to handle the multisampling better. Unfortunately it didn't help at all. I'm thinking of reporting this to Nvidia Developer Forums to see if someone there has a deeper understanding of the problem. Could we still keep this issue open as it's not really fixed?

[bigtimebuddy]

GitHub closed this automatically because the PR merged and referenced this issue. Sorry about that.

[qtiki]

I got rid of the glitch by changing these Sprite indices:

const indices = new Uint16Array([0, 1, 2, 0, 2, 3]);

To this:

const indices = new Uint16Array([0, 2, 3, 0, 1, 2]);

In other words I draw the two triangles in a different order. I'm not sure if this is a bug in Nvidia drivers or just an implementation detail in the multisampling. The WebGL specs state that the antialiasing method is totally up to the implementation so there's no telling what happens in an edge case (pun intended) where a single primitive has overlapping edges. It's entirely possible that changing the order of the polygons would bring this problem up with Intel or AMD drivers - or then this problem only happens on some Nvidia cards or drivers and other devices work just fine either way. This would probably need some testing on different devices.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.