-
Notifications
You must be signed in to change notification settings - Fork 103
Description
Hi,
I was previously using ARCore Extensions 1.37 and could create geospatial anchors at runtime by adding a ARGeospatialCreatorAnchor to my prefab and assigning its lat/lng/alt values:
ARGeospatialCreatorAnchor creatorAnchor = prefab.AddComponent();
creatorAnchor.Latitude = (double)decimal.Parse(data.lat, CultureInfo.InvariantCulture);
creatorAnchor.Longitude = (double)decimal.Parse(data.lng, CultureInfo.InvariantCulture);
creatorAnchor.Altitude = data.altitude;
creatorAnchor.AltType = ARGeospatialCreatorAnchor.AltitudeType.ManualAltitude;
This worked reliably and the prefab always appeared at the correct location.
New behaviour with ARCore Extensions 1.50
After upgrading to 1.50, I switched to the recommended runtime API:
double latitude = (double)decimal.Parse(data.lat, CultureInfo.InvariantCulture);
double longitude = (double)decimal.Parse(data.lng, CultureInfo.InvariantCulture);
double altitude = data.altitude;
ARGeospatialAnchor anchor = ARAnchorManagerExtensions.AddAnchor(
anchorManager,
latitude,
longitude,
altitude,
Quaternion.identity);
prefab.transform.SetParent(anchor.transform, false);
❗ Observed issues
• Anchor creation feels slower than in 1.37.
• In many cases the anchor is created (not null) but the prefab does not appear on screen.
• Sometimes it appears late or at an unexpected location.
• Overall behaviour is less reliable and more random than before.
• Same project, same devices, same coordinates — only ARCore Extensions version changed.
Questions
1. Is this expected? Has something changed internally in how geospatial anchors are resolved in 1.50?
2. Is AddAnchor() known to be less stable than the previous ARGeospatialCreatorAnchor runtime usage?
3. Am I missing a new required step in 1.50 (Earth tracking state, timing, readiness)?
4. Could this be a regression?