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 when action reference is not set or when binding count is zero to not track position nor rotation.

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.