Postprocessing adds a lot of pixelation

Mugen87 · September 12, 2023, 9:23pm

@new Did you write the comment at the followingChromium bug tracker? 1480965 - chromium - An open-source project to help move the web forward. - Monorail

If so, you should clarify that the comment is unrelated to the actual issue.

trusktr · September 12, 2023, 10:26pm

Make sure render targets are sized correctly inside of the passes, they do not take pixel ratio of renderer into consideration:

someRenderTarget.setSize(
  width * window.devicePixelRatio,
  height * window.devicePixelRatio
)

If we use values higher than devicePixelRatio, the result will be rendered at higher-than-physical resolution, then downsized, and will look even better (but will cost a lot more).

It is important to note (and maybe unfortunately) the postprocessing passes do not care about the pixel ratio we’ve set on our WebGLRenderer (with renderer.setPixelRatio(devicePixelRatio)) but this is good for keeping effect passes decoupled from renderers when possible (for use with multiple renderers in parallel, for example), and so we must explicitly handle pixel ratio ourselves when we size our effect passes.

BokehPass, for example, does not take pixel ratio into consideration when we set its size and it sets the render target size verbatim:

github.com

mrdoob/three.js/blob/ce0b3d0415c4bc87a8b4ad01c5d21cc26c6ec5eb/examples/jsm/postprocessing/BokehPass.js#L121-L125


      
          	setSize( width, height ) {
          
          		this.renderTargetDepth.setSize( width, height );
          
          	}

This means that if we set the pass to the same resolution as our WebGLRenderer, it will be half the resolution if our renderer.getPixelRatio() is 2! So, we need to do this:

const renderer = new WebGLRenderer()
renderer.setSize(width, height)
renderer.setPixelRatio(ratio)

const bokeh = new BokehPass(scene, camera)
bokeh.setSize(width * ratio, height * ratio)

new · September 13, 2023, 1:17am

Yes, you are right. I deleted the comment.

Mugen87 · September 13, 2023, 8:30am

That is not true anymore. If you call setSize() on EffectComposer, the composer honors the renderer’s pixel ratio and resizes all passes with the new effective width and height.

github.com

mrdoob/three.js/blob/e401356653cfa56b9ebeb36871d59cfd5d8eb635/examples/jsm/postprocessing/EffectComposer.js#L193-L210


      
          	setSize( width, height ) {
          
          		this._width = width;
          		this._height = height;
          
          		const effectiveWidth = this._width * this._pixelRatio;
          		const effectiveHeight = this._height * this._pixelRatio;
          
          		this.renderTarget1.setSize( effectiveWidth, effectiveHeight );
          		this.renderTarget2.setSize( effectiveWidth, effectiveHeight );
          
          		for ( let i = 0; i < this.passes.length; i ++ ) {
          
          			this.passes[ i ].setSize( effectiveWidth, effectiveHeight );
          
          		}
          
          	}

In general, you shouldn’t resize passes manually. Only resize the composer which cares about pixel ratio and the pass chain.

manthrax · September 13, 2023, 7:28pm

Ohh nice… TIL.

new · September 14, 2023, 6:28pm

hi @Mugen87 . I’ve seen your comment about camera.near value in the bug. What’s the suggested min camera near value? I am currently using 0.02 which gives the visual results, but adds pixelation. Should it be higher?

Mugen87 · September 14, 2023, 10:04pm

If possible, yes. However, depending on how we fix the issue you can keep using the exiting value.

Mugen87 · September 16, 2023, 8:03am

We have applied a change in three.js to mitigate this issue:

github.com/mrdoob/three.js

WebGLTextures: Increase default precision for depth buffers with WebGL 2.

mrdoob:dev ← Mugen87:dev75

opened 08:51AM - 15 Sep 23 UTC

Mugen87

+2 -1

Related issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1480965 …**Description** A user in the forum reported pixelization artifacts when doing RTT/post processing (see [here](https://discourse.threejs.org/t/postprocessing-adds-a-lot-of-pixelation/55813)). Since the artifacts did not appear in all browsers, I've filed an issue at the Chromium bug tracker. During the related investigations, it turns out the default precision of depth buffers for render targets in `three.js` is surprisingly low. The current precision can produce the white pixel artifacts like mentioned at the forum but also typical depth precision/z-fighting artifacts like in the following fiddle (its GUI option toggles RTT for comparison): https://jsfiddle.net/oquLde34/3/ Notice that the fiddle does not use a super special setup. The bit that triggers the artifacts is the low near camera value of `0.01` although you can even see (smaller) artifacts with `0.1`. That is definitely no unusual value. I remember similar rendering issues reported by users in the past which couldn't be fully explained. I'm sure the culprit is the default `DEPTH_COMPONENT16`. However, with WebGL 2 depth buffers can be defined with much higher precision. I'm using `DEPTH_COMPONENT24` in this PR similar to the default precision of depth textures which solves the issue in the fiddle and what has been reported in the forum. I have asked the Chromium devs if we have to expected any side effects from using `DEPTH_COMPONENT24` (e.g. incompatibilities with other WebGL commands): https://bugs.chromium.org/p/chromium/issues/detail?id=1480965#c12 If there aren't any objections, I think this PR should definitely be merged.

So the white pixel artifacts in the fiddle are gone with r157. It will be released at the end of this month.

new · September 17, 2023, 1:35am

This is awesome! Looking forward to upgrading the version asap! Thank you very much!

new · September 29, 2023, 2:03pm

Hi @Mugen87.
It seems the fix solved the problem only partially. If you pass antialias: true to the renderer, the issue is still present. Please see the fiddle here: Edit fiddle - JSFiddle - Code Playground. When I remove antialias: true the issue disappears.

new · September 29, 2023, 2:18pm

Also, could you please suggest what antialising technique I can use for mobile devices? SSAA is too heavy for that, but I need something since the pixelation is terrible.

Mugen87 · September 29, 2023, 3:13pm

I don’t think we can properly fix the issue if you use 0.00000001 as a near value since even a higher depth precision has its limits. You have to increase the scale of your scene instead.

Have you already tried a FXAA? It should be a lightweight AA pass and hopefully mitigate your aliasing issues.

new · September 29, 2023, 3:15pm

Oh, yes, sorry. However, it is still visible with camera.near = 0.01 which is not too low. Please see here: Edit fiddle - JSFiddle - Code Playground. When I disable antialiasing on the renderer level, the issue disappears.

Mugen87 · September 29, 2023, 4:05pm

It also disappears when disabling logarithmic depth buffer: Edit fiddle - JSFiddle - Code Playground

You really don’t need it with this near and far values.

new · September 29, 2023, 5:08pm

Thanks for your help! For some reason FXAA was making the model blurry, but TAA with 2 level of smoothing works for mobile devices and fixes most of the issues. I will also play with the scale and hopefully make it perfect. Thanks a lot!
PS: But I still believe that the problem with antialising + logarithmic depth buffer is a minor defect

Mugen87 · September 29, 2023, 5:24pm

Now I remember that this is actually a known issue. Unfortunately, we can’t fix this since using logarithmic depth buffer (meaning assigning values to gl_FragDepth) breaks MSAA. You can read more about this here:

github.com/mrdoob/three.js

Antialiasing has artifacts when logarithmic depth buffer is enabled

opened 03:58PM - 18 Jun 21 UTC

asbjornlystrup

Enhancement

When the logarithmic depth buffer is enabled, antialiasing fails in areas where …geometry intersects or lines up. See screenshot below. It feels like this would be a common issue, but I couldn't find any other post on it. With logarithmic depth buffer enabled. Notice the jagged, aliased lines. ![image](https://user-images.githubusercontent.com/9470947/122585815-33d38180-d05c-11eb-9261-1f6c3007fe42.png) With logarithmic depth buffer disabled. ![image](https://user-images.githubusercontent.com/9470947/122586092-844adf00-d05c-11eb-8aff-88b951a1c1fb.png) I've encountered this on desktop computers. I've seen it on both Linux Ubuntu and Fedora, in the Chrome browser. I don't remember how it looks in Windows, but it seems a bit strange if it would be different there? Right now we're at version 0.129.0 of threejs, but it's always been like this since we started using logarithmic depth (1-2 years ago), and it happens with all geometry. Is it like this for everyone else? Any idea how to fix it, or is it something we just have to live with? Thanks.

new · September 29, 2023, 5:58pm

Thanks a lot for the info! Also, if you are interested. I played with scale and it didn’t give me any visual benefits for mobile devices, pixelation and other stuff was still quite heavy. TAA fixes it, but it causes minor lagging, FXAA - was fast, but blurry (not sure why). I found this discussion FXAAPass causing blurry rendering - #9 by Torben_Van_Assche will try to fix it based on the recommendations.

new · September 30, 2023, 3:10am

Just an update. I have fixed FXAA, but it doesn’t fix the pixelation, quite useless in my case.