Arfoundation-samples: ARTranslationInteractable acts like Wile E. Coyote [Bug]

Created on 17 Nov 2020  路  11Comments  路  Source: Unity-Technologies/arfoundation-samples

When dragging objects in the Interaction.unity example scene, the object will always be placed at the height of the highest detected plane below the camera, even if a lower plane is being selected and is not occluded.

For example; if a plane is detected on the floor and another is on a table, objects will always be placed at the height of the table unless the phone is lower than the table.

This is happening because the function GestureTransformationUtility.GetBestPlacementPosition Raycasts against TrackableType.Planes instead of TrackableType.PlaneWithinBounds or even better TrackableType.PlaneWithinPolygon.

This means it treats all planes as infinite, and since GetBestPlacementPosition only checks against the first detected plane it creates a frustrating user experience. A temporary workaround is to modify ARTranslationInteractable.cs and GestureTransformationUtility.cs, but there probably needs to be a more robust solution to support multiple platforms.

This was tested with iOS 14 and AR Foundation 4.1.0-preview.13.

bug stale

All 11 comments

_MEEP MEEP!!_

+1 for issue title

We're looking into it. We'll post more info once we've confirmed whats going on.

Hello! What iOS device are you using when you get this issue?

Hi @tropicdragon

I have tested and experienced this issue in iOS 14 on an iPhone X, iPhone 12 Pro Max, and iPad Pro (4th gen).

I don't think the issue is phone specific, but rather a logical error with how the scripts handle raycasts. It is raycasting TrackableType.Planes which returns all planes including TrackableType.PlaneWithinInfinity. If all planes are infinite then the first received raycast is always the one closest to the camera.

There are a few other logical issues/difficulties with ARTranslationInteractable:

  • Even though you can only drag on horizontal planes, vertical planes will still block translation once they are detected. Even worse these block infinitely as well, and can create an issue where half of a room is cut off from interaction because the corner of a wall or couch was detected.

  • The interactable object always needs some an "anchor" parent object. This creates confusion when making scenes with pre-instantiated interactables.

  • In the script there seems to be an attempt to create either a similar behavior to infinite planes (so a user can place an object anywhere) using the parent "anchor" object, or a "drop down" effect when placing an object at a different level. It's not clear what the intended behavior is because this code is never reached. It seems to be because ARTranslationInteractable only positions the object when GestureTransformationUtility returns HasPlacementPosition as true.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Tested with ARFoundation 4.1.1 on an iPhone 12 Pro Max where the issues are still present. On a Galaxy S8 objects can be placed at different heights, although it will sometimes it will rise to the height of a higher plane unexpectedly.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Bumping for stale bot.

Hello, just wanted to inform that there is a solution for the issue where translating an object causes it to go to the level of the highest plane. This fix should be available in 1.0.0-pre.2 of the xr interaction toolkit package, which will be released soon.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kennethlng picture kennethlng  路  5Comments

sam598 picture sam598  路  3Comments

AdrienMgm picture AdrienMgm  路  5Comments

KirillKuzyk picture KirillKuzyk  路  5Comments

rvegele picture rvegele  路  9Comments