Does the spatial anchor map benefit from varying the anchor height?

[genereddick]

When I use the visualization tools I tend to walk around a space with the device, hand held or head mounted, at a steady height. This distributes the anchors evenly around the room in an x, z plane but with no variance in y / height. If the device is going to stay at that height the entire time, presumably this is sufficient for interpolation between anchors?

However, as we want to have anchors around the areas where devices/users will be, in a case where the device/user might get down on the floor, or perhaps lifted into the air (on a crane for example), does this imply that, for greater accuracy, we should extend the scan area to floor height and above the highest point they will ascend?

[fast-slow-still]

we should extend the scan area

Could you define "the scan area" in this context? Do you mean where you point your phone at to scan the environment? Or do you mean where WLT deploys its internal graph of anchors? Or something else entirely?

[genereddick]

In this case I mean where the WLT deploys its internal graph of anchors.

While new anchors are placed as you move around you can be outside of an area where anchors have been placed until you move far enough away (~1m) to trigger a new anchor to be dropped. I assume that the the anchor positions (as shown by the visualizer) are significant in that, when the device is in the areas between the anchors, it will be more stable than when in areas outside.

I am envisioning a case where I move around a space and the WLT creates an anchor graph at eye level. I place an asset on the floor and then I lower my head/device so that I am closer to the floor but not close enough to trigger another anchor creation. And then I stand on a chair so that I'm now above the eye level internal anchors but, again, not high enough to create another anchor.

Would I gain anything (in terms of the accuracy of the position of the floor asset) by making sure that internal anchors are positioned below and above my head positions in each of those cases?

As another example, in the case of a 3 meter cubic room, where you might end up everywhere in the room (corners, walls, floor, middle, etc), would you, ideally, want to make sure that the internal anchor graph has created 27 anchors at each 1 meter junction? Does it matter if this is done in advance -- so pre-scanning the space -- or can you rely on the creation of the anchors as you move around?

[fast-slow-still]

The short answer is that I don't believe you would get better quality world-locking by increasing the density of the internal spatial anchor graph, but you can easily experiment for yourself using the Min New Anchor Distance and Max Anchor Edge Length parameters.

[fast-slow-still]

My reasoning is two-fold. First, you never want to create a spatial anchor away from where you are, because the Unity spatial anchor (WorldAnchor, XRAnchor, ARAnchor) is not the real anchor. The real anchor is wherever the device thinks it can reliably place an anchor, which will generally be near the device. So if you create an XRAnchor 3 meters away, you are (conceptually) really creating an anchor where you are with a 3 meter long lever arm.

As far as I know, the exact relationship between the spatial anchor you request and the underlying real anchor is platform dependent, undocumented, and not to be relied on. Tweaking your algorithm for exact placement of spatial anchors is a waste of time when the underlying anchor provider subsystem can just hang all your XRAnchors off the same real anchor.

(When I say real anchor, I'm talking about the platform implementation of feature points and connectivity that allows an anchor to maintain its position in physical space.)

Unfortunately, public APIs are not available for querying the "real anchors".

[fast-slow-still]

would you, ideally, want to make sure that the internal anchor graph has created 27 anchors at each 1 meter junction? Does it matter if this is done in advance -- so pre-scanning the space -- or can you rely on the creation of the anchors as you move around?

A uniform 2d or 3d grid is generally not a good spacing for the internal anchor graph, for reasons discussed above, and other subtle issues.

In general, you will get better quality results if you pre-scan the space to let the device build up its own internal tracking state (not WLT's internal anchor graph, the device has its own). That's not necessary, and certainly isn't always possible, but where possible it will usually give better tracking quality, and I can't think of any situation where it would give worse quality.

Likewise, if you are able to let WLT build up its internal graph ahead of time, then at least you don't have to worry about refit events.

In general, applications will do well to just rely on the device scanning the space and the WLT internal anchors getting created as you move around. But yes, if you want to push the boundaries on accuracy, pre-scanning can be a useful tool.