WebXRManager: Native frame buffer scaling

[wilcoschoneveld]

Description

On the oculus quest 2 the default framebuffer scaling of 1 results in a framebuffer which is smaller then the native display resolution. The required scaling factor for native display size (1.4222.. for quest 2) can be retrieved programmatically right before initialization. This PR enables usage of this factor through a new constant called THREE.NativeFramebufferScaleFactor.

More information here: https://github.com/immersive-web/webxr/blob/master/explainer.md#controlling-rendering-quality

Usage:

renderer.xr.enabled = true;
renderer.xr.setFramebufferScaleFactor(THREE.NativeFramebufferScaleFactor);

[wilcoschoneveld]

Could I get a review for this? @cabanier @Mugen87 @mrdoob

[mrdoob]

I think we can do this automatically instead.

We could do

let framebufferScaleFactor = null;

And then do

if ( framebufferScaleFactor === null ) {

	framebufferScaleFactor = XRWebGLLayer.getNativeFramebufferScaleFactor( session );

}

Then we would not need the THREE.NativeFramebufferScaleFactor constant.

[wilcoschoneveld]

I think we can do this automatically instead.

We could do

let framebufferScaleFactor = null;

And then do

if ( framebufferScaleFactor === null ) {

	framebufferScaleFactor = XRWebGLLayer.getNativeFramebufferScaleFactor( session );

}

Then we would not need the THREE.NativeFramebufferScaleFactor constant.

I don't think this is a good idea because by default the oculus web browser has a lowered frame buffer size to improve performance of XR apps. I think it's best to leave the frame buffer scale factor at 1 by default, and to leave the default frame buffer size as the vendor's choice. I'm sure Oculus has thought very carefully about this. Also, in my testing I found that increasing the frame buffer to native size has quite an impact on performance because of the increased amount of fragments, so you have to know what you're doing. What do you think?

[mrdoob]

@cabanier What do you think we should do here?

[wilcoschoneveld]

@mrdoob I think I wrongly understood your suggestion, sorry. You want to use the now unused null value for using native size, and leave the default to 1.0. Still, I think a null value is commonly associated with using a default value. But we could go with that option to eliminate the constant.

[mrdoob]

Actually, I think I misunderstood your PR... So you're proposing passing 0 to get 1.4222 on Quest 2?

[wilcoschoneveld]

Actually, I think I misunderstood your PR... So you're proposing passing 0 to get 1.4222 on Quest 2?

I propose a way to allow the user a way to choose using a framebuffer of native size with a value of 0, regardless of the browser or device. It will resolve to 1.422 on the quest 2, yes.

[cabanier]

@cabanier What do you think we should do here?

I thought the Oculus browser didn't support framebuffer scaling. Do you see a difference when you move the slider on this site: https://immersive-web.github.io/webxr-samples/framebuffer-scaling.html

[cabanier]

@cabanier What do you think we should do here?

I thought the Oculus browser didn't support framebuffer scaling. Do you see a difference when you move the slider on this site: https://immersive-web.github.io/webxr-samples/framebuffer-scaling.html

Sorry, I didn't look at the PR. Is this to change the scale at runtime or at initialization time?

[wilcoschoneveld]

Sorry, I didn't look at the PR. Is this to change the scale at runtime or at initialization time?

At initialization time. As far as I know the scale factor cannot be changed during runtime.

[Mugen87]

Closing this in favor of #24877.