Sometimes touch is not registered depending on what else the Interactor is colliding with

[ghost]

Environment

• Source of VRTK: GitHub
• Version of VRTK: v4 Github master (6e769d4)
• Version of the Unity software: 2019.1.6
• Hardware used: Vive
• SDK used: UnityXR/OpenVR

Steps to reproduce

In the example scene change for instance on Interactable Objects/Tools/Saw/InteractionLogic/Interactable.GrabLogic/Actions/PrimaryAction/Interactable.GrabAction.FollowAction: Follow Tracking to Follow Rigidbody, Grab Offset to Precision Point.

Expected behavior

It should be possible to always pick the object up, when the interactor is touching the object.

Current behavior

In the first case it works as expected. The saw can be grabbed, when just touching the handle or while touching the handle and the countertop at the same time.

In the second case it's not possible to grab the saw, while touching the handle and the edge of the countertop (different collider on the same object with similar configuration) at the same time. (Grab is triggered every time the pointer can be seen lighting up)

[thestonefox]

It's more of a configuration issue.

What's happening is, the interactor is touching both objects but then sorts the collisions by the one it's nearest to the origin of.

Because the interactor is picking up a successful collision with the drawer surface it thinks that is its nearest touching object.

I think perhaps the Interactor ActiveCollisionContainer should only be listening for collisions against InteractableFacades maybe?

At the moment the rule is set up to exclude anything with a certain tag.

But is it fair to say Interactors can only have valid collisions with Interactables?

[ghost]

That might definitely be an issue too and just taking interactable facades into account seems like a good solution? I'm not 100% sure though thats the only issue. The drawer is quite a bit away from the interactor position in this case. The perspective is just a bit bad in my example. I just tried a few more cases and it's somewhat random, which position works for grabbing and which doesn't. It looks as if the order in which the colliders get evaluated plays some part in it. Or maybe a bug in the part that determines the nearest touching object? It does seem to pick the closest one, when the interactor touches several interactables, but fails in this case, when it's just touching one interactable and some of the static colliders of the drawer base. This works, so it's not an issue per se with the mesh collider of the table. Does not work even though there is just one interactable touching the interactor. Works flawlessly with 2 interactables and picks the one you would expect.

In any case I feel like ignoring all non interactables would solve this, and make setting stuff up and moving colliders around or so less of an headache?

• If someone really needs interactor<->non interactive object touches for something, it would be easy enoug with v4 to just slap an additional trigger on the tracked alias/interactor maybe on a seperate layer and use that one for interactions with other colliders. So just my two cents would be, couldn't hurt to ignore that stuff for the general case.

[thestonefox]

It is the issue. it's the sub collider being touched has a closer origin.

If you go and change the CollisionValidity rule on the Interactor to "InteractableFacade" and don't make it a negation rule, then you'll see it works as you expect.

[ghost]

Ah okay now I get it sorry, my bad. If it takes the origin of the collider, then it makes total sense that the grab from the side works. Checking which collider overlaps more of the volume of the interactor would then be the only way to pick reliably and that seems indeed like overkill. Just tried changing the rule and it does work. For ease of use that should maybe be the default configuration. But this issue can be closed then.

[thestonefox]

No, I agree it should be the default config. Leave this bug open until I fix it.

Current behaviour isn't correct.

[thestonefox]

I believe this PR will fix it correctly https://github.com/ExtendRealityLtd/VRTK/pull/2037