-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Solvers tracking pointers as target transforms #7012
Fix Solvers tracking pointers as target transforms #7012
Conversation
Consider merging into mrtk_development instead of stabilization |
@julenka we will ship with Solvers not working for ControllerRay target type if we target MRTK_Development |
Seems like a good idea |
Can you please createa bug for this and fill in "Fixes #"? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, except one worry about removing a field that is technically publicly exposed in an asset. Wanted to make sure we are not breaking people
Assets/MixedRealityToolkit.SDK/Features/Input/Handlers/ControllerPoseSynchronizer.cs
Show resolved
Hide resolved
Assets/MixedRealityToolkit.SDK/Features/UX/Scripts/Pointers/BaseMousePointer.cs
Show resolved
Hide resolved
Assets/MixedRealityToolkit.SDK/Features/Utilities/Solvers/SolverHandler.cs
Show resolved
Hide resolved
Assets/MixedRealityToolkit.SDK/Features/Input/Handlers/ControllerPoseSynchronizer.cs
Show resolved
Hide resolved
Assets/MixedRealityToolkit.SDK/Features/UX/Scripts/Pointers/BaseControllerPointer.cs
Show resolved
Hide resolved
@julenka filed #7030 to track work to simplify SolverHandler tracking code with DetectedControllers. Putting off for now since this is going into stabilization and that would be more code churn than necessary to solve the actual issue here. Speaking of issue here, filed #7029 to track with PR @julenka / @keveleigh , see my response to your other comments |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving to unblock check in, though I had a suggestion about deprecating handedness field instead of removing it. That might surprise people less.
Yes, please! And then be sure to add a note in the change tracking issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please deprecate Handeness instead of removing. Thanks
Dismissing as i was in error in my requested change
This can be ignored :) |
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM :)
tests are using PlayModeTestUtilities instead of TestHand - but that was already there before - so no need to change that now
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
hmmm build error on UWP x86 .NET @keveleigh / @wiwei , try to dive into myself now, but does this look like something that could be impacted by #7053 ? Seems like an odd error for this change 2020-01-13T23:05:25.9706477Z Microsoft (R) Visual C# Compiler version 2.9.1.65535 (9d34608e) |
@keveleigh / @davidkline-ms / @wiwei / @thalbern , can one of you review/merge this when possible? Thanks! |
@@ -32,8 +27,8 @@ public Handedness Handedness | |||
/// <inheritdoc /> | |||
public bool DestroyOnSourceLost |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just use
public bool DestroyOnSourceLost => destroyOnSourceLost;
If you are not altering either the getter / setter?
Also consider this for other areas this is being changed for
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe that just creates a getter, no setter
if (controller != null && gameObject != null) | ||
{ | ||
handedness = value.ControllerHandedness; | ||
gameObject.name = $"{handedness}_{gameObject.name}"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why remove the setting of the game object name, unless you are now doing this somewhere else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the PR description there is an example. Basically constant calling to his makes "Left_Right_Left_BlahPointer" names. Instead of checking the name and doing substrings, I just removed it so the name is left as-is
#pragma warning disable 0414 | ||
[SerializeField] | ||
[HideInInspector] | ||
[System.Obsolete("Use the Handedness property instead to get current handedness which is set by Controller attached")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would seriously have to question why you are putting an obsolete flag on a PRIVATE field.
Obsolete is for telling consumers of a function or property outside a class is it going to be deprecated. Private fields do not fall in this category because they are private. No need to make them obsolete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was originally removed. Please read PR thread
#7012 (comment)
@@ -208,7 +208,7 @@ public override IMixedRealityController Controller | |||
|
|||
if (base.Controller != null && this != null) | |||
{ | |||
pointerName = gameObject.name; | |||
PointerName = gameObject.name; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you have removed setting the gameobject name above, is this needed?
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
Overview
Due to pointer cache PR #6822 , pointers no longer necessarily destroy themselves after source lost. SolverHandler though would detach itself from a controller/hand once the transform was destroyed. This is actually incorrect since custom pointers could have had
DestroyOnSourceLost
false.This change tracks, for the controller ray tracked target type, the associated line pointer being used for the transform and whether it is still being tracked or not. If it is not null, but not being tracked, then we detach and refresh for a new transform.
Also clean up some of the code and comments around solvers/pointers related files. In particular, ControllerPointerSynchronizer did two incorrect things
Updated SolverTests to validate values on SolverHandler for switching hands and tracked target types.
Changes
Verification