Resolved atypical skeleton deformations when flipping bone rotations

[ergoxiv]

This pull request fixes the skeleton deformations that happen with frozen positions. This restores the old behaviour of the flip functionality. As a result, flipping bones with positions enabled and positions disabled should visually indistinguishable.

[StoiaCode]

#1400 ❤️

[CaptainSticky]

I was finally able to get to some testing and I am trying to think of some standard test cases I can apply so that I can test more regularly (and consistently). Let me know if this level of thoroughness is okay! :>

✅ Scenario 1 - Simple Flip

The goal is to do a simple test of the flip functionality. Tested pose is the Aetheryte attuning pose, saved pre-DT.

1. Import a pose using the import button.
2. Flip using the flip button.
   

✅ Scenario 2 - Make a custom pose.

The goal is to create a unique pose, using a typical workflow involving the flip button. Base pose is a standing Lalafell /clap and the pose used in step 3 is a standing Lalafell /welcome, both of which were saved pre-DT.

1. Import base pose using the import button.
2. Uncheck P, S. *
3. Import selected bones. R.
4. Manually pose several bones.
5. Export as a pose.
6. Flip using the flip button.
7. Import selected bones. R.
8. Flip using the flip button.
9. Manually pose several bones.
10. Export as a pose.
11. Flip using the flip button.
12. Import selected bones. R.
13. Flip using the flip button.
14. Import expression-only. R, P, S.
15. Manually pose several bones.
16. Export final pose.
    

Issues Occurred.

Step 2 in Scenario 2 was needed due to a behavior encountered, probably unrelated to this PR.

Possibly-Unrelated Issue 1

Distorted bones were encountered when importing selected bones with R, P, S after doing an initial import of a pose. Base pose is a standing Lalafell /clap and the pose used in step 2 is a standing Lalafell /welcome, both of which were saved pre-DT.

1. Import base pose using the import button.
2. Import selected bones. R, P, S.
3. Distortion encountered in the selected bones.
   

Re-saving new, DT versions of these poses resulted in no distortion.

1. Import base pose using the import button.
2. Import selected bones. R, P, S.
3. Import selected bones. P.
   

Possibly-Unrelated Issue 2

Importing selected bones with R while R, P, S is checked causes two behaviors. The first is that P becomes unchecked. The second is that no import actually occurs. These occur with both pre-DT pose files and post-DT pose files. (For this test, I used the new /clap and /welcome base poses I saved above.

1. Import base pose using the import button.
2. Import selected bones. R.
3. P becomes unchecked. No import occurs (visually).
   (I didn't take a picture of this.)

[ergoxiv]

Thank you for taking the time to test everything. I think your steps are clear, and I agree that having a few predefined test cases that we can manually run between changes is a good idea.

The issues that you mentioned are indeed unrelated to #1400. I think it makes more sense to address them in #1399.

Issue 1:

Unlike the other import options, importing "selected bones" does not reset positions. Using the same strategy as I did for the other options should resolve this issue. For context, this distortion happens because bones with frozen positions, unless explicitly written to, won't change position in Euclidean space. Specifically, their parent-relative position changes (if a parent bone is rotated) but character-relative position doesn't.

Issue 2:

The checkbox behavior is not a bug but current expected outcome of the import feature. The checkboxes for the secondary import options will overwrite the pose mode you were previously in. Changing it to preserve the state if pose mode is already enabled is pretty trivial and it mostly comes down to a design decision.

Which selected bones did you try to import with rotation-only mode? I will try to reproduce this issue to see where it goes wrong.

[StoiaCode]

Changing it to preserve the state if pose mode is already enabled is pretty trivial and it mostly comes down to a design decision.

I think its probably a good idea to handle this after a "smallest common denominator" principle. Not an important change but putting my word down for that approach.