Hello everyone.

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_stulovstepan_stulov ✭✭✭
    Answer ✓

    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.

Answers

  • stepan_stulovstepan_stulov ✭✭✭
    edited August 2017

    Hey, @tjmarshall

    You are not alone.

    There are two ways to go from here.

    1. You can keep you anchor transfer batches big and simply implement the network batching, like sending multiple messages. I guess you're doing it already. You can also increase message sizes, but certainly not to 0.2GB. Slicing is inevitable with Unity networking.
    2. Rethink your anchoring mechanism. There is no clearly documented dependency of how anchors, their number and their proximity to each other influence the size of the transfer batch. But empirically I have noticed that the bloated transfer batches are those that have anchors that are far from each other and have very different visual background to be tracked against. While anchors that are close to each other, in mere centimetres, seem to share some tracking information and adding more anchors in the same neighborhood doesn't seem to impact the transfer batch size significantly. If your case the former, you may be more or less out of luck unless you rely on additional world clues like the VuMarks and derive your tuntime anchors from it. If your case is the latter then your batch size shouldn't be that big anyway. Additionally you can think if you really need that many anchors. Perhaps store very few anchors as kind of a grid and actual coordinates relative to them. Finally, what hurts is transferring those anchors every time. Perhaps that's unnecessary and you can only transfer them when they're really updated. And maybe only on demand. Kinda of like your optional Windows Updates or like game DLCs. Good to have but will work without.

    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.

  • stepan_stulovstepan_stulov ✭✭✭
    Answer ✓

    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.

  • 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.

Sign In or Register to comment.