Rendering artefacts with recent Chromium versions and render targets

[heretique]

Hey PlayCanvas Team, we're noticing rendering errors with recent versions of Chromium based browsers. Here's a short screen recording of the issue:

https://user-images.githubusercontent.com/139596/190588044-519819d0-5e10-4ee7-a467-5ed68c8b815a.mov

Notice on the left character there are rendering artefacts on the sweater. The difference between the two characters is that the one on the left is first rendered into a render target (that's our default behaviour of the application) then on screen, while the one on the right is rendered directly into the frame buffer.

The artefacts appear in:

Chrome Version 105.0.5195.125
Edge Version 105.0.1343.33 

but they don't show up in recent versions of Firefox or older versions of Chrome:

Firefox 104.0.2
Chrome 99.0.4844.51

I also need to mention that I've tested this with PC 1.56 and PC 1.52.6 and the results are similar which led me to believe that this might be an issue in Chromium's WebGL implementation but I couldn't find a way to go around it, rendering directly into the frame buffer may not be a solution for us given current implementation of the application.

[yaustar]

Hmm... Looking at the image, I'm wondering if its related to the depth buffer or z fighting?

A bit difficult to know more without a repro. Would it be possible to give a published link of this or a cut down version of this to see if it's reproducible on our end?

Have you tried Chrome Beta or Chrome Canary to see if it has been fixed later down the line?

[slimbuck]

Looks like the render target could be using a 16bit depth buffer instead of 24/32. cc @mvaligursky

[heretique]

It seems to be a 16 bit depth buffer for Edge and for Firefox but it only shows fine in Firefox

I'm also attaching the Spector.js captures for these maybe it helps. spectorjs captures.zip

@yaustar I'll try this with the Canary versions as well and see if I can create a smaller project to replicate the issue.

[slimbuck]

If this is a depth buffer issue you could probably fix it with careful camera near and far settings. Have you tried optimising these for your scene?

i.e. Set camera near distance as large as possible without it causing clipping and set far as small as possible without causing clipping of your scene. This will make maximum use of your depth buffer. 16 bits should be fine for rendering this little green dude.

[heretique]

We had near camera distance to 0.1 and far to 15. Increasing the camera near distance to 1.0 from 0.1 solved the issue. This gives us enough precision to remove z-fighting with the hidden meshes that are part of the collar. We should consider this issue fixed I guess but I'm still intrigued why it worked for Firefox when it had the same depth buffer format.

[willeastcott]

Those original near and far clip planes seem very reasonable to me. I do wonder whether something else might be at play here. For example, can you verify your camera entity (or any ancestor entity) has no scale applied to it?

[kungfooman]

These material attributes aren't exposed in the editor, but to reduce z-fighting you can try via scripting:

material.slopeDepthBias = -5;
//material.depthBias = -5; // same, I don't know the difference

Or alternatively fix the model (if thats the only issue).

[heretique]

I forgot to mention a very important aspect, this is reproducible only on MacOS and Chromium based browsers. On Windows it works fine with the 0.1 near and 15 far camera planes on all browsers. @willeastcott the scale for the whole camera tree up to root is (1, 1, 1) @yaustar I've also tested with Chrome Canary (Version 108.0.5309.0 (Official Build) canary (x86_64)) and the issue is still reproducible. I guess it might be a bug in the WebGL implementation on MacOS, this platform is known for having issues with this now and then.

[yaustar]

Bizarre 🤔 Wondering if it's something that we can reproduce on our end. I've not seen this yet.

If you do have a published link of this for us to take a look, we can see if we can reproduce on our end.

[heretique]

I'll try creating a test project towards the weekend to help with investigation on your end.

[mvaligursky]

I know in the last 6 or so months, Chrome has been testing switching to ANGLE Metal rendering .. perhaps they made the switch and introduced new errors. Or we have, in the engine, that's entirely possible too.

Could you please try different rendering backends (OpenGL vs Metal) to see if it makes any difference here. See page 8 here: https://www.khronos.org/assets/uploads/developers/presentations/WebGL__WebGPU_Updates_Jul_22.pdf

go to about:flags, search for "angle" and try different backends.

[heretique]

I created a test project here: https://playcanvas.com/project/987093/overview/repro-issue-888 it should contain the minimum reproducible scene but there's one issue with it, the render target is always black and I couldn't figure out why 😞