Proposal: In Between Solver that keeps an object between two tracked objects/transforms

[Ecnassianer]

Overview

My team needed a solver that keeps an object in between two tracked objects. I'd like to pull this code into the June 18 release.

My implementation creates a second solverhandler (public class AdditionalSolverHandler : SolverHandler) and adds it to the gameobject at runtime. This second solverhandler updates its TransformTarget, which is used by SolverInBetween as one of the two end points. It could be used by other solver types in the future; any number of AdditionalSolverHandlers is supported.

In the process, I fixed a few bugs, particularly with the custom inspectors. Solvers can now be switched to other tracked objects while playing in editor or at runtime via script. It also adds an offset and rotation to solver handlers so you can track a virtual point near by/rotated around an actual tracked object.

I have an updated version of the SolverHandler that I've used for testing and it is 17.7x better than the old one, so I'll replace the old one with that. The only downside is my new map requires motion controllers. The upside is the old map was pretty busted without motion controllers. It will be included in this PR.

One thing that will be lacking in this pull request is a refactor of the Solver and SolverHandler's attachment coroutine. I'd like to do that in a later pull request, but for now it leaves a bit of a mess around Solvers and SolverHandlers talking to each other unnecessarily when they reattach to new tracked objects.

[Ecnassianer]

Also fixing a bug where SolverHandlers can attach to a default handedness controller before their Handedness is updated.

[david-c-kline]

@Ecnassianer,
bring on those PRs! :)

[keveleigh]

I added in a couple changes for the May release that align with things you mention here.

Also fixing a bug where SolverHandlers can attach to a default handedness controller before their Handedness is updated.

I saw this same issue (or at least, something extremely similar) when I was implementing the controller pointing rays, so I updated ControllerFinder to wait until Start before trying to find a controller: https://github.com/Microsoft/MixedRealityToolkit-Unity/pull/2150/files#diff-cd6753cb36ca873e3f742d196d57240bR63

This allows apps to instantiate ControllerFinders at runtime and update their handedness before they try to attach. I'm not sure if this will properly bubble up and solve the issue in SolverHandler, but it sounds similar.

Solvers can now be switched to other tracked objects while playing in editor or at runtime via script.

I also added a method called ChangeHandedness in ControllerFinder, to go through the motions of detaching and reattaching: https://github.com/Microsoft/MixedRealityToolkit-Unity/pull/2201/files#diff-cd6753cb36ca873e3f742d196d57240bR98

Since SolverHandler is a ControllerFinder, you should be able to take advantage of these (or perhaps your changes supersede mine or they can live side-by-side). Overall, thanks for all this feedback and the contributions!

[Ecnassianer]

Shoot, I think I missed your commit by a few hours! XD

I think we're essentially doing the same thing. The biggest difference is in mine the reattach work happens in the setter of Handedness. It looks like ChangeHandedness() needs to be called each time Handedness is updated? I added it to the accessor because I think there are no circumstances where you want to update Handedness and not immediately do the work to find a new controller. Am I overlooking a reason they should be independent?

If you're curious, here are mine:
https://github.com/Ecnassianer/MixedRealityToolkit-Unity/blob/adb897b920bd471010a689739d1656b54e5c6915/Assets/HoloToolkit/Input/Scripts/Utilities/ControllerFinder.cs

I'll pull your may changes into my local branch and get them to mingle nicely.

[keveleigh]

I much prefer your way of doing it, so all the dev has to do is change handedness and it "just works". I can't think of a good reason for them to be independent, so we should likely deprecate my method in favor of yours.

This Issue also reminded me that I had an in-progress refactor of Solver/SolverHandler from a few months ago, specifically addressing:

a bit of a mess around Solvers and SolverHandlers talking to each other unnecessarily when they reattach to new tracked objects

I'll start cleaning up my work and updating it with the latest code, then I can make sure it works well with your proposed updates here.

[Ecnassianer]

Pull Request here:
#2245