-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic import of glTF extras as per-instance shader uniforms and other object data in 4.x #4286
Comments
Another useful thing that could be imported from glTF extras is visibility ranges since manual HLOD are a thing in 4.x. Extras could be floats named something like "vis_range_begin", "vis_range_begin_margin", etc or instead an array of four floats names "visibility_range" and a separate int named "visibility_range_mode". |
See also discussion in #4204. This is a good idea, but I'd prefer using separate values that match Godot property names instead of an array. |
This comment was marked as outdated.
This comment was marked as outdated.
This proposal should be possible now with godotengine/godot#66026:
You might have to wait until godotengine/godot#69022 is merged, so that you can easily reload the editor plugin while working on it. |
How do you do this? I thought putting something like this in the plugin would do it, but the enter tree code doesn't seem to be called.
|
nm, disabling and reenabling the plugin seems to have made it work. |
Describe the project you are working on
A 3rd person stealth game with parkour.
Describe the problem or limitation you are having in your project
Due to the excellent support for glTF import in Godot, one of the best ways to create static level geometry is to make it all in Blender and utilize import hints to generate all the necessary data. However, with the introduction of per-instance shader uniforms a great obstacle is made for users of this workflow. In Blender per-instance shader uniforms are easy to replicate using custom properties.


As you can see in this screenshot all of these cubes have the same material and are colored differently using custom properties. But when I export as glTF all this work is lost and must be painstakingly replicated in Godot, by making the glTF scene have editable children and manually copying and pasting every hex value from Blender into Godot. For large levels this can create hours of tedious, error prone work that worse still can get erased when major modifications are made to the level and the glTF reimported.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Add support for importing glTF extras and automatically parse them for import hints in a similar way to the existing import hint system. This would allow custom properties to
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
On import all extras would be parsed for import hints, for instance an extra called "my_color-shadparam(8)" will be imported as a shader parameter in index 8 called "my_color" with the data type determined automatically. If the extra has an array of 4 floats, that's a vec4, 3 floats, vec3, etc. Another useful import hint for extras could be "-group" so an extra names "wall-group" would ignore any data on that extra and instead add the node to the group "wall". Any data lacking import hints could be imported as metadata for use in scripting (see godotengine/godot#59452 ).
If this enhancement will not be used often, can it be worked around with a few lines of script?
As far as I can tell the glTF importer doesn't support glTF extras, or if it does it doesn't pass that data along to EditorScenePostImportPlugins so to get this functionality would require either modification of engine source or a completely custom glTF importer.
Is there a reason why this should be core and not an add-on in the asset library?
Previously there was little reason to support glTF extras, but with per-instance shader uniforms and the refactoring of object metadata, there is now more reason than ever to add it, and make it part of the standard import workflow. As far as I can tell, this can not easily be done in a way that would be an asset library add-on.
The text was updated successfully, but these errors were encountered: