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.
How exactly is WorldAnchorTransferBatch serialized?
I have just ran a very interesting test on how the size of a WorldAnchorTransferBatch (namely its serialized bytes) depends on the number of anchors encoded into it. I ran a series of tests where in which I would create N little sphere evenly distributed around the camera, each have a WorldAnchor attached to it, then all anchored recorded into a freshly instantiated WorldAnchorTransferBatch and finally serializing that batch into bytes and displaying the size of it.
I was amused to see that the dependency between is not particularly a linear function, let alone constantly growing. Check this log:
Serialized 1 balls into 18171377 bytes.
Serialized 2 balls into 28671999 bytes.
Serialized 3 balls into 35462503 bytes.
Serialized 4 balls into 35922993 bytes.
Serialized 5 balls into 40444423 bytes.
Serialized 6 balls into 39034393 bytes.
Serialized 7 balls into 46405887 bytes.
Serialized 8 balls into 47810489 bytes.
Serialized 9 balls into 46505143 bytes.
Serialized 10 balls into 48633108 bytes.
Serialized 11 balls into 46947059 bytes.
Serialized 12 balls into 49880005 bytes.
Serialized 13 balls into 51336371 bytes.
Serialized 14 balls into 50499936 bytes.
Serialized 15 balls into 50331198 bytes.
Serialized 16 balls into 49725136 bytes.
Serialized 17 balls into 50109292 bytes.
Serialized 18 balls into 50206014 bytes.
Serialized 19 balls into 50137468 bytes.
Serialized 20 balls into 51161167 bytes.
Serialized 21 balls into 49962236 bytes.
Serialized 22 balls into 50263111 bytes.
Serialized 23 balls into 50160096 bytes.
Serialized 24 balls into 49826676 bytes.
It's interesting to witness that sometimes more balls means slightly smaller batch size.
This, in a purely speculative fashion, makes me think there must be a collection of some kind of tracking/feature points that are being re-used by the world anchors and after a certain moment (especially in case of an even distribution on a spherical surface around the head) adding new anchors adds little overhead.
I would like you guys to shed some light on how the transfer batches are serialized conceptually. Additionally are there any size optimization techniques that could help me decrease the size of the serialized batch? And finally I'd like to know how, when a transfer batch is given to another HoloLens in the same room, that HoloLens would compare some else's anchors against own spatial mapping and ensure their positioning.
Thank you very much for taking time for definitive answers!
Building the future of holographic navigation. We're hiring.