AutoBone Improvements

[slimevr]

AutoBone Improvements

[Eirenliel]

As mentioned in #148, Autoboning should start and end when user presses Reset on controllers with the #26 feature.

[Eirenliel]

Autobone improvements

[Erimelowo]

More stuff to do:

• Make GUI better, autobone easier to use. Right now, it’s just “move around with your heels locked for 15 seconds. Ask user to do (and make autobone detect) certain movements instead of a timer?
• SlimeVR/SlimeVR-OpenVR-Driver#20 (Also RESET ALL automatically when autobone starts (should be easy)
• Need to support more bones (especially controller distance for elbows. That’ll require a separate recording session most likely) (head offset and neck length too!!! Probably will also require a separate recording session (before the neck and legs one?))

[Eirenliel]

Make GUI better, autobone easier to use. Right now, it’s just “move around with your heels locked for 15 seconds. Ask user to do (and make autobone detect) certain movements instead of a timer?

See #148 Step 6. It covers everything. GUI tasks are for GUI, not for Autobone, but I guess it's okay to have this written down in multiple places so we don't forget it.

[ButterscotchV]

• Marked "Refactor AutoBone to use SkeletonConfig internally instead of EnumMaps" as completed since it's no longer a goal or possible when adjusting offsets directly
• Added new goals for invalid recording detection, these should help give better feedback for why recordings aren't working as expected

[ButterscotchV]

Recording validation and result validation systems could be created to give full feedback to users about potential issues with the recording and resulting measurements using modules
Ex. recording validation

Excess foot movement detected between frames 0 and 1
Headset movement stutter detected between frames 4 and 5

And result validation

Torso to leg proportion is outside of the expected range (1.47)
Torso to hip ratio is outside of the expected range (0.3)

[Eirenliel]

Yesss yesss! #148

Calculated data should be sanity checked for ranges and possible wrong values should be highlighted and a warned should be displayed

[ButterscotchV]

Recording validation and result validation systems could be created to give full feedback to users about potential issues with the recording and resulting measurements using modules
Ex. recording validation

Excess foot movement detected between frames 0 and 1
Headset movement stutter detected between frames 4 and 5

And result validation

Torso to leg proportion is outside of the expected range (1.47)
Torso to hip ratio is outside of the expected range (0.3)

To add on to this, it would be very trivial to have a list of requirements to be met at any time, ex. HMD connected and active, at least the 5 minimum trackers assigned correctly and active, etc.

This could be made easily on the protocol by just having a list of info lines, with info, success, warning, and error statuses in order to show the current state or state of the results. The relevant statuses could be filtered by the receiver as desired to reduce overloading with information.