-
-
Notifications
You must be signed in to change notification settings - Fork 35.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clean up WebXR manager by calling setRenderTarget #22558
Conversation
This change ended up being much larger than I anticipated.
I tried out all the vr (and some non-vr) examples with:
Performance of WebXR Layers with multisampled-render-to-texture and an implied WebXR depth buffer is on par or slightly better than the origin vanilla WebXR implementation. |
src/renderers/WebGLRenderer.js
Outdated
|
||
// The multisample_render_to_texture extension doesn't work properly if there | ||
// are midframe flushes and an external depth buffer. Disable use of the extension. | ||
if ( renderTarget.useMultisampleRenderToTexture ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe worth adding a log/warning here. How likely is it that you would end up in this state without user error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not likely, but the author can force a texture if they wanted to.
I'll add a warning.
@Mugen87 can you also take a look? |
Yes! I'll try to review the changes in the next days 👍 . |
Is
|
@Mugen87 I think I addressed your comments. Do you have any suggestions on how to best test this? |
Um, it's probably best to merge PRs which apply deep changes to the renderer at the beginning of a month. In this way, we have the complete dev cycle for more detailed testing. It's definitely a good sign that the E2E tests all pass (although they do no cover all use cases). I've also tested selected examples manually today by downloading your branch. Everything seems to work fine. However, having more time for verification is of course preferable. |
That's OK :-)
Thanks! If you know of more examples, I would love for one of us to try them out. |
Do you mind explaining in more detail the rendering issue? I've not seen something unusual when testing the branch. |
The version that is currently checked in uses the ext_multiview_to_texture extension. It allows efficient multisampled code but it suffers from the drawback that a certain order of graphics calls cause the depth buffer to be discarded. We can revert the PR that introduced this extension or integrate this PR which works around that issue. |
I'm still worried that this is changing colors from the old non-layers based WebXR. |
I think my fix is pretty safe; it's just making the layers and non-layers code paths have the same behavior: #22997 |
tested your Patch on oculus quest2 browser with disabled webxr Layers, initial Loaded Textures looks normal now, but new created Textures in webxr session still darker looks like this needs some redefine? |
@arpu I assume that's a separate (but probably related) issue. I can't repro it, so I'll let you explore. |
if i remove this line https://github.com/mrdoob/three.js/blob/dev/src/renderers/webgl/WebGLPrograms.js#L95 it works in webxr view maybe this needs be sRGB in a webxrSession |
It might have to do with how the textures are being created. I thought that line was my problem too originally, but it turned out the fix was elsewhere. Do you have a simple repro URL? And does it also repro on mobile AR? |
will test again on next dev build update with your Patch on https://raw.githack.com/mrdoob/three.js/dev/examples/?q=webxr#webxr_vr_ballshooter |
@elalish have reproducible simple example at https://raw.githack.com/vrlandio/three.js/vrlandio/0.136.0.vr2/examples/?q=webxr#webxr_vr_ballshooter ( on Controller select it create a new Geometry and new Material for spawn the Ball) i can reproduce this with chrome and the WebXR API Emulator and on Oculus Quest 2 OculusBrowser with enabled/disabled Layers |
As I mentioned in the PR, if we change the texture format to be sRGB, we also need to communicate that to the browser when we create the projection layer. Otherwise, the multisampled path that uses renderbuffers is broken. I also think we should make this lighter rendering an option as it produces output that doesn't match the 2D representation; at least on quest. |
The render inside VR should be identical to the one outside VR (as it always has been). |
i can still reproduce this with https://raw.githack.com/vrlandio/three.js/vrlandio/0.136.0.vr2/examples/?q=webxr#webxr_vr_ballshooter ( all created balls in the webxr session are darker) and some side note, if i enable webxr navigation in OculusBrowser and transform in webxr to a new Scene all texture are darker |
@arpu Can't repro. Do you mind recording a video? |
@cabanier yes the example use three.js r136, with r136 all initial loaded bevore enter the webxr session looks good but not the created in the webxr Session, but looks like @Mugen87 refactor the decoding #23129 (comment), better wait to investigate after this |
I can't imagine how the removal of the sRGB inline decode should affect WebXR scenes. I think your issue needs to be investigated/solved separately. |
I can confirm that we're also seeing dark/wrong colorspace WebXR rendering with r136, both on Desktop (via Quest + Link) and Oculus Browser on Quest. |
@hybridherbst Can you share a screen recording from inside the Quest? |
It seems to be related to using render textures (doesn't happen when not rendering into any); will investigate further and open a new issue if it's not just a mistake with using RTs on our end. |
Do you mind checking if the latest |
Still happens on latest builds.
Before, this wasn't causing any darkening and both the RT and the XR result were correct; Creating the RT with sRGBEncoding fixes the issue – I'm not sure but I think the rendering result shouldn't change when rendering into a RT and then restoring state.
|
I applied your change to the latest version of three.js and the balls look identical. |
@cabanier Yes this fixed the Problem with loaded Materials looks darker! Awesome |
When you say "this fixed the problem", what change are you referring to? |
not sure tested latest dev version 0311f8f |
I'm really facing severe glitch effect ( after upgrade from r134 to r135/136 ) when using
I'll try to make a small example. |
This change changes WebXR so it calls
setRenderTarget
instead of binding to the framebuffer directly.This will fix a couple of issues.
In addition, it introduces the ext_multisampled_render_to_texture extension and uses that instead of using renderbuffers.
This contribution is funded by Oculus.