FIX: Corrected behaviour of TrackedPoseDriver when no device is connected.

[ekcoh]

Description

This fix is intended to fix reported behaviour in ISXB-699
.

Changes made

Modified behaviour so that when position and rotation are assigned actions, they are evaluated similar to tracking state is such a way that they may only be applied if the binding is associated with a resolved control. If not, the evaluated tracking state will not contain the flag for the corresponding transform. This applies to ignoreTrackingState == false.

Modified behavior so that when entering playmode with ignoreTrackingState == true, the transform of the associated GameObject is preserved rather then forcibly reset to identify transform. This is achieved by initialising the internal m_CurrentPosition and m_CurrentRotation based on the local transform of the associated GameObject.

Added a test case that is mimicking the reported behavior.

Notes

Requesting insights from XR team regarding any implications this might have since behavior wasn't previously covered properly in existing test cases. It also changes the behaviour commented inline in the implementation.

Checklist

Before review:

• Changelog entry added.
  • Explains the change in Changed, Fixed, Added sections.
  • For API change contains an example snippet and/or migration example.
  • FogBugz ticket attached, example ([case %number%](https://issuetracker.unity3d.com/issues/...)).
  • FogBugz is marked as "Resolved" with next release version correctly set.
• Tests added/changed, if applicable.
  • Functional tests Area_CanDoX, Area_CanDoX_EvenIfYIsTheCase, Area_WhenIDoX_AndYHappens_ThisIsTheResult.
  • Performance tests.
  • Integration tests.
• Docs for new/changed API's.
  • Xmldoc cross references are set correctly.
  • Added explanation how the API works.
  • Usage code examples added.
  • The manual is updated, if needed.

During merge:

• Commit message for squash-merge is prefixed with one of the list:
  • NEW: ___.
  • FIX: ___.
  • DOCS: ___.
  • CHANGE: ___.
  • RELEASE: 1.1.0-preview.3.

[Pauliusd01]

@smnwttbr I don't have any XR devices so I'll add an XR QA instead. @UnityRyanC

[UnityRyanC]

I won't be able to test this PR as I don't have a Mac (which the bug mentions was where the issue was reproduced on). I spoke with Manuel Gonzalez Solano, who does testing on PolySpatial and Apple Vision OS, who'll be able to test this once he's free later this week.

I don't have permission to update reviewers on this PR, so @Pauliusd01 could you update the PR for me please?

[Pauliusd01]

I won't be able to test this PR as I don't have a Mac (which the bug mentions was where the issue was reproduced on). I spoke with Manuel Gonzalez Solano, who does testing on PolySpatial and Apple Vision OS, who'll be able to test this once he's free later this week.

I don't have permission to update reviewers on this PR, so @Pauliusd01 could you update the PR for me please?

Okay, I dmed him on slack since I can't find him on github by name.

[mangosol]

@Pauliusd01 can you add me as reviewer? I don't seem to have permission to add myself

[mangosol]

I tested the isxb-699-trackedposedriver-fix branch against a new Universal 3D project created and run using Unity Editor 6000.0.26f1 apple silicon and 2022.3.51f1 apple silicon, on an M1 macOS machine.

I did observe that the non-origin position and rotation was preserved on GameObjects having Tracked Pose Driver components if I left the Ignore Tracking State checkbox enabled.

If I check the Ignore Tracking State checkbox, GameObjects having Tracked Pose Driver component and set at non-origin position and rotation are once again returned to origin position and rotation when PlayMode starts

I also observed that setting Update Type = Before Render with Ignore Tracking State checked, non-origin rotations and positions are preserved when starting PlayMode

[mangosol]

I've also bound input actions to change position and rotation on GameObjects having TrackedPosedDriver component, and I observe the following:

• When TrackedPoseDriver is configured with Ignore Tracking State unchecked, I am able to modify position and rotation, and the updated values persist.
• When TrackedPoseDriver is configured with Ignore Tracking State checked, and Updated Type is set Update and Before Render || Update, and Tracking Type is set to Rotation and Position, then any changes made to position and rotation are reset immediately after applied (likely on next frame).
• When TrackedPoseDriver is configured with Ignore Tracking State checked, and Updated Type is set Update and Before Render || Update, and Tracking Type is set to Rotation only, then any changes made to rotation are reset immediately after applied (likely on next frame). Position changes are applied successfully and persist.
• When TrackedPoseDriver is configured with Ignore Tracking State checked, and Updated Type is set Update and Before Render || Update, and Tracking Type is set to Position only, then any changes made to position are reset immediately after applied (likely on next frame). Rotation changes are applied successfully and persist.

[ekcoh]

I've also bound input actions to change position and rotation on GameObjects having TrackedPosedDriver component, and I observe the following:

• When TrackedPoseDriver is configured with Ignore Tracking State unchecked, I am able to modify position and rotation, and the updated values persist.
• When TrackedPoseDriver is configured with Ignore Tracking State checked, and Updated Type is set Update and Before Render || Update, and Tracking Type is set to Rotation and Position, then any changes made to position and rotation are reset immediately after applied (likely on next frame).
• When TrackedPoseDriver is configured with Ignore Tracking State checked, and Updated Type is set Update and Before Render || Update, and Tracking Type is set to Rotation only, then any changes made to rotation are reset immediately after applied (likely on next frame). Position changes are applied successfully and persist.
• When TrackedPoseDriver is configured with Ignore Tracking State checked, and Updated Type is set Update and Before Render || Update, and Tracking Type is set to Position only, then any changes made to position are reset immediately after applied (likely on next frame). Rotation changes are applied successfully and persist.

Thanks for the feedback @mangosol , I have taken this old PR back again since @smnwttbr worked on it to conclude this. How should I interpret your assessment, is it in line with what you would expect? Any additional feedback/perspective from @chris-massie?

[ekcoh]

I tested the isxb-699-trackedposedriver-fix branch against a new Universal 3D project created and run using Unity Editor 6000.0.26f1 apple silicon and 2022.3.51f1 apple silicon, on an M1 macOS machine.

I did observe that the non-origin position and rotation was preserved on GameObjects having Tracked Pose Driver components if I left the Ignore Tracking State checkbox enabled.

If I check the Ignore Tracking State checkbox, GameObjects having Tracked Pose Driver component and set at non-origin position and rotation are once again returned to origin position and rotation when PlayMode starts

I also observed that setting Update Type = Before Render with Ignore Tracking State checked, non-origin rotations and positions are preserved when starting PlayMode

Thanks for the feedback @mangosol , I have taken this old PR back again since @smnwttbr worked on it to conclude this. How should I interpret your assessment, is it in line with what you would expect? Any additional feedback/perspective from @chris-massie?

[mangosol]

Thanks for the feedback @mangosol , I have taken this old PR back again since @smnwttbr worked on it to conclude this. How should I interpret your assessment, is it in line with what you would expect? Any additional feedback/perspective from @chris-massie?

I do not have sufficient context on whether the behavior I observed is expected or not; my assessment is meant to describe current behavior for either you or any other stakeholder with more in depth knowledge of functional requirements to determine if the current behavior is expected or not given the changes in this PR. I'm happy to sign off if behavior is in line with requirements

[ekcoh]

Thanks for the feedback @mangosol , I have taken this old PR back again since @smnwttbr worked on it to conclude this. How should I interpret your assessment, is it in line with what you would expect? Any additional feedback/perspective from @chris-massie?

I do not have sufficient context on whether the behavior I observed is expected or not; my assessment is meant to describe current behavior for either you or any other stakeholder with more in depth knowledge of functional requirements to determine if the current behavior is expected or not given the changes in this PR. I'm happy to sign off if behavior is in line with requirements

OK, thanks, I will do a review of this then and assess it and then make a decision based on that. Thanks for testing this through and carefully documenting observations. Its helpful.

[ekcoh]

This PR have been updated based on reviewing implementation and previous suggested fix. I have updated the PR description accordingly. It would be fantastic if it would be possible to reassess this fix and ensure there are no regressive behavior in XR domain. @mangosol @chris-massie

[ritamerkl]

Changes look good. I suggest outsourcing the HasResolvedControl method since it could be useful in more cases.

[vrdave-unity]

A couple of minor tweaks.

[vrdave-unity]

These changes look good. I don't think it should impact performance too much since the HasResolvedControl calls only happen during the first update.

[ekcoh]

@chris-massie I have applied all your suggestions to the PR and re-run CI on the branch. Hence requesting re-review. Additionally do you think an additional QA pass is needed from @mangosol or other XR QA before this lands or not?

[chris-massie]

I tested these changes out with the XRI simulator and it seemed to work as I expected where the existing pose is retained if there's no device. If I connect the device late the Transform stays at the initialized pose until a change from (0, 0, 0) happens on the device, at which point it updates as expected.

[ekcoh]

Thanks @chris-massie and @vrdave-unity for the latest reviews and testing, it was very valuable. I will get this merged based on this.