Mesh Blendshapes arbitrary limited to the 0.0-1.0 range

[smix8]

Godot version:
3.2 stable.official

OS/device including version:
Windows 10 x64

Issue description:
Mesh Blendshape values clamp to the 0.0 - 1.0 range which creates an arbitrary limit and ignores practical use cases for other values. A 3d artists intention to allow for overshooting blendshapes or use of negativ values is not supported by the engine.

This issue is completly similar to older Unity and Unreal Engine issues that clamped blendshapes in the 0 - 1 or 0 -100 range. Both game engines removed this limit by now and allow for customization of limits (unreal engine as early as 2014 and unity in 2018). While not a real bug this old decisions on limits are almost certainly oversights or made in favor of making the life of engine programers easier which is fine. The tradeoff is limited options and usefulness of blendshapes for 3d artists that have to work and create quality 3d content for games that use said engine.

Unity removed this arbitrary limit in v. 2018.3. due to regular demand.
https://forum.unity.com/threads/removing-clamping-of-blendshapes-to-the-range-0-100.504973/
https://unity3d.com/unity/whats-new/unity-2018.3.0
"Graphics: Added 'Clamp BlendShapes (Deprecated)' option in PlayerSettings to toggle BlendShape weight range clamping and replaced the FloatField with a Slider in SkinnedMeshRenderer."
Unreal Engine Commit:
https://github.com/EpicGames/UnrealEngine/commit/f5f1b8b77efe30878fac8d7ae101b07636833bc9

Found behavior:
When importing a Mesh with Blendshapes that have negative range values or values above 1.0 (100%) those range values and informations don't show up / are discarded.

Expected behavior:
The importer should allow for the intended range values by the 3d artists or in case of engine limitations provide import options to recalculate them to fit the Godot range instead of throwing the information into the dumbster. Customizable range limits on import and per blendshape through the inspector would be the ideal solution.

Problem with current behavior:
From a 3d artist perspective (especially character artists) negative blendshape range values or values that allow for overshooting the morph targets serve a purpose. They provide for better useability with the 3d models or make certain wild combinations of blendshapes better "work" at runtime. This way a 3d artist can foresee a e.g. game designers demand for change in combinations, that would otherwise require a timeconsuming rework in a 3d authoring software which is often not even an option for 3d stock assets.

Common cases and problems:
1.) Blendshapes that oppose each other are combined in one single blendshape for useability. In this case 0.0 is a neutral stance, while -1.0 and 1.0 are e.g. for up/down or left/right, thinner/thicker morph targets. Negative values are more intuitive for users in this case than e.g. 0.5 for neutral.

2.) Blendshapes no longer align perfectly with certain morph combinations, e.g. eyes don't close completly with certain head blendshape combinations. Instead of providing additional correction blendshapes a more practical solution is to allow for overshooting a blendshape to e.g. 125% that fixes this issue even at runtime.

3.) This behavior limits the use of market available 3d assets with blendshapes inside Godot and also makes commissions to 3d artists cumbersome as they have to do additional workarounds for Godot.

While Godot isn't the only game engine still with this issue it doesn't provide the same amount of helpful tools to make up for it in other regards for 3d artists, further branding the 3d part of the engine as a second-choice for an important part of the production pipeline which is undesirable.

Steps to reproduce:
Import a Mesh with Blendshapes that allow for a negative range or values above 1.0, the values don't show up / are discarded by Godot. Creating the mesh and blendshapes through code doesn't work either due to clamping.

Minimal reproduction project:
test_actor.zip

Test .glb file (.dae or .fbx makes no difference) with a 3d actor from blender with eyes left/right or eye closed blendshapes between the -1.0 and 1.25 range. Overshooting to 125% on the closed eyes isn't supported and only the eye right position works in Godot as the left position uses negative range values.

[mhilbrunner]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!

[akien-mga]

Fixed by #45859.