Use Cloud Anchors to create multiplayer or collaborative AR experiences that Android and iOS users can share.
What is a Cloud Anchor?
Using Cloud Anchors, your app lets users add virtual objects to an AR scene. Multiple users can then view and interact with these objects simultaneously from different positions in a shared physical space.
Cloud Anchors are similar in behavior and function to anchors, but differ in that they’re hosted on the ARCore Cloud Anchor API service. This hosting enables users to share experiences.
How do Cloud Anchors work?
To enable these shared experiences, ARCore connects to the ARCore Cloud Anchor API service to host and resolve anchors. This requires a working Internet connection.
Hosting and resolving involves these steps at a high level:
The user creates a local anchor in their environment.
During hosting, ARCore uploads data for the anchor to the ARCore Cloud Anchor API service, which returns a unique ID for that anchor.
The app distributes the unique ID to other users.
During resolving, users with the unique ID can recreate the same anchor using the ARCore Cloud Anchor API service.
To create a good user experience with Cloud Anchors, it's important to understand the hosting process in detail, so that you can accommodate your app's design to help users be successful.
Establishing and hosting an anchor
To establish and host an anchor, ARCore uses a 3D feature map of the space surrounding the anchor (the center of interest). To obtain this feature map, the device’s rear camera must map the environment in and around the center of interest from different viewing angles and positions in the 30 seconds before the host call (ArSession_hostAndAcquireNewCloudAnchor()).
Beginning in ARCore SDK 1.12, this host call causes ARCore to upload select visual data from the last 30 seconds from the device's camera to the ARCore Cloud Anchor API service, which processes the visual data to construct the 3D feature map and return a Cloud Anchor ID.
The proper creation of the 3D feature map is critical to a great user experience. Otherwise, the mapping quality may be limited, making resolving harder. To improve map quality, we recommend that user interfaces explicitly instruct users to map as much of the environment around the center of interest as possible, by moving the device around the anchor from different viewing angles and positions.
To host a Cloud Anchor:
Wait a few seconds after the session starts to give tracking time to stabilize before attempting to host an anchor.
When selecting a location to host the anchor, try to find an area with visual features that are easily distinguishable from each other -- for example, a corner with visually distinct features.
Point the rear device camera at the center of interest, that is, the area surrounding the point where you want to place the anchor.
While keeping the camera trained on the center of interest, and while roughly maintaining the physical distance between the device and the center of interest, move the device around to map the environment from different viewing angles and positions for up to 30 seconds. Walking around in the space while keeping the device camera trained on the center of interest will enable capturing visual features of the area of interest from all angles, making resolving more robust.
Call ArSession_hostAndAcquireNewCloudAnchor() to initiate the hosting request.
ARCore uploads visual data, device poses, and the anchor pose via the ARCore Cloud Anchor API.
The ARCore Cloud Anchor API service creates a 3D feature map of the space, and returns a unique Cloud Anchor ID for the anchor to the device.
ArSession_hostAndAcquireNewCloudAnchorto check the status of a hosted anchor (including error handling messages).
The ARCore Cloud Anchor API service creates a 3D feature map of the space, and returns a unique Cloud Anchor ID to the device.
The anchor should be hosted.
ArSession_hostAndAcquireNewCloudAnchor lets you check the status
of a hosted anchor (including error handling messages).
Resolving a previously hosted anchor
When another user in the same environment points their device camera at the area where the Cloud Anchor was hosted, a resolve request (ArSession_resolveAndAcquireNewCloudAnchor()) causes the ARCore Cloud Anchor API service to periodically compare visual features from the scene against the 3D feature map that was created, which ARCore uses to pinpoint the user’s position and orientation relative to the Cloud Anchor. This is why it is important to use the 30 seconds preceding the hosting request to map as much of the environment around the center of interest as possible.
Using the same or different device than the hosting device, follow these steps to resolve the hosted anchor.
Wait a few seconds after the session starts to give tracking time to stabilize before attempting to resolve an anchor.
In the same environment as the hosted anchor, scan the original area of interest, ensuring that:
The device camera has a clear line of sight to mapped area
The device camera is a similar distance from the hosted anchor as the device that originally hosted the anchor.
ARCore continuously polls the ARCore Cloud Anchor API, sending visual data to the ARCore Cloud Anchor API service.
The ARCore Cloud Anchor API service compares visual features from the scene against the 3D feature map that was created. When it finds a match, the service returns the pose of the Cloud Anchor.
The Cloud Anchor should resolve.
ArSession_hostAndAcquireNewCloudAnchorlets you check the status of a hosted anchor (including error handling messages).
Cloud Anchor privacy requirements
To comply with our updated privacy requirements for using ARCore SDKs 1.12 or later, you must disclose the use of Cloud Anchors prominently. For details, refer to User privacy requirements.
Data storage and access limitations
Cloud Anchors have the following data storage and access limitations:
Cloud Anchors can be resolved for 24 hours after they are hosted.
Visual data uploaded to the cloud when hosting an anchor is discarded within twenty-four hours.
Anchors are resolved on the server against the 3D feature map.
Previously uploaded visual data is never sent to a user's device.
Best practices for a good user experience
The following best practices help create a good Cloud Anchors user experience.
Remember that initiating the host call uses the preceding 30 seconds of mapping to create the 3D feature map. Make sure that your app's user interface takes this into account.
Consider creating actions or features that are fun or could be of use to users (or both) when users are moving around the center of interest, and that that also accomplishes the task of creating a proper 3D feature map.
Avoid hosting or resolving Cloud Anchors on certain kinds of surfaces.
- For best results, users should avoid reflective surfaces or surfaces without visual features, such as a blank, smooth, white wall.
Make sure that the lighting in the room is sufficient.
To start using Cloud Anchors, see the Cloud Anchors Quickstart.
If you are new to working with anchors, see Working with Anchors for an introduction.