Skip to content
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

Allow importing scenes (glTF etc) as MeshLibraries #5375

Open
jtnicholl opened this issue Sep 9, 2022 · 3 comments
Open

Allow importing scenes (glTF etc) as MeshLibraries #5375

jtnicholl opened this issue Sep 9, 2022 · 3 comments

Comments

@jtnicholl
Copy link

jtnicholl commented Sep 9, 2022

Describe the project you are working on

Porting the official demos to 4.0 (see godotengine/godot-demo-projects#770)

Describe the problem or limitation you are having in your project

Currently, the typical process for creating a MeshLibrary involves exporting a .gltf or .glb to your project, setting up collision shapes and navmeshes for the scene in the import options, then opening the file as a new inherited scene and exporting it as a MeshLibrary.
This MeshLibrary resource contains screenshots, as well as copies of the mesh, collision shape, and navmesh data, all bundled into one file. And because it has to be created manually, you will probably want to include it in version control, even though the only data it has is either auto-generated or duplicated from the glTF file.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

It would be much simpler if the scene importer allowed importing scenes directly as MeshLibrary resources.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

In the import tab, add an option for MeshLibrary in the "Import As" dropdown alongside Scene and AnimationLibrary.
The advanced import window will still be available and used for setting collision shapes, use external materials, etc.
This will make it faster and easier to create MeshLibraries, as you won't have to manually open a new inherited scene and export every time, and also reduce the amount of binary data in version control.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It might be possible to do this with an import script, but I don't think that should be necessary. This is about improving the default workflow for MeshLibrary and by extension GridMap, which are core features.

Is there a reason why this should be core and not an add-on in the asset library?

I'm sure it's possible to do this with an import plugin as well, but I believe it's basic enough that it should be in core. Plugins shouldn't be necessary for usability of core features.

@Calinou
Copy link
Member

Calinou commented Sep 9, 2022

Related to #4849, #3821 and #3406.

@oparisy
Copy link

oparisy commented Apr 30, 2023

This is a super nice idea in that this would provide a direct workflow to import assets as a MeshLibrary, while currently multiple steps are required, and are constrained by Scene > MeshLibrary export limitations (as documented by #3821).

Is the importer able to import a bunch of assets in one go? Because the most common use case is to import a possibly large number of assets into a single MeshLibrary, an it seems to me that this proposal is for an evolution of the existing Godot 4.0 importer.

@jtnicholl
Copy link
Author

This is a super nice idea in that this would provide a direct workflow to import assets as a MeshLibrary, while currently multiple steps are required, and are constrained by Scene > MeshLibrary export limitations (as documented by #3821).

The idea here isn't to add any new or different code for MeshLibrary generation, just calling it automatically. This doesn't solve the limitations mentioned there.

I assume this could be implemented fairly easily right now, the issue is that godotengine/godot#65552 would prevent it from being usable.
The structure of MeshLibraries needs to change to solve that, otherwise your tiles could potentially scramble any time you reimport.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants