Both bugs were related to how position animation tracks were adjusted in rest fixer.
First bug: motion scale is applied before subtracting the origin when applying bone roll
Second bug: armature scale was lost when converting basis to quaternion, leading an unscaled position offset to be added to the scaled origin.
Reimplements "Remove Immutable" by comparing to the skeleton rest.
It is necessary to delay removing animation tracks until after the correct rest pose is calculated in rest-fixer.
Preserves the original implementation in the GLTFDocument / FBXDocument API for compatibility.
Corrected the for-loop condition in the auto_mapping_process function. Previously, it was checking if children.size() is non-zero, which resulted in an infinite loop
This PR prevents potential NPEs, and follows Kotlin conventions more closely
by replacing the unsafe !! operator with safe ?. (or ?.let) (usually
!! would only be used very rarely, and with a good reason - there is one
place left in this PR where !! makes sense), and by replacing Java style
'if (x != null)' with Kotlin's '?.'
In certain situations it is possible that in a `Viewport` the same
mouse button is pressed twice in series without releasing it in
between.
In this case, focus stealing should happen to ensure, that the
mouse button is not sent unintentionally to the previously focused
Control node.
This paves the way for integrating hand-picked high-quality assets
to be displayed in the project manager when accepting the
"you don't have any projects yet" dialog.
Editor would not be brought up when clicking on all but the last column on a TreeItem with SelectMode=Row with
multiple columns and when the editor was being brought up when clicking on the last column, it was editing the first column
Fixed draw_item, gui_input and edit_selected functions by setting set_meta parameter for each column
Fixed select_single_item function by changing selected_col depending on input
WMR isn't supported on non-Windows platforms, so there's no point
in mentioning it in the error message as it's not a possible
cause for OpenXR not initializing.
In some cases it can happen, that the order of input events and
window events is not followed, when input buffering or input accumulation
is active.
The display server order `InputEvent` => window-event gets changed to
window-event => `InputEvent` which becomes problematic in certain
situations.
This PR makes sure, that the order is adhered to by flushing input events
before a window event is sent.
Previously this problem was mitigated by discarding these delayed events.
But this solution was problematic in the setting of android input events.
Changed Input.action_press() treatment of strength parameter to match
behavior of InputEventAction and documentation, by clamping between 0
and 1. Fixes Input.get_action_strength() returning values over 1 when
large values are passed to Input.action_press().
