Two projects: First, a game designed to be driven by root motion; and second, a general purpose platform supporting import of user generated avatar models (such as VRM files) to which we apply a standardized set of animations.
Describe the problem or limitation you are having in your project
Regarding the game driven by root motion, we created animations using Auto-Rig Pro in Blender. This tool allowed animating the position of the root bone (the Hips), so at import time in Godot, there was no root motion track.
First, post-import scripts do not compose, so if we wanted to add additional workflows into the import pipeline, we would have been forced to modify the root motion extractor to introduce an unrelated feature.
Second, there was no way to provide a user interface to adjust parameters used by these scripts such as the root-motion extractor (for example, the user may need to tune some thresholds related to rotation extraction).
Secondly, regarding the VRM & custom avatar application, we wrote a script to put characters into a T-Pose to realign bone rolls for the purpose of animation and IK retargeting.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
General-purpose scene importer plugins should be assigned project-wide, which will assign options and
From @SaracenOne
Coming off from doing some work on the scene importer yesterday, I'm looking to start drafting a spec for general-purpose scene importer plugins, basically an API for hooking into the pre and post-import steps for importing any file intended to be imported as a Godot scene, and essentially a more extensive, general-purpose replacement for the post-import scripts.
My goal is to not to over-engineer, but to provide simple script entry points in the essential steps of the import process, provide callback functions for the property list to allow custom importer properties to be defined, and provide access to the UI for the new AdvancedSceneImporter window in order to create contextually appropriate widgets and render any custom gizmos required.
As of now, I'm drafting it as 'EditorSceneImportBehaviourPlugin', but let me know if you've got questions or feedback.
New user-overridable class: EditorScenePostImportPlugin
Allows adding custom options to the basic as well as the advanced import dialogs:
_get_import_options - override to return additional global import options
_get_internal_import_options - override to return additional advanced per-node import options
_get_internal_option_update_view_required - should the settings view refresh when this option is changed?
_get_internal_option_visibility - is the advanced option visible?
_get_option_visibility - is the basic option visible?
_internal_process - allow operating on individual nodes or resources in the scene. This enables use-cases like changing animations; modifying bone poses and so on.
_post_process - allow modifying state after the normal import post-processing flow is run.
_pre_process - allow modifying state after the import; and before the normal import-post-processing for is run. (Note that this is pre-processing the post-import state, so it still runs after the base importer)
And functions to call:
add_import_option
add_import_option_advanced
get_option_value
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
These plugins are called in the order they are added (by _enter_tree in a editor plugin). They define settings that can be changed by the user, and then override hooks which are called at various stages of the post-import process.
It might be interesting to provide pre-import scripts which could offer a good way to activate GLTFDocumentExtension and alter other settings for other imports, before the main importer runs:
I expect it may also be a good way to access the document model of Fire's recent refactoring of GLTF importing so that we can more effectively parse custom extensions
There is a question of whether the post-import script has access to the GLTF Document (from the import phase), or if this state should left solely as part the GLTFDocumentExtension subclass.
If this enhancement will not be used often, can it be worked around with a few lines of script?
While post-import scripts exist, there is no UI for users to provide import options for each scene.
Is there a reason why this should be core and not an add-on in the asset library?
lyuma
commented
2 years ago
Describe the project you are working on
Two projects: First, a game designed to be driven by root motion; and second, a general purpose platform supporting import of user generated avatar models (such as VRM files) to which we apply a standardized set of animations.
Describe the problem or limitation you are having in your project
Regarding the game driven by root motion, we created animations using Auto-Rig Pro in Blender. This tool allowed animating the position of the root bone (the Hips), so at import time in Godot, there was no root motion track.
For this reason, we create a tool at https://github.com/V-Sekai/root-motion-extractor/tree/godot_4 which was intended to be run as a post-import script. However, we ran into two problems.
Secondly, regarding the VRM & custom avatar application, we wrote a script to put characters into a T-Pose to realign bone rolls for the purpose of animation and IK retargeting.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
General-purpose scene importer plugins should be assigned project-wide, which will assign options and
From @SaracenOne
New user-overridable class: EditorScenePostImportPlugin
Allows adding custom options to the basic as well as the advanced import dialogs: _get_import_options - override to return additional global import options _get_internal_import_options - override to return additional advanced per-node import options _get_internal_option_update_view_required - should the settings view refresh when this option is changed? _get_internal_option_visibility - is the advanced option visible? _get_option_visibility - is the basic option visible?
_internal_process - allow operating on individual nodes or resources in the scene. This enables use-cases like changing animations; modifying bone poses and so on. _post_process - allow modifying state after the normal import post-processing flow is run. _pre_process - allow modifying state after the import; and before the normal import-post-processing for is run. (Note that this is pre-processing the post-import state, so it still runs after the base importer)
And functions to call: add_import_option add_import_option_advanced get_option_value
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
See the PR by @reduz here: https://github.com/godotengine/godot/pull/53813
These plugins are called in the order they are added (by _enter_tree in a editor plugin). They define settings that can be changed by the user, and then override hooks which are called at various stages of the post-import process.
It might be interesting to provide pre-import scripts which could offer a good way to activate GLTFDocumentExtension and alter other settings for other imports, before the main importer runs:
There is a question of whether the post-import script has access to the GLTF Document (from the import phase), or if this state should left solely as part the GLTFDocumentExtension subclass.
If this enhancement will not be used often, can it be worked around with a few lines of script?
While post-import scripts exist, there is no UI for users to provide import options for each scene.
Is there a reason why this should be core and not an add-on in the asset library?
Import is core