Suggestions for updating the WorldAnchorManager

I am sure the coder had a reason for doing it this way, but if it is just to keep performance good when adjusting a lot of anchors at once, then IMO it is not enough to offset the major problems using a queue causes:

• It is impossible to know the success or failure of an operation as it does not execute when the Attach/Remove call happens.
• It is impossible to know if AttachAnchor was able to load any existing anchor data. This is important if you want to take actions based on whether or not the anchor data exists. For example you may want to hide a GameObject if there is no anchor data, then only create the anchor data if the user issues a command to show the object.
• Code like this doesn’t work since the anchor is not removed in a timely manner to allow the rotation to happen:

WorldAnchorManager.Instance.RemoveAnchor(this.gameObject);
this.transform.Rotate(blah blah blah);
WorldAnchorManager.Instance.AttachAnchor(this.gameObject, this.gameObject.name)

• Stack traces are useless since they go back to WorldAnchorManager.Update and then to Unity internals, instead of to the function in my code that called RemoveAnchor or AttachAnchor.

The queue should be removed, or at least have a switch to turn it off. As an application developer I should have the control to balance performance with the convenience with writing straightforward code like I have above.

In addition there are other problems with WorldAnchorManager which compound this issue:

• If you call AttachAnchor without calling RemoveAnchor the queue processing code throws a duplicate key exception.
• When using SharingWorldAnchorManager, the base functionality is suppressed when not connected to a server. Why can’t it work like WorldAnchorManager when offline? Why can’t it at least give me an error message?
• It is impossible to test WorldAnchorManager withni the Unity Editor (perhaps with the holographic emulator but you need the Hololens on the network for that to work; the Hololens is not yet working on our company network), requiring me to delete the UWP directory (APPX build is broken in HTK v2017.1.1, that is the only workaround I can find), rebuild from scratch, manually use the dev portal to deploy the build (automatic app install has been broken in EVERY HTK version I’ve used), and then test on Hololens. And because of the abysmal Debug performance I have to test with Release which gives me useless stack traces (not that it is any more useless than WorldAnchorManager’s stack traces anyway). WorldAnchorManager should be emulated using PlayerPrefs or something when not on a HoloLens so the developer can better test the functionality.

Honestly if it were up to me I’d deprecate WorldAnchorManager and start from scratch. I think Unity itself is partly to blame though since some of the annoyances come from WorldAnchor (such as being unable to move the GameObjects they are attached to. Why?!?)

[The-MAZZTer]

I should mention I have worked around my issues by making the following modifications to the class (I don’t have the code in front of me right now, sorry):

1. Adding a call to .Update after every .Enqueue on the queue.
2. Changing .Update’s if check on the queue size to a while loop to ensure the entire queue is emptied in one go.

This ensures any call to .AttachAnchor or .RemoveAnchor is immediately executed before the function returns with minimal code modifications, except in the case where AnchorStore is null, in which case the queue will function as normal until AnchorStore is ready and then it will immediately empty.

This is working fine for my purposes. I am not sure about the performance impact of anchor operations so I can’t say if I will need the queue further along in development but for now my approach is working. It resolves the following issues from my first list, assuming the AnchorStore is ready when you call Attach/RemoveAnchor:

• Stack traces are now useful.
• You can write code like the sample I provided above and it works.

Additional changes would be needed to SharingWorldAnchorManager if you’re using that class as it overrides .Update. I haven’t analyzed it yet, though I will need to use this class eventually.

[The-MAZZTer]

Yeah sorry if I come across as a little angry, been trying to get WorldAnchors working with some code that was not built with them in mind for the past couple of days.

Also one thing I forgot to mention is that having so much code disabled in the editor makes it more difficult to edit that code in Visual Studio to modify the class. It would be nice if the amount of code removed by #if directives was minimized. For example, anchors should still be queued up (if the queue is being used) but the actual AnchorStore calls should be stubbed out in the editor, or simulated with PlayerPrefs like I suggested.