[Question] What's the difference between Preserve Gravity Vector and normal space pin behaviour?

[camnewnham]

The 1.5.7 release notes mention a new option to 'preserve gravity vector'.

The default Orienter behaviour is to retain the model up (Y) vector as gravity up (as opposed to OrienterThreeBody which allows 6dof repositioning). Is there a difference between how these work, and is one methodology preferred over the other?

Thanks!

[zantiu]

This is a very welcome option. For example in my testing setup I have 2 spacepins on qr codes positioned opposite the room, but not straight in front of each other. A small error in the qr code scanning tilts my entire coordinate system. And then all the content positioned horizontally in the application, is also tilted.

However since activating this option I at one run where the coordinate system was still tilted. In fact it was tilted in a direction that I hadn't seen before. Maybe there's still a bug in some edge case? But I haven't been able to reproduce yet.

[camnewnham]

@zantiu but isn't this also resolved by using a regular Orienter (instead of an Orienter3Body) and using SpacePin.SetFrozenPosition() instead of SpacePin.SetFrozenPose()? Though with SetFrozenPosition the orientation will not be correct until both codes are scanned.

[fast-slow-still]

@camnewnham , that is correct, the difference between the Orienter and Orienter3Body is exactly that. The Orienter infers an implied rotation about the Y-axis from the different positions of the SpacePins projected onto the horizontal plane. The Orienter3Body allows a full 6-dof rotation to be inferred, once 3 or more space pins have been established.

The new option has no effect on space pins. It only affects the camera correction transform computed by the FrozenWorldEngine based on the internal graph of spatial anchors.

So referring to the teminology on this page:

No Pitch And Roll - If enabled, zero out pitch and roll from the transform from Playspace to Locked space, forcing it to be yaw only correction. Default is NOT enabled.

Orienter/Orienter3Body - If using Orienter, transform from Locked space to Pinned space will have a rotation about Y-axis (yaw only) as inferred from relative positions of space pins projected onto horizontal plane. If using Orienter3Body, rotation from Locked space to Pinned space inferred from relative positions of 3 or more space pins has 3 degrees of freedom.

[camnewnham]

The new option has no effect on space pins. It only affects the camera correction transform computed by the FrozenWorldEngine based on the internal graph of spatial anchors.

Ah, I see. I haven't noticed the pitch and roll being introduced to the camera from noisy tracking in prior versions of WLT. If I am understanding correctly the No Pitch and Roll feature is error correction and shouldn't affect how space pins function - only the underlying anchor graph. Am I correct in saying that under normal scenarios with reasonable tracking this feature should not be noticeable - and in this case is there a reason why it's not enabled by default?

[fast-slow-still]

The reason it is not default is that when tracking is good, you actually want to use that information to slightly adjust the gravity vector. So I would not recommend using this on HoloLens, which has excellent anchor stability.

On mobile, we have seen some situations where anchor error introduces a slight tilt to the gravity vector. In these cases, the new option lets you override that bias. I would recommend that you do not use the "No Pitch And Roll" option unless you are seeing a problem with the gravity vector as computed by the Frozen World Engine.

You are correct that the "No Pitch And Roll" option does not directly affect how space pins operate.

[camnewnham]

That makes a lot of sense with the relationship between anchor stability (mobile devices vs. HoloLens) and this option. Thanks for the explanation!