Skip to content
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

Conversation

Troy-Ferrell
Copy link
Contributor

@Troy-Ferrell Troy-Ferrell commented Jan 8, 2020

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

  1. It would allow setting of Handedness although really this was always the read value from the assigned controller
  2. It would pre-append the handedness onto the gameobject name. However, since we re-use gameobjects of pointers now (they are just deactivated), the name will always pre-append onto itself making strings such as "Left_Right_Left_Left_DefaultControllerPointer"

Updated SolverTests to validate values on SolverHandler for switching hands and tracked target types.

Changes

Verification

As a reviewer, it is possible to check out this change locally by using the following
commands (substituting {PR_ID} with the ID of this pull request):

git fetch origin pull/{PR_ID}/head:name_of_local_branch

git checkout name_of_local_branch

@julenka
Copy link
Contributor

julenka commented Jan 9, 2020

Consider merging into mrtk_development instead of stabilization

@Troy-Ferrell
Copy link
Contributor Author

@julenka we will ship with Solvers not working for ControllerRay target type if we target MRTK_Development

@Troy-Ferrell Troy-Ferrell added this to the MRTK 2.3.0 milestone Jan 9, 2020
@julenka
Copy link
Contributor

julenka commented Jan 9, 2020

Consider moving away from HandJointService in SolverHandler. Look at detectedinputsources/controllers and then search for hand or not that way. This way consolidate controller ray and hand joint tracked target types?

Seems like a good idea

@julenka
Copy link
Contributor

julenka commented Jan 9, 2020

Can you please createa bug for this and fill in "Fixes #"?

Copy link
Contributor

@julenka julenka left a 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

@Troy-Ferrell
Copy link
Contributor Author

@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

Copy link
Contributor

@julenka julenka left a 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.

@david-c-kline
Copy link

deprecating handedness field instead of removing it

Yes, please! And then be sure to add a note in the change tracking issue.

Copy link

@david-c-kline david-c-kline left a 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

@david-c-kline david-c-kline dismissed their stale review January 10, 2020 19:00

Dismissing as i was in error in my requested change

@david-c-kline
Copy link

Yes, please! And then be sure to add a note in the change tracking issue.

This can be ignored :)

@david-c-kline
Copy link

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

Copy link
Contributor

@thalbern thalbern left a 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

@Troy-Ferrell
Copy link
Contributor Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@Troy-Ferrell
Copy link
Contributor Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@Troy-Ferrell
Copy link
Contributor Author

hmmm build error on UWP x86 .NET
https://dev.azure.com/aipmr/MixedRealityToolkit-Unity-CI/_build/results?buildId=8478&view=logs&j=c1841906-0df4-5516-e3c5-68840a78c082&t=dcf3bde5-faf6-583c-8480-29a621c79462

@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)
2020-01-13T23:05:25.9708647Z Copyright (C) Microsoft Corporation. All rights reserved.
2020-01-13T23:05:25.9710639Z
2020-01-13T23:05:25.9712893Z error CS2001: Source file 'C:\Windows\SERVIC2\NETWOR1\AppData\Local\Temp.NETCore,Version=v5.0.AssemblyAttributes.cs' could not be found.
2020-01-13T23:05:25.9714753Z
2020-01-13T23:05:25.9715056Z (Filename: Line: 0)
2020-01-13T23:05:25.9715829Z
2020-01-13T23:05:25.9716878Z DisplayProgressNotification: Build Failed
2020-01-13T23:05:25.9717287Z Error building Player because scripts had compiler errors
2020-01-13T23:05:25.9718312Z
2020-01-13T23:05:26.1728978Z (Filename: Line: -1)

@Troy-Ferrell
Copy link
Contributor Author

@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
Copy link
Contributor

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

Copy link
Contributor Author

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}";
Copy link
Contributor

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?

Copy link
Contributor Author

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")]
Copy link
Contributor

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.

Copy link
Contributor Author

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;
Copy link
Contributor

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?

@wiwei
Copy link
Contributor

wiwei commented Jan 14, 2020

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@wiwei wiwei merged commit c17ecee into microsoft:prerelease/2.3.0_stabilization Jan 14, 2020
@Troy-Ferrell Troy-Ferrell deleted the users/trferrel/fix-solvers branch January 22, 2020 19:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants