darker textures in WebxrSession in latest dev git

[arpu]

darker textures in WebxrSession in latest dev git

To Reproduce

Steps to reproduce the behavior:
https://raw.githack.com/mrdoob/three.js/dev/examples/?q=webxr#webxr_vr_ballshooter

Screenshots

Platform:

• Device: [Desktop]
• OS: [Linux, Android]
• Browser: [Chrome]
• Three.js version: [dev, 3280feb]

[arpu]

revert 63f7beb fixed the problem

[cabanier]

@Mugen87 Is it because the default framebuffer for WebXR isn't null?

[Mugen87]

The mentioned line only influences the output encode in the shader. And it is only required when rendering to the default framebuffer since WebGL does not allow to define its color space. If a render target is set, the output encode is disabled.

When using a sRGB render target, the shader writes linear values and WebGL should automatically convert to sRGB. Is the default framebuffer for WebXR a sRGB framebuffer?

[cabanier]

It depends on the output encoding. See https://github.com/mrdoob/three.js/blob/dev/src/renderers/webxr/WebXRManager.js#L284

It's needed there because the framebuffer that is created for multisampling, is created with that encoding. Maybe it shoudn't in case of the default framebuffer?

[Mugen87]

Maybe it shoudn't in case of the default framebuffer?

Can we give this a try?

[Mugen87]

If we can't fix this in WebXRManager, we have to add a flag to the XR render targets so we can identify them in WebGLRenderer and WebGLPrograms. It would be then possible to restore the old behavior which means adding back the missing GLSL linear-sRGB conversion (the reason why the image is too dark).

Not hard to implement but a bit hacky because it would be better to let WebGL handle the color space conversion if possible.

[cabanier]

WebXR Layers do allow you to specify the encoding. However, the oculus implementation has some bugs in this area that I'm trying to fix. For now, you can assume that you always write linear values.
However, the implementation of three before I added multisample_render_to_texture rendered to a framebuffer backed by renderbuffers which was then blitted to a non-multisample WebXR texture. This did gamma correction which resulted in lighter colors that some people preferred. I suspect that is where @HexaField's original bug and sRGB changes to the WebXRManager came from.

If we can't fix this in WebXRManager, we have to add a flag to the XR render targets so we can identify them in WebGLRenderer and WebGLPrograms.

I think that's what we need to do. Ideally, I fix the bugs in our WebXR implementation so three doesn't need this special behavior.

[mrdoob]

which resulted in lighter colors that some people preferred

In the world of PBR 3D, it's not about "preference"... it's about "correctness" 🤓

[Mugen87]

I've filed a PR to restore the old behavior.

I agree with @mrdoob that we should head for the correct solution which means a proper sRGB workflow. If colors are perceived as too dark, devs have to update their lighting.

However, it's not clear to me whether the sRGB workflow in WebXR is right and the colors as they should be. I did not have the chance so far to test this in detail with a Quest 2.

[cabanier]

The issue is that there is no correct behavior defined in the spec.

The Oculus browser sets the primaries to sRGB and the gamma correction should come from the texture type. However, the gamma correction seems to be incorrectly applied inside the compositor. I'm working with that team to get to the bottom of this.
Once the workflow is fixed/clarified, I will update the spec and our implementation.