WebXR hit-test performance issues

Questions
1

Hello!

I’m building an AR experience with hit-test and anchors. The goal is simply to place objects in AR.

On Android phones and tablets the experience is smooth, but on a Meta Quest 3 the placed objects stutter and drift as soon as I move my head.

You can reproduce it on the headset with this Babylon Playground:
https://playground.babylonjs.com/#KDWCZY

What’s puzzling is that a very similar demo runs butter-smooth in the official WebXR sample:
https://immersive-web.github.io/webxr-samples/hit-test-anchors.html

This makes me suspect a performance issue in the Babylon hit-test implementation. If I place an object without enabling hit-test, it stays perfectly stable.

One more detail: even if I disable hit-test after placing the object, the session remains sluggish, as if something under the hood is still doing work.

Any insights or suggestions would be greatly appreciated. Thanks!

1 Like
2

cc @docEdub

3

Thanks. I’ll look into it.

5

I’m not able to reproduce this on my Quest 3, yet. The placed objects are stable for me. They do not stutter or drift, and I’m not seeing any performance issues with hit-test enabled.

Maybe you have a lot more WebXR planes being detected than me? I added plane id and count logging in https://playground.babylonjs.com/#KDWCZY#1044 . Try it out and see how many planes are detected. I’m getting 8 on my headset.

6

Thanks for getting back to me.

Today I realized that the performance issues seem to be closely related to the type of object being spawned.

So I updated both demos to use the same 3D model I’m trying to display in my project.

Here’s the WebXR version (sorry if the object looks very dark — it uses unlit materials, which don’t seem to work properly in this environment):

And here’s the modified Playground version:

Please let me know if you can notice any difference now!

7

I’m still not reproducing the issue. I placed 20-ish models and they all stay fixed to their positions very well, even at 15 FPS.

Can you capture a video from your headset to show the issue? Also, is there any console output that could give us a hint?

8

Nothing interesting from the console output unfortunately!

Here is a capture from my headset where I test both the WebXR and the Babylon version of the experience:

The issue is not quite as relevant as I see from the headset, but I hope it’s still noticeable.

9

Ya, I see it. Try playground https://playground.babylonjs.com/#KDWCZY#1044 to see how many planes are being reported in the console.

10

I’m able to reproduce this now after clearing my space setup and rescanning the room.

11

Great, I’m glad you could reproduce it! Hopefully this will help narrow down what’s going on.

Anyway, I tried your playground and the console reported 59 planes, in case that helps.

1 Like
12

Thanks! 59 is a lot more than the 8 I’m getting right now.

13

FYI I haven’t forgotten about this. I did some testing last week and it looks like the model being inserted is fairly complicated and is causing the FPS to drop, which may explain the stuttering you’re seeing. I plan on looking into this further soon to see why the FPS drops so much and to see if there’s anything we can do to speed it up on our end.

1 Like
14

Great to hear you’re still investigating this!
I realize the model itself is fairly heavy, but since the WebXR samples were running smoothly, I was hoping there might be some small tweaks or optimizations on the Babylon side to make things a bit smoother.
Let me know if there’s anything I can do on my side to help with the investigation.

15

Ya, I looked at the WebXR example code briefly and I don’t think the PBR shaders are doing much. Babylon’s PBR shaders are a lot better, and as a result they are more expensive on the GPU.