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 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 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 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 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 (
Beginning in ARCore SDK 1.12.0, 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 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 local 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.
ARAnchorManager.HostCloudAnchorto initiate the hosting request.
ARCore uploads visual data, device poses, and the anchor pose via the ARCore Cloud Anchor API.
The ARCore Cloud Anchor service creates a 3D feature map of the space, and returns a unique Cloud Anchor ID for the anchor to the device.
CloudAnchorStateto check the status of a hosted anchor (including error handling messages).
The ARCore Cloud Anchor service creates a 3D feature map of the space, and returns a unique Cloud Anchor ID to the device.
The anchor should be hosted.
CloudAnchorState 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
ARAnchorManager.ResolveCloudAnchorId) causes the ARCore
Cloud Anchor 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.
You can initiate resolves for multiple Cloud Anchors in sequence. Up to 20 Cloud Anchors can be resolved simultaneously.
Using the same or different device than the hosting device, follow these steps
to resolve the hosted anchor. The host can retrieve and share the ID using the
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 service.
The ARCore Cloud Anchor 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.
CloudAnchorStateof the resolved Cloud Anchor until it reports ready, or reports an error.
Cloud Anchor privacy requirements
To comply with our updated privacy requirements for using ARCore SDKs 1.12.0 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:
In ARCore 1.20 and later, Cloud Anchors can be resolved for 365 days after they are hosted. (In versions of ARCore earlier than 1.20, Cloud Anchors could be resolved only for 24 hours after they were hosted.) You can extend the lifetime of the anchor after it is already hosted using the Cloud Anchor Management API.
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.
Apps built with ARCore SDK 1.12.0 or higher are covered by the Cloud Anchor API deprecation policy.
Apps built with ARCore SDK 1.11.0 or lower are unable to host or resolve Cloud Anchors due to the SDK's use of an older, deprecated ARCore Cloud Anchor service.
If you are new to working with anchors, see Working with anchors for an introduction.
To start using Cloud Anchors for ARCore Extensions, see the: