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.
Hololens Spatial Anchor Sizes
I'm working on a script to share anchors between Hololenses and have been having some trouble with the sizes of the anchors. It varies but I've measured the anchors to be around 160mb . The most I can get out of the Low-Level API TransportNetwork that Unity uses is around 1000 bytes per transfer. With transferbatches approaching 0.2 GB, the time to transfer an anchor is more easily measured in minutes or hours rather than seconds. In fact, I've yet to successfully transfer a sign anchor because of this. Am I mismeasuring the anchor somehow? If not, what determines the transferbatch's size? Any advice on how to approach this issue?
Best Answer
-
stepan_stulov ✭✭✭
I've been searching for a way to specify a smaller area or to programatically clear the "Space" from the Hololens when the app starts.
I'm afraid spaces are system-level data, not app-level. It would really be bad otherwise if one app would mess up the space for other apps. There is no (known to me) API to read or write space information. You only have access to the spatial mapping, which is a lossy derivative.
I've already got a system for cutting up the data, but the largest piece I have been able to convince it to send is ~1000 bytes.
I'm afraid you have to really fire up that many messages, unless you use some alternative networking API.
I've seen some signs suggesting that the "Space" that the Hololens is building as it scans the environment is fully exported when you serialize a TransferBatch, rather than just the area surrounding the anchor.
I never thought about entire space being packed into the transfer batch, but now that you said you I'm thinking it could be true. I always thought it only packs the necessary sub-space, but that was not based on any particular evidence.
Any further advice based on this information?
Only the ones I've suggested to maybe decrease the frequency of delivering the new anchors. Maybe you delivery the heavy anchor-based grid first and then only deliver lightweight non-anchor-based relative coordinates whenever edited given the grid didn't change. There is not much you can do about the size of the batch I'm afraid. I mean you can always clean up the space from the settings and only scan one corner but that's dorky and unreliable.
Building the future of holographic navigation. We're hiring.
1
Answers
Hey, @tjmarshall
You are not alone.
There are two ways to go from here.
Building the future of holographic navigation. We're hiring.
@stepan_stulov Thank you so much for your answer. I just want to clarify a few points. I'm reaching sizes of 160 mb or more with a single anchor. I've already got a system for cutting up the data, but the largest piece I have been able to convince it to send is ~1000 bytes. This is using the NetworkTransport LLAPI with a reliable channel. I've seen some signs suggesting that the "Space" that the Hololens is building as it scans the environment is fully exported when you serialize a TransferBatch, rather than just the area surrounding the anchor. I've been searching for a way to specify a smaller area or to programatically clear the "Space" from the Hololens when the app starts. Serializing the entire "Space" to transfer one anchor will cause serious usability issues for what needs to be a "plug and play" tool. Any further advice based on this information? Thank you again.
I'm afraid spaces are system-level data, not app-level. It would really be bad otherwise if one app would mess up the space for other apps. There is no (known to me) API to read or write space information. You only have access to the spatial mapping, which is a lossy derivative.
I'm afraid you have to really fire up that many messages, unless you use some alternative networking API.
I never thought about entire space being packed into the transfer batch, but now that you said you I'm thinking it could be true. I always thought it only packs the necessary sub-space, but that was not based on any particular evidence.
Only the ones I've suggested to maybe decrease the frequency of delivering the new anchors. Maybe you delivery the heavy anchor-based grid first and then only deliver lightweight non-anchor-based relative coordinates whenever edited given the grid didn't change. There is not much you can do about the size of the batch I'm afraid. I mean you can always clean up the space from the settings and only scan one corner but that's dorky and unreliable.
Building the future of holographic navigation. We're hiring.
Thanks @stepan_stulov . Sounds like there are still quite a few obstacles to overcome even in the best of cases. I'll go ahead and mark your post as the answer, but to anyone else that reads this, feel free to add further input and if I break any new ground I'll add it here so that others having the same issue can find it.