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 (ArSession_hostAndAcquireNewCloudAnchor()).
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.
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 service creates a 3D feature map of the space, and returns a unique Cloud Anchor ID for the anchor to the device.
Use
ArSession_hostAndAcquireNewCloudAnchorto 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.
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 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.
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.
Call
ArSession_resolveAndAcquireNewCloudAnchor()and useArSession_hostAndAcquireNewCloudAnchorto periodically check the status of the resolve request.If you want to cancel your request, call
ArAnchor_detach.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.
ArSession_hostAndAcquireNewCloudAnchor lets you check the
status of a hosted anchor (including error handling messages). When you are
done with the Cloud Anchor, call
ArAnchor_detach.
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.
Deprecation policy
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.
Get started
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.