Xr-dom-overlay (new feature)

Demos and projects
1

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
2

So great!! Thanks :slight_smile:

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

3

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

1 Like
4

But when the session is over, the application crashes.

5

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.

6

No it’s work ok, but when i use anchors app crashes.
This PG without anchors, works fine:

This PG with anchors, it crashes when exiting:

1 Like
7

Will there be any difference using this than passing

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

to the options of WebXRExperienceHelper ?

1 Like
8

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
9

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
10

Hi, this example works fine for me, but when I try (in a React app) the DOM overlay is visible before switching to AR mode, not visible on the first switch to AR, but is visible on subsequent switches.
Any clues? Is there a link to your repo for the example posted here?
Also, supressXRSelectEvents doesn’t seem to work for me…
The DOM overlay is perhaps the most powerful feature in WebXR, thanks for adding to BabylonJS!
Cheers

11

Feels like an issue with react-rendering or context update, but it iss very hard to tell. The dom overlay is rather straightforward - it will render the HTML element you passed to it.
If you can provide some more information we might be able to help, but it does seem like it is more related to your react context.
Would also be great if you opened a new thread for that

12

I suspect you are not rendering in React when you think you are. That example was written in React and could use a code refresh, but the source is there:

1 Like
13

Many thanks both for responding: the sample code was useful…it helped me realize I was doing something really dumb with brackets! I’d managed to only enable the DomOverlay inside my onHitTestResultObservable callback! Doh!

2 Likes
14

Thanks for sharing this, and I was able to use the code example directly in my React project. It required me to wrap my canvas element in a parent div, and to move my fullscreen code to the parent object. Using modal objects (material ui) also required some changes to the CSS (z-index), but overall an easy transition.

Thanks again (from a fellow Vancouverite),
r

2 Likes