I’m trying to use SceneOptimizer in WebXR Immersive Mode, but not having success. Are they intended to be compatible?
Here’s what I’m observing:
- any use of
TextureOptimization
causes the entire immersive view to go blank - I just see the background color and nothing else from that point on
-
HardwareScalingOptimization
has no effect - I can see it gradually increase the target to 4x via console logs form onNewOptimizationAppliedObservable
, but the appearance in XR does not change (and neither does the framerate)
I see both of the above on Quest2 in Oculus browser and in Firefox Reality
Adding @RaananW for 1
for 2: this is expected as we do not control the resolution in XR (It is dictated by the device)
you don’t control the screen resolution, but you do control the XRWebGLLayer frame buffer resolution, which can be up- or down-scaled for quality or performance adjustments see XRWebGLLayer.getNativeFramebufferScaleFactor() static method - Web APIs | MDN and WebXR Device API
I let @RaananW take it from there
1 Like
you can change the frame buffer scale factor when requesting the session init. either here:
WebXRDefaultExperienceOptions | Babylon.js Documentation (output canvas options) or if you do it manually then here - WebXRSessionManager | Babylon.js Documentation
The reason the scene optimizer doesn’t work is that XR is using a texture to render the session, and if its size changes XR doesn’t know how to handle it. I assume the scene optimizer tried optimizing the render texture. We will need to mark this texture “non-optimizable”. This way you will still be able to use the scene optimizer while using XR.
want to create a github issue? I will be able to track it better,
Thanks, @RaananW - filed.
Re the scale factor, it sound like you’re saying there’s no chance HardwareScalingOptimization
will be updated to handle immersive mode. Have y’all ever thought about putting a banner on documentation pages that’s like “This feature is/isn’t available in Immersive Mode” kind of like what MDN does for Web Workers? That could really help us make determinations about implementing features.
2 Likes
That’s a good idea. Will require a bit of a change in the documentation, but I do agree that it’s an important information. I’ll add that as an issue in the documentation repository
1 Like