Hierarchy of Spatial Anchors

Hi
the documentation mentions that GameObjects should be within 3 meters distance of their spatial anchors. This is especially true for grouped objects (in hierarchy objects).

I have a situation where I have a hierarchy where i place the parent and the children by tapping, and the children are about 2-3 meters away from the parent GameObject.

If I put only one Spatial Anchor on the Parent GameObject I fear for diminished accuracy. Some children are very close to 3 meters away.

Can I put Anchors both on the Parent and the children? Are anchors in a hierarchy allowed?
I am unsure how to proceed.

Thanks
Dimi

Tagged:

Best Answer

Answers

  • According to Unit doc an anchor overrides its parent transform.

    World Anchors override their parent GameObject’s Transform component, so any direct manipulations of the Transform component are lost. Similarly, GameObjects with World Anchor components should not contain Rigidbody components with Dynamic physics. These components can be resource-intensive and affect game performance, so ensure that you use only a small number of Anchor components. For example, a game board surface placed upon a table only requires a single Anchor for the board; child GameObjects of the board do not require their own World Anchor.

    So you might be correct about the flat hierarchy. I am not sure what you are proposing though. Are you proposing to reparent the children the top of the hierarchy one they are placed? remove them from having a parent?

    Thanks
    Dimi

  • stepan_stulovstepan_stulov ✭✭✭
    edited January 2017

    On Unity doc. Yes, basically once you delegate taking care of you game object's transform to a world anchor you agree to not interfere yourself. It's either or. But that has nothing to do with parenting. It's simply stating the exclusivity of the API in use, you cannot combine.

    On flatness. By flat hierarchy I meant that you cannot have world anchors (unrelated to Unity's scene) build up a hierarchy. It's a flat list with named elements.

    Now keeping both facts in mind you kind of have a conflict or using anchors on parents and children simultaneously. This is not a bug, it's rather a conceptual conflict, if you ask me. You want to simultaneously control child's transform by its parent (due to the very definition of parenting) and by anchor (due to anchoring). Why? Avoid this conflict. Simply don't have the children "childed" to the parent when driven by an anchor. Or don't drive them by an anchor when they're parented to something.

    To be honest I fail to imagine the use case of having parent and children all be anchored. Would you like to describe it in detail? You need to either re-design your approach or separate the two APIs in time.

    Hope this helps.

    Building the future of holographic navigation. We're hiring.

  • stepan_stulovstepan_stulov ✭✭✭
    edited January 2017

    About these 2-3 meters recommendation. To my opinion this is the most misunderstood tip from Microsoft/Unity. Or rather, it's understood too literally.

    When you attach an anchor to a game object, HoloLens takes care of keeping that object's pivot point as stable as possible to its nearest spatial/topological surrounding. Accent on "pivot" and "nearest". This has nothing to do with the visual content of your game object. It can be anything as well as nothing, near or far. HoloLens "doesn't care". You metaphorically tell it "please keep this point stable and I will decide what to show there".

    Now if you place the object's visual content too far away from its pivot point your eye will naturally compare that content's stability against the spatial environment behind that content. And that, not-so-near-anymore spatial environment's part may "swim" relative to the one that's near. So what happens is your eye now compares visual content against something that the HoloLens never promised to be stable relative to. Your eye respects no pivots points, so to say. So it's unstable. Visually. My personal advice here is simply having pivots of your holograms in their centres of mass.

    Parenting has nothing to do with this recommendation.

    Building the future of holographic navigation. We're hiring.

  • Hi
    thanks for the info.
    Here is a use case for you about the need of a hierarchy.
    Imagine a car body (parent) which has car parts (wheel, rims, racks) as children.
    When i align the car (move rotate) etc I only move the parent (one script attached).
    All other accessories/parts follow automatically.
    The car body (parent) center of mass is quite some units away from some accessories. For example on a real car of 5 meter a rear rack is 2.5 m. away from the car body center.

    How do you anchor the car-body + car accessories in this scenario. Since all are holograms. I could cancel the hierarchy and have it flat, but this is counter-intuitive and not productive. This exact scenario is why hierarchies in Unity are supported.

    About the distance rule of 2-3 meters. I imagine Microsoft has probably figured out that when below 3 meters the discrepancies are small between anchored and unanchored content. Thanks for this info though, this was not what i expected it to be doing.
    In essence you say a anchored hologram more than 3 meters away is stable, and appears only unstable because of the other unanchored environment that might be around it and might swim.

    I will resolve to just using 1 anchor on the car body for now.

    Thanks Again
    Dimi

  • In that car scenario, you would really only want one spatial anchor for the parent object. That way all the wheels and other parts keep their spatial relationships with the car, and the car as a whole is positioned relative to its spatial anchor. I think the other thing is that the car's main pivot would be near the spatial anchor, and that's the important thing. (Or at least as important as the rest of the car moving together like one solid object).

  • Another idea I haven't seen discussed is to create multiple spatial anchors and average them. The documentation for spatial anchors lists the "lever arm effect" as one of big problems with placing an object far from its spatial anchor. Simply put, if you are close to the origin, then a 1 degree change in rotation results in a small distance traveled (its 0 at the spatial origin). The further you are from the origin, however, the bigger the arc, and the larger the error becomes.

    So my idea for large objects (and I have no idea if or how well this would work), is to create multiple spatial anchors, for example, one located at each tire, and position the car using a script relative to the centroid of those 4 anchors, and to average their rotations as well.

    I'm not sure if this would work any better than the single anchor, but it might be worth trying anyway.

  • stepan_stulovstepan_stulov ✭✭✭
    edited February 2018

    Hey, @christop

    How do you anchor the car-body + car accessories in this scenario. Since all are holograms. I could cancel the hierarchy and have it flat, but this is counter-intuitive and not productive. This exact scenario is why hierarchies in Unity are supported.

    I believe my flat hierarchy essay was misunderstood. I apologise for that. Nobody is saying you have to abandon the parenting mechanism of Unity altogether simply because you're now working with HoloLens. What I meant is you're don't want children with anchors inside of a parent with an anchor. That would simply have two different positioning systems working in parallel /conflicting which you don't want. Perhaps this thread will explain that idea a bit better:

    https://forums.hololens.com/discussion/7488/world-anchors-in-hierarchies

    Another thing I meant by flat hierarchy of anchors is that anchors can only be persisted in WorldAnchorStore or WorldAnchorTransferBatch in a flat list. You cannot save anchors as children or parents of another anchors. Anchors don't have their own concept or parenting.

    About the distance rule of 2-3 meters. I imagine Microsoft has probably figured out that when below 3 meters the discrepancies are small between anchored and unanchored content. Thanks for this info though, this was not what i expected it to be doing.

    This is not about anchored vs unanchored content. This is about your eye detecting poor visual content's stability against an area of the environment that you did not ask the HoloLens to stabilise against. Simply put, you say "Mr. HoloLens, please keep this point stable against my table". And it does! Both positionally and rotationally, with deviations of course. It's this rotational deviations that's the problem. You now show the visual content of your anchored object not near your table, but 5 meters away at your colleague's table. Slight jumps in rotation of the anchor now result in bigger jumps positionally, because one degree jitter near the centre is not as prominent for your eye as one degree jitter miles away from it. It's just the nature of rotation, nothing to do with anchors so to say. Get a big beam, put it on a fulcrum and start rocking it. Part of the beam near the fulcrum will positionally travel just a bit. Part of the beam furthest away from the fulcrum will positionally travel the biggest distance. That is what they call leverage effect.

    Another problem of course is when you look away from the environment that HoloLens stabilises against, stability drops. Perhaps that's done to preserve performance (a'la tracking culling). Such looking away is expected when you show your visual content not there, where HoloLens needs to be looking to keep things anchored. After all humans look at that which is shown to them.

    In essence you say a anchored hologram more than 3 meters away is stable, and appears only unstable because of the other unanchored environment that might be around it and might swim.

    Not the "anchored hologram more than 3 metres away" but an "an anchored hologram whose content is more than 3 metres away from its pivot/origin". Not sure what you mean by "appears only unstable because of the other unanchored environment that might be around it and might swim". Environment cannot be anchored or unanchored. Holgorams are anchored to the environment. Environment just is.

    About your car. I believe you bumped into a seeming conflict, where you want to drag the whole car as one, but anchor its subparts individually because such anchoring will be more stable locally. Then simply do so! Unanchor everything, drag the car as whole and then, when dropping it, add new anchors to car parts individually. One thing you need to not forget is to have some kind of default layout of parts within the car so that when unanchoring you can correct back any possible errors that anchors could introduce over time due to drifting. Anchors may have slightly "disassembled" your car.

    You don't have to preserve the same hierarchy paradigm all the time. You're free to reshuffle.

    The proposal by @thebanjomatic with averaging the anchors is another great idea.

    Hope this helps.

    Building the future of holographic navigation. We're hiring.

Sign In or Register to comment.