SSRPass: Resolution Scale?

[ROBYER1]

Description

There are some popular 3d online solutions such as Vectary that have SSR on by default and on mobile they appear to scale the resolution of the SSR effect down to achieve better performance.

Is there any possibility of allowing us to tweak the resolution used by the SSR solution in the current three.js version?

Solution

I saw in realism-effects there is a resolution scale property which when adjusted can make SSR cause less of a performance hit on lower end desktops/mobile and high resolution display rendering. Something like this would be great for SSR in three.js by adjusting the internal resolution of the SSR effect.

Alternatives

realism-effects package has the resolution scaling, although it doesn't work in more recent three.js versions past “three”: “^0.151.3” so I can't use it in current projects I tried it with unless I roll back the three version.

Additional context

No response

[Mugen87]

SRRNode has a resolution scale property:

three.js/examples/jsm/tsl/display/SSRNode.js

Lines 72 to 81 in a551c3b

	/**
	* The resolution scale. Valid values are in the range
	* `[0,1]`. `1` means best quality but also results in
	* more computational overhead. Setting to `0.5` means
	* the effect is computed in half-resolution.
	*
	* @type {number}
	* @default 1
	*/
	this.resolutionScale = 1;

With r180, there will also be a new quality setting:

three.js/examples/jsm/tsl/display/SSRNode.js

Lines 123 to 134 in a551c3b

	/**
	* This parameter controls how detailed the raymarching process works.
	* The value ranges is `[0,1]` where `1` means best quality (the maximum number
	* of raymarching iterations/samples) and `0` means no samples at all.
	*
	* A quality of `0.5` is usually sufficient for most use cases. Try to keep
	* this parameter as low as possible. Larger values result in noticable more
	* overhead.
	*
	* @type {UniformNode<float>}
	*/
	this.quality = uniform( 0.5 );

That requires the usage of WebGPURenderer though. Any chances to migrate to the new renderer? Post processing has been considerably improved in the new renderer with built-in MRT and effect combination (pass reduction) support.

[ROBYER1]

This looks like just what I need, I should have done a but more digging but I wasn't aware there was much extra that could be done outside of the example SSR scenes on the three.js examples site. Thanks for showing me this, I'll go give it a test now!

[ROBYER1]

I forgot to clarify this is for the normal WebGL solution and not the WebGPU version. Is there similar functionality in the regular WebGL SSR in Three js?
This one:
https://threejs.org/examples/?q=ssr#webgl_postprocessing_ssr

[Mugen87]

No, there isn't. Would you be willing to contribute this feature to SSRPass? It's essentially a member that needs to be honored in setSize() and the resolution uniforms.

Personally, I see the "old" post processing classes in some sort of maintenance mode and focus solely on the new pipeline. However, I still review and support PRs that update EffectComposer and its passes.

[ROBYER1]

When the Safari support for WebGPU is out of tech preview, I will be making the jump to use it but currently my web projects target all widely available browsers so patchy WebGPU support and even lack of WebGPU support on older devices that don't get a Safari update due to no iOS updates could be a blocker.

I'm using Needle Engine currently and their WebGPU support is only on the roadmap still for a similar reason as far as I know.
https://cloud.needle.tools/roadmap#webgpu-support-in-needle-engine

If I can make any progress looking into it, I will submit a PR and if not then I will be for sure making the jump to WebGPU when it is feasible for my work projects 👍

[Mugen87]

Side note: The name might not imply this but next to a WebGPU backend WebGPURenderer has an additional WebGL 2 backend. When a platform does not support WebGPU, it can still use the new renderer since it automatically fall backs to WebGL 2. You can even force a pure WebGL 2 usage by setting forceWebGL: true when creating the renderer.

[ROBYER1]

In which case, unless I'm misinterpreting, I can use the new renderer for the SSRNode resolution scale setting, but force it to use pure WebGL2? I'll have to test that. That is a great feature for a situation like mine where common devices used don't all support the latest standards yet.

[Mugen87]

If you look into webgpu_postprocessing_ssr and change below line:

three.js/examples/webgpu_postprocessing_ssr.html

Line 98 in 54ac263

renderer = new THREE.WebGPURenderer();

to:

renderer = new THREE.WebGPURenderer( { forceWebGL: true } ); 

the demo will always run with a WebGL 2 backend and ignores WebGPU capabilities. Although you not necessarily have to use this flag. If you use the default, devices that support WebGPU use WebGPU. iOS devices will automatically use WebGL 2.

This automatism is the reason why forceWebGL is rarely used and is more interesting for debugging.

[Mugen87]

I have reconsidered your use case and I agree for a useful SSR you want resolution scaling in place. I've added it to SSRPass which hopefully gives you more flexibility.

I've also enhanced the GUI of webgl_postprocessing_ssr so you can test the feature on dev with a slider when #31629 has been merged.