You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In GLTF2 we currently code lights and cameras directly into the gltf2 importer.
glTF2 has many extensions. It doesn't make sense for all them to be embedded into the core of Godot Engine. There's also user extensions that shouldn't be part of Godot Engine.
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Using this extension system, the lights and cameras in gltf2 can be moved to c++ extensions. This also allows other uses.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
The main goal is for these extensions to be gdscript-able.
I wanted to move the glTF2 camera and light extensions to an "Extension class of a glTF2 document".
In the import panel, we can select import/export extensions which are just global named import/export extensions.
Import:
read from disk -> extension pre -> parse into gltf/fbx document -> extension current -> packed scene -> extension post
Export:
packed scene -> extension pre -> convert to gltf/fbx document -> extension current -> write to disk -> extension post
There's a stack of extensions. The order of the extensions are interleaved. The pre of all the extensions is done before all the current extensions, and all the post extensions.
User modifications should be stored in the .import file for use in these scripts.
This should also allow the creation of new properties that are stored inside of the import panel and saved in the .import file.
Misc other uses:
class_nameSomeNameHereextendsSceneWorkflowToolfuncon_pre_import( resource_path : String ):
passfuncon_current_import( resource_path : String, document: Resource):
passfuncon_post_import( resource_path : String, scene : PackedScene ):
iftreeA.contains("/RootNode/"):
treeA.remove("/RootNode/")
# example extensions which could be writtenoptimise_meshes()
remove_lighting()
reset_all_scales_to_one()
purge_orphans()
retain_orphan_gui()
funcon_pre_export( resource_path : String ):
convert_all_dds_to_png(resource_path)
funcon_current_export( resource_path : String, document: Resource ):
passfuncon_post_export( resource_path : String, scene : PackedScene ):
open_diff_gui(treeA, treeB, <matchingrule> )
iftreeA.contains("/RootNode/"):
treeA.remove("/RootNode/")
Workflow extra root node:
There is a root node that is at the top.
Extension point pre and current are ignored.
Extension point post takes the existing scene that is imported and modifies the root to be dissolved keeping children. The nodepath and string references need to be rewritten. Animations too.
Workflow diff tool:
A diff tool can be one of the default extensions and can be subclassed.
We can make an extension post point gui for gdscript fixes that has shows a popup dialog for all the relevant changed locations for review.
Workflow orphan detection:
Extension point pre reads from the raw tscn and directly searches for orphans and deletes it since the orphans don't appear in the scene.
Workflow gdscript is in-correct:
This is a diff tool that shows every node that is invalid. The tool asks the developer for input.
Workflow tool post process move to directory:
Extension point import post is a post process option.
If this enhancement will not be used often, can it be worked around with a few lines of script?:
We want to expose an interface that is gdscriptable.
Is there a reason why this should be core and not an add-on in the asset library?:
Expose the extension points in importers requires work.
The text was updated successfully, but these errors were encountered:
fire
changed the title
Import extensions
Import / Export extensions
Sep 4, 2020
SceneImporter.set_extensions(TypedArray<SceneImporterExtension> p_extensions) -> void
Store extensions in an ordered vector.
One sample extension is to check the scene requirements. For example, less than N triangles; no textures > 2048. We can implement this extension so that it returns a null node if failing. Error data is stored in the extension.
Describe the project you are working on:
Godot Engine and a 3D Multiplayer Game.
Describe the problem or limitation you are having in your project:
This is a way to implement #1398.
In GLTF2 we currently code lights and cameras directly into the gltf2 importer.
glTF2 has many extensions. It doesn't make sense for all them to be embedded into the core of Godot Engine. There's also user extensions that shouldn't be part of Godot Engine.
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Using this extension system, the lights and cameras in gltf2 can be moved to c++ extensions. This also allows other uses.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
The main goal is for these extensions to be gdscript-able.
I wanted to move the glTF2 camera and light extensions to an "Extension class of a glTF2 document".
In the import panel, we can select import/export extensions which are just global named import/export extensions.
Import:
read from disk -> extension pre -> parse into gltf/fbx document -> extension current -> packed scene -> extension post
Export:
packed scene -> extension pre -> convert to gltf/fbx document -> extension current -> write to disk -> extension post
There's a stack of extensions. The order of the extensions are interleaved. The pre of all the extensions is done before all the current extensions, and all the post extensions.
User modifications should be stored in the .import file for use in these scripts.
This should also allow the creation of new properties that are stored inside of the import panel and saved in the .import file.
Misc other uses:
Workflow extra root node:
There is a root node that is at the top.
Extension point pre and current are ignored.
Extension point post takes the existing scene that is imported and modifies the root to be dissolved keeping children. The nodepath and string references need to be rewritten. Animations too.
Workflow diff tool:
A diff tool can be one of the default extensions and can be subclassed.
We can make an extension post point gui for gdscript fixes that has shows a popup dialog for all the relevant changed locations for review.
Workflow orphan detection:
Extension point pre reads from the raw tscn and directly searches for orphans and deletes it since the orphans don't appear in the scene.
Workflow gdscript is in-correct:
This is a diff tool that shows every node that is invalid. The tool asks the developer for input.
Workflow tool post process move to directory:
Extension point import post is a post process option.
If this enhancement will not be used often, can it be worked around with a few lines of script?:
We want to expose an interface that is gdscriptable.
Is there a reason why this should be core and not an add-on in the asset library?:
Expose the extension points in importers requires work.
The text was updated successfully, but these errors were encountered: