[WebXR] Teleportation preview fps loss when creating a teleportation feature through featuresManager

When using the default teleportation setup from the WebXRExperienceHelper the teleportation preview is really smooth, probably 72fps on my Quest device.
If I add a new teleportation feature through the featuresManager the teleportation preview drops to approx. 30fps. This is the code I use:

   const featuresManager = xrHelper.baseExperience.featuresManager;
                xrHelper.teleportation = featuresManager.enableFeature(BABYLON.WebXRFeatureName.TELEPORTATION, 'stable', {
                    xrInput: xrHelper.input,
                    floorMeshes: [ground],
                    pickBlockerMeshes: collisionMeshes
                }) as BABYLON.WebXRMotionControllerTeleportation;

Is there any reason for this?

For clarification: With teleportation preview I mean pointing around with the teleportation ray/mesh


How many meshes are in the collisionMeshes array? This is the only difference between the two.
Would also be great if you can share a reproduction so I can experience it myself

I have 4 meshes in the array. I tried it in the playground but couldn’t reproduce it there. In my case the performance loss happens even when adding no collision meshes.

Is it working well in the playground?

Are you using the latest babylon version?

It is working well in the playground, in either cases I get smooth 72fps. I was using the 4.2.0-beta.5 version and tried the current beta.9 version, which didn’t help. Logged the fps just to be sure and I get a performance change from 72fps to 25-35 fps, just by enabling/disabling the following code:

if (xrHelper.baseExperience != null) {
                const featuresManager = xrHelper.baseExperience.featuresManager;
                xrHelper.teleportation = featuresManager.enableFeature(BABYLON.WebXRFeatureName.TELEPORTATION, 'stable', {
                    xrInput: xrHelper.input,
                    floorMeshes: [ground]
                }) as BABYLON.WebXRMotionControllerTeleportation;

The same ground object is being used when creating the defaultXRExperience.

Could there be a performance loss, which is not noticeable in a simple playground scene?
Edit: I’m using an oculus quest.

Can you share an example of this FPS reduction? I am not 100% sure if i get the error, and code/example would make a lot of sense.

There should be no reduction in FPS just by enabling teleportation. It is not doing anything until you actually trigger it. If you have very complex objects in the scene, i would recommend turning the pointer selection off and see if it is helping.

But again - a working code example will be very helpful to be able to debug this.

I made an example with the Hill Valley demo, where the performance loss is noticeable on my quest device. Hope that helps.

Hill Valley
Original Demo: Babylon.js Playground
Demo with custom teleportation Feature: Babylon.js Playground

A few notes about this (and a fix :slight_smile: )

The main performance issue here is the pointer selection feature and not the teleportation. If you re-attach the teleportation but detach the pointer selection, the performance is as good as you can get in the quest:


The reason your demo is different than the one before (performance-wise), is that the pointer selection feature was not set when you recreated the feature:


Another thing is this - try not to play with feature-inits while already inside the session (like updating them on the first frame). The features manager is meant as a preparation for the session. It will work (well, it should work :slight_smile: ) but you might have a bit of overhead with taking care of disposing the old feature (and detaching it from the session)

1 Like

Thanks for your help, setting the ponterselection fixes it. But why does not setting it or not detaching it causes performance loss?

When teleportation is on and it has the pointer selection added to it, it detaches the pointer selection temporarily. The pointer selection feature can be very costly when it comes to complex scenes, as it does ray-picking on each frame on both hands. Quite the burden on your CPU :slight_smile: