We’ve encountered two machines now out of several, which when SSAO is enabled get a defective heavy red tint across the screen. Shown here with and without (we have a toggle to disable SSAO.)
Upgraded to latest BJS 5.15.1. Dont know when the problem appeared.
On machines where this occurs, appears in all browsers - latest Chrome & Edge & Firefox.
One machine has an Nvidia RTX 3080 with latest Win10 and latest Nvidia drivers, so the problem isnt limited to obsolete drivers with inadequate WebGL/GPU support.
Here’s my SSAO pipeline setup:
// add SSAO
const ssaoRatio = {
ssaoRatio: 0.5, // Ratio of the SSAO post-process, in a lower resolution
blurRatio: 0.5// Ratio of the combine post-process (combines the SSAO and the scene)
};
if( !lowQuality ) {
const ssao = new SSAO2RenderingPipeline("ssao", scene, ssaoRatio, [camera], false);
ssao.radius = 15.5;
ssao.totalStrength = 1.3;
ssao.expensiveBlur = false;
ssao.samples = 16;
scene.prePassRenderer!.samples = 16; // MSAA disabled by default (==1) with SSAO, so enable
}
Chrome is confirmed latest, v103.0.5060 64bit. Same with Brave and Firefox. Latest BJS too, 5.15.1
There are no related warnings/errors in the console.
I dont do anything with render targets explicitly. Just set the engine up with SSAO and MSAA, point it at the one Canvas element in React, and go.
The weird thing is this only happens on 2 known machines so far, everywhere else is looks fine including mine. I cant reproduce this on my machine at all.
Unfortunately the full app is too large for sharing (and company proprietary anyway, you know how that goes). I wish I could reproduce the problem locally.
We’ve discovered the problem is specific to MSAA. If I set the MSAA sample rate to 1, the problem goes away on the problem machines (but so does the MSAA, of course).
Why would random PCs have an apparent failure to support MSAA? Particularly a young machine with the latest Nvidia RTX, latest drivers, and all Windows 10 updates.
I cant even repro the problem on my own machine with the same code that is failing elsewhere. That’s why Im forced to ask if anyone recognizes the problem via screenshot and description.
Looking at different ways to obtain SSAO, with the SSAO2RenderPipeline we’ve had to re-enable MSAA with scene.prePassRenderer.samples =16. This works fine for roughly only 4 machines out of 5, with the minority suffering the red wash bug.
Revisiting the older SSAORenderPipeline, how does one enable MSAA or FXAA?
The scene.prePassRenderer seems no longer valid.
The SSAO instance appears to lack a member “samples” or “textureSamples”.
Modified the existing SSAO demo replacing SSAORenderPipeline with SSAO2RenderPipeline and our config. Consistently incurs the “red bug” on machines where this bug is known to happen. The only changes here are in the SSAO/2 setup.
Screenshots are from my boss’s laptop (Win10, Nvidia 3080 Mobile), since mine doesnt suffer the problem.
For SSAO, _originalColorPostProcess.samples = 4 does work to restore anti-aliasing, yes. Thank you.
Although SSAORenderingPipeline has a separate, more subtle problem I didnt spot earlier. This happens on all machines.
Hard to describe. It looks like slightly-muddied screen-space layer is detached from the camera and overlaying on top of the screen. Maybe I can capture it in video. You have to look closely, mostly at the ground plane as the camera rotates. Look for the subtle ground layer that doesnt rotate. It’s like SSAO is stuck on an old color frame instead of using most recent.
{“vendor”:“Google Inc. (Intel)”,“renderer”:“ANGLE (Intel, Intel(R) UHD Graphics Direct3D11 vs_5_0 ps_5_0, D3D11)”,“version”:“WebGL 2.0 (OpenGL ES 3.0 Chromium)”}
Oh hey, well there’s one interesting point. It’s using the onboard Intel UHD GPU, not the Nvidia 3080 Mobile. Which BTW that is a laptop so the Nvidia is not an add-on card.
Some enumerator is taking the 1st GPU found, instead of taking the best. With both GPUs being integrated, you’d think the Intel one would be de-prioritized if not entirely disabled.
And SSAO2RenderingPipeline manages to tickle an MSAA bug in the Intel UHD driver I guess?
Just for reference, here’s my info as well - and the red bug never happens here.
{“vendor”:“Google Inc. (NVIDIA)”,“renderer”:“ANGLE (NVIDIA, NVIDIA GeForce RTX 3080 Direct3D11 vs_5_0 ps_5_0, D3D11)”,“version”:“WebGL 2.0 (OpenGL ES 3.0 Chromium)”}
Nvidia Optimus is a technology where a notebook with two graphics cards (integrated Intel GPU and discrete Nvidia GPU) can dynamically switch between them during regular use based on the needs of the applications.
The goal of Optimus is to save battery life while still giving a chance for high-performance graphics.
Applications needing high performance should use faster discrete Nvidia GPU, applications needing longer battery life should use slower but less-energy-consuming integrated Intel GPU.
You think the red bug is a fault in Chromium then? Seems like an Intel flaw.
The “Optimus” GPU switching business is doing it’s intended job of favoring the lower-powered GPU when deemed adequate, it’s just the Intel GPU/driver then happens to fail on MSAA support.
