The WebXR Experience Helpers - Babylon.js Documentation This section doesn’t match the api docs.
does not create an WebXRExperienceHelper, it creates a WebXRDefaultExperience, whose
baseExperience is a WebXRExperienceHelper.
In the next line,
WebXRDefaultExperienceHelper doesn’t exist.
I’m sure there’s more to it, but I’m learning myself.
I assume you are referring to this:
the list describes what the default experience does under the hood. And it does initialize a base experience helper, amond other things (as you also found out yourself). It does also state that:
To check if the default experience helper initialized correctly, make sure the baseExperience variable was created:
I can change the text thou if you find it confusing
In this line:
var xrHelper = await scene.createDefaultXRExperienceAsync( /* optional configuration options */ );
What I’m saying is that in this example, the variable is being named ‘xrHelper’, but scene.createDefaultXRExperienceAsync returns a WebXRDefaultExperience, it’s not actually an ‘xrHelper’
In the next line
var xrHelper = await WebXRDefaultExperienceHelper.CreateAsync(scene, /* optional configuration options */ )
It says it’s equivalent, but first of all, there is no WebXRDefaultExperienceHelper class. Assuming it meant WebXRExperienceHelper.CreateAsync, it’s still not actually equivalent because it returns a WebXRExperienceHelper and not a WebXRDefaultExperience.
And yeah, that line after that is also confusing, because “default experience helper” is not a thing. I guess it might just be an ambiguous phrase, because if it said “default experience’s helper” it would be easy to follow that there is a default experience which has a helper field.
I am not sure I follow…
Of course there is - Babylon.js/webXRDefaultExperience.ts at master · BabylonJS/Babylon.js · GitHub
It is the main entry to XR (well, the default one), and is the one returned when you use either one of those functions that you mentioned.
Internally, it has an instance of the webxr experience helper. it adds a few other important features on top (pointer selection, teleportation, ui and more).
WebXRDefaultExperience is what you linked.
WebXRDefaultExperienceHelper is what the code says.
Got it, but once you remove the helper (will be done), it all makes sense :-).
I will make sure to update the page
To make the “equivalent” functions actually equivalent they would need to look like this:
var xrDefault = await scene.createDefaultXRExperienceAsync( /* optional configuration options */ );
var xrHelper = xrDefault.baseExperience
var xrHelper = await WebXRDefaultExperience.CreateAsync(scene, /* optional configuration options */ )
The default experience is actually a helper as well Due to historical reasons and backwards compatibility its name has not been changed, but all in all - it is a helper. This is why the documentation was written this way.
I have no problem changing the variable name in the doc I changed the variable name in the documentation (thanks for that) , but eventually - it is the developer’s decision what they name their vars and other members. The important part is understanding the API and the structure. And I do hope this part was clear.
Ok, so it looks like my problem with the API docs is that CreateAsync in WebXRExperienceHelper - Babylon.js Documentation says it returns a WebXRExperienceHelper, but it actually returns a WebXRDefaultExperience.
Here’s a playground
The CreateAsync of the Default Experience returns default experience (as in your playground). The Experience helper’s CreateAsync returns a basic experience helper:
(the last helper is the one you are looking for):
If it says otherwise in the doc I will change it instantly, but I can’t find that in the docs
Ok cool, I see there’s another class that snuck in there. Last nitpick, the new code doesn’t work in a copy/paste sense because the
WebXRExperienceHelper doesn’t have the
BABYLON. prefix. Unless you already have some preference on that, it would help the newbies coming upon this article.
Yeah, this is a decision we have to make when writing the documentation - do we always use the Babylon namespace, or just use the classes. People using imports / es66 will argue that they can’t copy-paste too because of the babylon namespace.
We always provide playground examples with the code so you don’t need to work hard to see an example. this is a trade-off between providing a 100% working code (in the playground) to providing a clean code that can be used by all.
Anyway, thanks for updating this. After the references to any ‘default’ were taken out of the helper section, it all clicked for me.