Resource Sharing via Paths

[donn-xx]

Imagine one has a scene with many nodes (let's say 3d meshes). They are setup as a library of meshes. Let's say "trees.tscn"

I'd like to suggest a way to reach any object via something like: "res://trees.tscn::/palm_tree/coconut/mesh"

(The material would be "res://trees.tscn::palm_tree/coconut/material" and so forth. A bit like Blender does it.)

Right now, Multimesh is very keen to duplicate meshes and dump all that data into the scene file—which bloats quickly. Either that or it expects a file path to a mesh resource file—but, if I already have the coconut tree mesh in that packedscene, why can't the Multimesh just point into tree.tscn instead; fetch the data from there and go about its business?

To avoid issues, the packedscene could be required to be instanced in the scene, so it's loaded and available, it would just be set to invisible.

Maybe this exists already, not sure?

[smix8]

The question is why you have a "coconut tree" Mesh or Materials (and likely Textures as well) stored in a PackedScene in the first place, and not stored in their own Resource file.

Which is basically "resource sharing via paths" because only the path to the resource ref will be stored in the scene, not the entire file data.

Just because you can embed everything in Godot into scene files does not mean you should. Not only does storing a mesh or texture like that inside a scene file make everything slow to edit and slow to save and load, it also makes the resource not reusable and shareable.

Godot also can not load "a little" of a scene file, it loads the entire scene file because it does not keep a file index position for each individual asset in the scene file. So having a bloated scene file with everything is really unwieldy and bad for a lot of things, not recommended at all.

[donn-xx]

Hey. Thanks for engaging the topic. Good on ya.

Try this angle:
Coming from Blender, you can lay out a whole bunch of models (say different kinds of trees and plants) and then export all of them out as one glb file. Then in Godot, you import and instance as a tscn file. This way you have a neat back-and-forth for when you want to iterate on the models: the scene file acts as a kind of library.

I hear what you sat about bloat, but that's up to the dev (me). They would balance the pros and cons of it.

When I start to scatter those trees onto a landscape scene, I am employing many MultimeshInstance3D nodes. If each Multimesh within them could point into that 'library' scene (or even into the glb file) I could use this approach.

I know one can extract all the meshes on import and save them to resource files, perhaps that's the way to go. Although, a side-effect/issue is that when you do extract/save the meshes to files, the glb becomes redundant (ito of final export of the game) and you have to remember not to include it or to delete it. Can one mark files for non-inclusion in an export?

[AThousandShips]

the glb becomes redundant (ito of final export of the game) and you have to remember not to include it or to delete it

The glb won't be exported, it's imported, this doesn't change with this

[donn-xx]

Oh. I have been stuck in tool-land for so long that I've yet to try exporting anything.

Is this true when you make an "Inherited Scene" based on a glb file?

[AThousandShips]

Yes, it's imported and the data is converted, Godot can't handle glb files directly, it imports them and converts them to our native data formats, same for obj, fbx, blend, etc.

[donn-xx]

Well, I did not know that. Thanks.

[donn-xx]

Okay. Thanks to your feedback, I am going to rethink my approach of using scenes as libraries and just go with the godot. I will extract meshes and use folders to categorize things.