Shared AR object position issue

Include the following details (edit as applicable):

  • Issue category: Multiplayer
  • Device type & OS version: Android
  • Host machine & OS version: Windows
  • Issue Environment : On Device
  • Xcode version:
  • ARDK version:2.3.0
  • Unity version:2021.3

Description of the issue:
I am a beginner to shared AR, so I am building a sample application to throw a ball to each other, but throwing a ball from a device causes others in the session to witness the ball going away from the camera rather than coming to the camera.

Hello @Naveen

Would you mind sharing a bit more information about your scene and/or scripts? If you could attach any recordings and/or code snippets related to the ball-throwing logic, that may prove useful for getting to the bottom of things.

Also, do you happen to be using an ARMeshManager anywhere in your scene’s hierarchy?

hi @rob_link
yes I am using ARMeshManager in my scene.
I am attaching screenshots of my scripts and hierarchy window.

Hmmm… you may want to try passing a desired rotation vector over the network in addition to passing the desired position. You could then pass that rotation into the PlaceObject() method where it could be used during the rigidbody.AddForce() call instead of camera.transform.forward.

I suspect that camera.transform.forward may always be resolving to the host camera’s transform.forward vector, which would explain why a client device always sees the ball being thrown behind them when standing across from a host device.

hi @rob_link thanks for your reply. I tried to implement your advice, but the problem persists.

Hi @rob_link any suggestions?

Hello @Naveen,

We were unable to reproduce the exact issue that you reported with the spheres being thrown in reverse. However, we took the following steps to produce a scene in which different users in a networked session can successfully throw spheres that originate from their device’s position and rotation. You may want to follow these steps with a fresh project to see if this is the result you’re looking for. If so, you can compare the resulting project to your existing project in order to pinpoint the issue.

Starting with the ARNetworking scene that ships with the ARDK Examples package (located on the Downloads page here), we opened the ARNetworkingExampleManager.cs script in order to make some changes.

First, we added an Update() function that checks for tap input from the user, and then calls an OnScreenTap() function that passes in the touch information.

Next, we added the OnScreenTap() function, which captures the current position and rotation of the local camera, serializes the information, and sends it across the network with a tag of 0.

Then, in the OnDidReceiveDataFromPeer() function, we look for a message with the tag of 0, and respond by deserializing the position and rotation that was sent and forward those values to a ThrowBall() function.

Next, we added a ThrowBall() function and public GameObject ballPrefab;
field. This function instantiates a ballPrefab at the given position and rotation and adds a force along its forward vector.

Finally, we built a Ball prefab that has Rigidbody and SphereCollider components, while ensuring the prefab’s position and rotation values are all 0…

…and then assigned this prefab to the ARNetworkingExampleManager component on the ExampleManager.

The resulting scene demonstrates an environment in which players can throw balls forward from their device position and rotation.

Let us know if this example grants some insight into the methodology used, and if you have any other questions about how to achieve the desired effect.

P.S. - If you’re observing unreliable physics results when testing in one of the Virtual Studio mock environments, you may want to check the mock environment prefab for any colliders that may be affecting your rigidbodies in the scene. For example, the ParkPond prefab erroneously contains an active Box Collider component that will interfere with spheres thrown within the mock environment unless deactivated.

We’ve escalated this particular issue internally and it will be addressed in a future ARDK release. Happy building!

hi @rob_link, that’s great. It worked. Thank you so much

1 Like

This topic was automatically closed 2 hours after the last reply. New replies are no longer allowed.