The Mixed Reality Forums here are no longer being used or maintained.
There are a few other places we would like to direct you to for support, both from Microsoft and from the community.
The first way we want to connect with you is our mixed reality developer program, which you can sign up for at https://aka.ms/IWantMR.
For technical questions, please use Stack Overflow, and tag your questions using either hololens or windows-mixed-reality.
If you want to join in discussions, please do so in the HoloDevelopers Slack, which you can join by going to https://aka.ms/holodevelopers, or in our Microsoft Tech Communities forums at https://techcommunity.microsoft.com/t5/mixed-reality/ct-p/MicrosoftMixedReality.
And always feel free to hit us up on Twitter @MxdRealityDev.
World Anchor question
I realize that World Anchors can be stored in a general database called: WorldAnchorStore. What if I store the coordinates of the GameObjects separately that are tagged as having a 'World Anchor' component. When I reload them back in I add a world anchor component to each of those GameObjects that are tagged as WorldAnchors. Presumably this will not give me the same WorldAnchor set as I had earlier. Or would it?
Best Answers
-
Thank you Patrick. I agree with Stepan about the 'confusion' issue here. It is good to know that stores are unique to the application. I did read also about the value of having WorldAnchor components attached rather sparingly to your overall store of spatial data. Apparently these components help to stabilise the data that do not have a WorldAnchor component and to stop them from drifting off. From what I remember they have to be near to a WorldAnchor (about 2 meters). In my experience this has not been the case with my testing. I find that the proximity of WorldAnchors have no or little effect on the drift. However if I save a vector offset to the nearest WorldAnchor and recalculate the position on each Update() this does the trick. However it is plain to see that this is extra computational work here. Have I misunderstood this drifting solution?
6 -
stepan_stulov ✭✭✭
I think there is barely such a thing as anchored object drift based on its distance to the actual anchor, strictly mathematically speaking. Just think about it, this would involve determining where the visual content of your object is, in other words some kind of boundaries, including particles, meshes etc. I don't believe the API does that. The only thing, I believe, the world anchor API does is keeping stability of one point's transform, regardless of its visual contents.
However, I think what is meant in the documentation about the drift and proximity to to the anchor is this. It's not a mathematical drift but a visual one. If you anchor a point then that point is kept most stable to its closest spatial environment. And if you place the visual content of the anchored object way out, then your eye will perceive the stability of that content not against the spatial environment around the anchor but against the spatial environment behind that what you see. You thus break to concept of local stability and make your eye compare against remote spatial environments that are drifting in relation to each other because HoloLens continuously learns about the reality. Hence that whole recommendation of keeping it close.
My personal rule of thumb is just keeping the visual content of an anchored object so that the anchored point / pivot is kind of in the "centre of masses" of the visual content. It's also most predictable for people messing with your Unity scene: you select an object and its centre is in its, well, centre.
Building the future of holographic navigation. We're hiring.
6
Answers
I think your confusion is justified as the process of saving the world anchors and the process of loading them back are extremely asymmetrical. One is trying to be overly helpful while another is leaving you to do all the manual work yourself.
What worked for me is this, from within each individual anchored object's script.
Loading:
_worldAnchorStore.Load(_worldAnchorId, gameObject)
Anchoring:
WorldAnchor worldAnchor = gameObject.AddComponent();
if (_worldAnchorStore.GetAllIds().ToList().Contains(_worldAnchorId))
_worldAnchorStore.Delete(_worldAnchorId);
_worldAnchorStore.Save(_worldAnchorId, worldAnchor);
Unanchoring:
GameObject.DestroyImmediate(gameObject.GetComponent());
_worldAnchorStore.Delete(_worldAnchorId);
I wish they made the "philosophy" behind anchoring more consistent.
Building the future of holographic navigation. We're hiring.
Thank you Stepan for the quick reply and suggestion. Is it correct to say that all your WorldAnchor positions for all the applications are stored in a single WorldAnchorStore on the HoloLens and each WorldAnchor is only identifiable by a unique name you give it as in _worldAnchorId in your explanation? I apologize if this is so obvious.
Each application has its own store, and the anchors are referenced by the name you give the anchor when you save it to the store.
===
This post provided as-is with no warranties and confers no rights. Using information provided is done at own risk.
(Daddy, what does 'now formatting drive C:' mean?)
Thank you Patrick. I agree with Stepan about the 'confusion' issue here. It is good to know that stores are unique to the application. I did read also about the value of having WorldAnchor components attached rather sparingly to your overall store of spatial data. Apparently these components help to stabilise the data that do not have a WorldAnchor component and to stop them from drifting off. From what I remember they have to be near to a WorldAnchor (about 2 meters). In my experience this has not been the case with my testing. I find that the proximity of WorldAnchors have no or little effect on the drift. However if I save a vector offset to the nearest WorldAnchor and recalculate the position on each Update() this does the trick. However it is plain to see that this is extra computational work here. Have I misunderstood this drifting solution?
I think there is barely such a thing as anchored object drift based on its distance to the actual anchor, strictly mathematically speaking. Just think about it, this would involve determining where the visual content of your object is, in other words some kind of boundaries, including particles, meshes etc. I don't believe the API does that. The only thing, I believe, the world anchor API does is keeping stability of one point's transform, regardless of its visual contents.
However, I think what is meant in the documentation about the drift and proximity to to the anchor is this. It's not a mathematical drift but a visual one. If you anchor a point then that point is kept most stable to its closest spatial environment. And if you place the visual content of the anchored object way out, then your eye will perceive the stability of that content not against the spatial environment around the anchor but against the spatial environment behind that what you see. You thus break to concept of local stability and make your eye compare against remote spatial environments that are drifting in relation to each other because HoloLens continuously learns about the reality. Hence that whole recommendation of keeping it close.
My personal rule of thumb is just keeping the visual content of an anchored object so that the anchored point / pivot is kind of in the "centre of masses" of the visual content. It's also most predictable for people messing with your Unity scene: you select an object and its centre is in its, well, centre.
Building the future of holographic navigation. We're hiring.
Thank you Stepan for your long and informative comment. I know it's very challenging to use stereographic and polychromatic content only to locate where you are. Thomas Whelan, amongst others has done some great stuff on the Kinect device doing 3D surveying of buildings. The accuracies he gets are quite awesome. When you have a bunch of noisy and sometimes inaccurate information coming in at a high frequency (say 60 Hz as in HoloLens) you can process meaningful stuff out of that heap of data. In 1953 a chap called Metropolis (actually it was his wife and friends) developed a way of processing noisy data like this and it is one of the most important algorithms of the 20th century apparently. At the HoloLens The HoloLens is a better hardware frame than the Kinect and it has, in my view, an exciting future on the professional side as well as the gaming side. We are just in at the very beginning of great parallelism and new techniques of how to deal with the volume of it in a meaningful way.
For my part, I just get so frustrated at the volume of stuff to learn like the new processing methods and to understand it.
Frustrated? Take it as a challenge! Wouldn't it be boring otherwise
Building the future of holographic navigation. We're hiring.