SPECIFIC ISSUE ENCOUNTERED
ARCore can start an AR session with a good world estimate, then randomly revise that estimate several seconds later.
Before the revision, tracking works normally. The detected floor is accurate and metrically correct + camera poses are usable.
When the revision happens, ARCore changes the detected plane or world estimate. ARCore continues to report normal tracking throughout the event. The plane remains detected and its pose remains available.
The revised estimate is wrong. Physical distances calculated from the new poses change even though nothing in the physical scene moved. In the failure cases observed, the revision never repaired the estimate, it could only make it worse.
This creates two failure modes for applications:
- An application that keeps reading the live plane pose sees its measurements jump when ARCore revises the map.
- An application that creates an anchor after the revision captures the bad world state and receives measurements that are stable but wrong.
There is no exposed confidence value or tracking-state transition that warns the application before this happens. A bad revised state can report the same normal tracking state, plane extent, and pose availability as the original good state.
Reproduced this through Chrome WebXR and through a native Android application. Also reproduced it on both a high-end Samsung phone and an older Motorola phone. The shared component is ARCore.
Expected behavior is that ARCore preserves or improves physical distances when it refines its map. If it cannot do that, it should report limited tracking or expose a signal that tells the application the current metric estimate is unsafe.
Actual behavior is that ARCore replaces a good metric estimate with a bad one while continuing to report normal tracking.
VERSIONS USED
- Android Studio: Android Studio Quail 3
- ARCore SDK for Android: Chrome uses Chromium 150's ARCore backend. The native comparison used ARCore 1.54.2.
- Device manufacturer, model, and O/S:
- Samsung Galaxy S24 Ultra, Android 16.
- Motorola g(7), Android 10.
- Google Play Services for AR (ARCore):
Samsung runtime build number: 1.54.260890093.
- samsung/e3quew/e3q:16/BP4A.251205.006/S928U1UES6DZG1:user/release-keys
STEPS TO REPRODUCE THE ISSUE
- Start an ARCore session with horizontal plane detection. The issue reproduces through both native ARCore and Chrome WebXR.
- Move the phone until ARCore reports normal tracking and detects a horizontal floor plane.
- Record the camera pose and plane pose.
- Confirm the initial metric estimate against a known physical distance. The initial estimate can be correct.
- Keep the same AR session active and move the phone normally around the scene.
- Continue logging the camera and plane poses. On affected initializations, ARCore eventually revises the plane or world map without reporting tracking loss.
- Compare the same known physical distance before and after the revision. The calculated distance changes even though the physical scene did not move.
- Repeat with an anchor created only after the revision. That anchor captures the revised world state and produces a stable but incorrect metric result.
The result is surprisingly consistent in its occurence but not in how variable it is.
WORKAROUNDS (IF ANY)
This current workaround captures the initial good state before ARCore has time to revise it.
Start a timer on the first real AR frame. If ARCore detects the complete required floor area (this uses the check of 9/9 floor hits within a 75% middle section of the screen) within seven seconds, then create a free session anchor immediately and store the first Y value returned for that anchor. Keep that number in application state and ignore every later pose update for measurement.
If ARCore does not detect the complete floor within seven seconds, reject the session and start a fresh ARCore session. Never create an anchor from the late estimate.
The seven-second limit is an empirical application workaround. It is not an ARCore confidence threshold. It relies on this fact: the destructive revisions occurred later than the initial floor detection in testing. Even the Motorola g(7), almost the lowest-spec ARCore-compatible device, can detect the complete floor within seven seconds under adequate lighting.
This workaround has prevented the severe metric failures in testing but does not solve the underlying ARCore problem.
ADDITIONAL COMMENTS
Waiting for ARCore to finish refining does not help because the revised state is the bad state.
Plane age, plane size, stable pose, polygon updates, plane identity, full plane coverage, and anchor availability do not predict the failure. They can all look normal before and after the revision.
This is not caused by Three.js or WebXR coordinate conversion. An independent implementation using the raw WebXR matrices produced the same coordinates. The native Android path also reproduced the issue.
The problem is also NOT that ARCore refines its map. The problem is that it universally replaces a correct physical estimate with an incorrect one while tracking reports remain normal.
It's also worth noting that ARKit doesn't have this problem.
SPECIFIC ISSUE ENCOUNTERED
ARCore can start an AR session with a good world estimate, then randomly revise that estimate several seconds later.
Before the revision, tracking works normally. The detected floor is accurate and metrically correct + camera poses are usable.
When the revision happens, ARCore changes the detected plane or world estimate. ARCore continues to report normal tracking throughout the event. The plane remains detected and its pose remains available.
The revised estimate is wrong. Physical distances calculated from the new poses change even though nothing in the physical scene moved. In the failure cases observed, the revision never repaired the estimate, it could only make it worse.
This creates two failure modes for applications:
There is no exposed confidence value or tracking-state transition that warns the application before this happens. A bad revised state can report the same normal tracking state, plane extent, and pose availability as the original good state.
Reproduced this through Chrome WebXR and through a native Android application. Also reproduced it on both a high-end Samsung phone and an older Motorola phone. The shared component is ARCore.
Expected behavior is that ARCore preserves or improves physical distances when it refines its map. If it cannot do that, it should report limited tracking or expose a signal that tells the application the current metric estimate is unsafe.
Actual behavior is that ARCore replaces a good metric estimate with a bad one while continuing to report normal tracking.
VERSIONS USED
Samsung runtime build number:
1.54.260890093.STEPS TO REPRODUCE THE ISSUE
The result is surprisingly consistent in its occurence but not in how variable it is.
WORKAROUNDS (IF ANY)
This current workaround captures the initial good state before ARCore has time to revise it.
Start a timer on the first real AR frame. If ARCore detects the complete required floor area (this uses the check of 9/9 floor hits within a 75% middle section of the screen) within seven seconds, then create a free session anchor immediately and store the first Y value returned for that anchor. Keep that number in application state and ignore every later pose update for measurement.
If ARCore does not detect the complete floor within seven seconds, reject the session and start a fresh ARCore session. Never create an anchor from the late estimate.
The seven-second limit is an empirical application workaround. It is not an ARCore confidence threshold. It relies on this fact: the destructive revisions occurred later than the initial floor detection in testing. Even the Motorola g(7), almost the lowest-spec ARCore-compatible device, can detect the complete floor within seven seconds under adequate lighting.
This workaround has prevented the severe metric failures in testing but does not solve the underlying ARCore problem.
ADDITIONAL COMMENTS
Waiting for ARCore to finish refining does not help because the revised state is the bad state.
Plane age, plane size, stable pose, polygon updates, plane identity, full plane coverage, and anchor availability do not predict the failure. They can all look normal before and after the revision.
This is not caused by Three.js or WebXR coordinate conversion. An independent implementation using the raw WebXR matrices produced the same coordinates. The native Android path also reproduced the issue.
The problem is also NOT that ARCore refines its map. The problem is that it universally replaces a correct physical estimate with an incorrect one while tracking reports remain normal.
It's also worth noting that ARKit doesn't have this problem.