XR motion controller unwanted picking of 3D buttons meshes

Hello, it’s me again with another VR question that I cannot seem to solve on my own. I have compared both attached PGs a hundred times, but I’m unable to locate what the problem might be.

Both attached PGs import the same .glb with animations. The motion controllers work exactly as intended in the first PG. But in the second PG I’m able to do funky stuff that is not intended, and there also seems to be a ghost living in there with an invisible bounding box interfering with the Ray from the controllers.

PS. I’m using a Quest 2 when trying to make it work.

First PG:

https://playground.babylonjs.com/#0I8B39#1

In this PG the interaction and controllers work exactly as I want them to. Ps. the glb model is on the second floor. Shortcut through the balcony :wink:

Second PG:

Babylon.js Playground

In this PG the interaction is all over the place. I’m able to both push/interact with the buttons as intended, but I’m also able to grab and move them… Why are the buttons behaving like this in this PG, but not in the first PG?
Another weird thing in this second PG is that there seems to be some kind of invisible “bounding box” in front of the Continue/Pause button that the controller Ray stops at.

Hi!

This is probably because of the imported mesh’s bounding box size, BUT i’ll have to check before being 100% sure :slight_smile:

Assigning to me, will get to that soon.

Big thanks! I have tried to enable the bounding box on everything in the Inspector, but I cannot see anything unusual…

About the buttons that can be moved in the second PG but not in the first. I know that I needed to create extra bounding boxes for the show/hide buttons by the three spheres in the first PG. I couldn’t figure out how to stop the grabbing of the meshes without the extra bounding box as a blocker.

But the mystery is why there is no need to similarly create bounding boxes around the 3D controls by the cube in the first PG, but seems to be needed in the second PG…?

I would rather just make every mesh in the scene non pickable by default, and then set “mesh.isPickable = true” for the meshes that needs to be pickable… But I’m thinking that setting isPickable to false for the 3D buttons would make them non interactable?

Just wanted to update with some of my findings upon further inspection.

Invisible bounding box issue
Can the invisible bounding box issue in PG 2 have something to do with the “root1.scaling = new BABYLON.Vector3(-2, 2, 2);” (line 114) of the mesh straight after importing? Can there be some kind of residue bounding box data stuck in there because of not waiting before scaling?

Unintended picking of button meshes issue
In PG 2 I can get around the grabbing of the button meshes by doing what I did with Button 1, 2 and 3 in PG 1. That is to create a “blocking” bounding box around the stackpanels, and then set these new bounding boxes as “non-grabbable” meshes on line 412. I also need to change from “onPointerClickObservable.add” to “onPointerDownObservable.add” for it to work. I loose the button clicking animation when clicking the buttons.

I also need to set the blocker bounding boxes to “isVisible = false” when not in XR. Otherwise the slider gets stuck to the mouse movement when in desktop mode. Probably because it latches with the DownObservable instead of being momentary with the ClickObservable…

Not sure why. But the functionality is restored, and the meshes stays in place.

So currently I have found a work around. But I’m sure there must be a better way of doing it consistently…
Should I really need to have to create extra bounding boxes for each 3D button I do not want to move with my motion controllers? And why do I not need to do it in PG 1…?

I opened your playground and at first I was asking myself - how is this possible. But then I look into the code and, well, it’s pretty clear why :slight_smile:

The 3D GUI elements are meshes and are a part of the scene. So, they behave just like any other mesh. You don’t need to create a blocker. Instead of adding blockers or playing with the mesh’s properties, you can filter them in the callback that sets their parent. i.e. - if it is a 3D button, don’t grab it with your right controller. as simple as that.

Can I ask about the negative scaling - why is it needed?

Thanks for checking!
I see, I managed to get each buttons mesh (one by one) through the following…

const tn003 = scene.getTransformNodeByName('transAnimBtn');
const tn004 = tn003.getChildTransformNodes()[0];

var animBtnMesh1 = tn004.getChildren()[0];
var animBtnMesh2 = tn004.getChildren()[1];
var animBtnMesh3 = tn004.getChildren()[2];
var animBtnMesh4 = tn004.getChildren()[3];
var animBtnMesh5 = tn004.getChildren()[4];
var animBtnMesh6 = tn004.getChildren()[5];
var animBtnMesh7 = tn004.getChildren()[6];

And then I set each “animBtnMeshX” like this in the motion controller function.

//Add meshes that should not be grabbable
if ((mesh === animBtnMeshX)) {
return;
}

But I do not understand how I can create a variable that selects all Button3D meshes in the scene (instead of doing each mesh one by one)? I have tried the getClassName, but it only returns the class name as a string (I think), not all the Button3D meshes in the scene.

About the negative scaling: It was inherited from another PG where the imported .glb was mirrored (I think). So, it is really not necessary in this example.

See PG1 #1

But even If I set the scaling to positive (2, 2, 2) in PG1 is still have the ghost bounding box issue. Not sure if you can see it, or if it is a Quest 2 specific issue. But the ray and the blue dot that follows the mesh contours is following an invisible bounding box around the cube. So something is not right.

Even without scaling, rotation and position there is still a ghost bounding box around the cube… And it can be grabbed and moved with a motion controller. I can’t for the life of me figure out what it is. I have turned on bounding boxes for everything in the Inspector, but it is not there…

See PG1 #2

Update 1:
Upon more inspection I find that XR-RigCamera and the TteleportationTarget are the only things that could possibly create the invisible bounding boxes. Is it possible that these are to blame, and how can I solve it so that they are not in the way for the motion controllers in that case…?

pinging @RaananW

are the meshes displayed per default?

I have fixed an issue with the two meshes (making them invisible per default), can you try with the latest version?

The meshes are invisible by default, I just turned them on when trying to figure out what is causing the issue.
What latest version are you referring to? I tried #4 of the PG aswell, but the issue is the same.

I think that I have a hard time explaining the issue, so I made a video to demonstrate it. As you can see the ray from the controller is “seeing” an invisible bounding box above the cube. I can grab and move this invisible bounding box, but I can not figure out what is causing it and how to solve the issue… Any ideas?

if they are invisible they shouldn’t influence any return picking info, or have their bounding boxes influence anything in the scene. This is really weird.

I am sorry, but from all of the messages I am a bit at a los as to which playground I can test this with. And I am so sorry if you have already provided the link - would you be able to show me a reproduction of this in the playground?

Yeah sorry this thread got a bit confusing since there was initially two simultaneous issues discussed.

This is the PG from the video:

1 Like

Found the issue! thanks a lot :slight_smile:

It is the backplate of the slider. I am working on a fix for that.

Here is the fix - [GUI] Fix 2 slider3D issues by RaananW · Pull Request #13411 · BabylonJS/Babylon.js (github.com)

It will be available in the next stable version.
Thanks for the patience :slight_smile:

2 Likes

Super grateful! Thank you :ok_hand:

1 Like