Xr-dom-overlay (new feature)

I’ve added xr-dom-overlay support as a Babylon XR feature. Looking for input on my draft PR:
Feature dom-overlay by brianzinn · Pull Request #10378 · BabylonJS/Babylon.js (github.com)
^^ looks like linting failed :man_facepalming: , so feedback besides that! :grinning_face_with_smiling_eyes:

You will need a browser that supports xr-dom-overlay within an immersive-ar experience (ie: Android device with new Chrome). Live demo here:
xr-dom-overlay demo (brianzinn.github.io)

You’ll notice that I brought in a 50% transparent Material UI Switch component, so there is a lot of potential.
dom-overlay

8 Likes

So great!! Thanks :slight_smile:

I will review this today, as soon as I can.

https://playground.babylonjs.com/#RFTC4B#47
I added custom XR options to createDefaultXRExperienceAsync() and it’s work with dom-overlay.

1 Like

But when the session is over, the application crashes.

That’s a great example PG. The equivalent from 5.0.0-alpha.23 (not yet released) will be:

const xrDomOverlay = fm.enableFeature(BABYLON.WebXRDomOverlay.Name, 1, { element: '#pg-header' }, undefined, false);

The last parameter is significant as it marks the ‘dom-overlay’ as an optional feature. Once that version is out then I will update the docs and add a playground.

@buddy90210 - Do you experience those crashes using the demo link in the original post? It looks like passing in the XRSessionInit may have unintended consequences or is misconfigured.

No it’s work ok, but when i use anchors app crashes.
This PG without anchors, works fine:
https://playground.babylonjs.com/#RFTC4B#51
This PG with anchors, it crashes when exiting:
https://playground.babylonjs.com/#RFTC4B#52

1 Like

Will there be any difference using this than passing

                    optionalFeatures: ["dom-overlay"],
                    domOverlay: {
                        root: document.getElementById('#somerootelement')
                    }

to the options of WebXRExperienceHelper ?

1 Like

hi @br-matt - Good Question. Simple answer is that there is no difference, but there will hopefully be more functionality added and the feature itself will be future proof (the feature itself is a draft proposal state in the unlikely event of changes).

In terms of updates one thing that I wanted to add was the ability to hide the DOM overlay. I tried to set the display type to “none” and got a blank screen (Pixel 4 + Chrome). I will do some more testing before posting an issue about that, but that would become a method on the feature. So, besides the option for event deduplication with supressXRSelectEvents option property ( dom-overlays/explainer.md at master · immersive-web/dom-overlays (github.com)) there are no advantages currently.

One thing made easier with the feature is that you can get the overlay type (screen,floating,head-locked) from the feature itself without needing to know where to look on the session object:

const domOverlayFeature = featureManager.enableFeature(WebXRDomOverlay.Name, 1, {
    element: '.dom-overlay-container'
}, undefined, false);
xr.baseExperience.onStateChangedObservable.add((eventData: WebXRState) => {
    console.log('overlay type:', domOverlayFeature.domOverlayType);
})

Once dom-overlay is available on more devices/browsers then any polyfills (if needed) or enhancements will make their way into the feature. Once the next alpha release goes out I will update the docs to include many of those details. Thanks for asking.

3 Likes

Exactly that! :slight_smile:

Technically you can implement any of those features yourself. Babylon gives you the full freedom to do that. You don’t even have to use the features manager - everything is exposed publicly, you can interact with the XR session directly. Babylon is simply trying to simplify and unify the process. And also provide a public API that will work in the future, even if the webxr draft changes for some odd reason :slight_smile:

1 Like