Add ability to reference subresources and inspect them in filesystem

[reduz]

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

Godot users, in one way or another, want to reference subresources from scenes. The most common example of this is being able to reference meshes or materials from imported scenes (GLTF or FBX) directly, like they do in other engines such as Unity. But there are also other cases, such as slicing a texture manually and accessing its sub-atlas textures.

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

While this is possible to some degree, it is not to others. Not every resource type makes the built-in subresources easily accessible, as example:

• Binary resources (including imported scenes such as FBX or gltf) have easily accessible subresources.
• Text resources (such as tscn, scripts, etc) are very inefficient for subresource access because the whole file needs to be parsed until the subresource is found.

So, ultimately, this feature would work in some file formats but not others. Or, alternatively, it will work in all file formats but with a warning when you open an inefficient one (like .tscn) that accessing these subresources is very inefficient, hence discouraged (which one should it be?).

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

There is an implementation for this feature here, so as you can see It's not too complicated to add. What would be missing is extending the filesystem access for this.

This work would consist of:

• EditorFileSystem, which caches the filesystem state, needs to keep a cache of subresources in each file, or at least store that the file has subresources.
• FileSystemDock, EditorFileSystemDialog and QuickOpen need to provide a way to explore the sub-resources.
• The Editor previewer needs to be able to create thumbnails for subresources.

For FileSystemDock we can add this icon:

Or, if in this mode:

This would change the filesystem dock to a sub-resource explorer:

(yes its the same thing, use your imagination as if these were meshes and materials):

This way of exploring sub-resources can be a reusable control that can be used in EditorFileSystemDialog and QuickOpen (replacing the current list by this control). The sub-resources control would just show the icons of the sub resources (that you can turn into a list if you want) and that lets you search.

This way, the other dialogs can have this too:

FAQ
Q: Why a subresource button and not directly show them as part of the filesystem?
A: I think this is really hard to do on many levels. First, It's something that is both a file and a folder, so it does not fit the traditional folder structure. Additionally, these files can have thousands of subresources, so it may not be a great idea to make them part of the regular filesystem transparently. Finally, I think usability wise, it is better they are considered an exceptional case for simplicity.

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

N/A

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

N/A

[Flynsarmy]

They should be available for both binary and text resources for consistency IMO though a warning should be emitted when accessed via a text resources explaining how this is not optimal and will result in significant slowdowns.

Making them available to text resources with no warning will likely result in the perception that Godot is a slow engine by those who are unaware of this limitation.

[reduz]

@Flynsarmy well technically on export all text resources are converted to binary, so it may not be terrible, but for gameplay It may be a major annoyance if you don't know what you are doing.

[SaracenOne]

This sounds good to me. The initial implementation I did was simply there to fix a bug with the animation libraries, and I deliberately didn't make it user-facing until a proposal was formalized for how it could be exposed. Are you okay with the underlying technical implementation in my PR though, simply using of the '::' notation to indicate a sub-resource reference?

If that's all good, I can probably move onto to implementing the UI required for making this happen.

[xzbobzx]

This sounds really promising, it addresses the biggest issue I've had with using Godot's 3D importer.

You mentioned it yourself in another comment on another thread:

Some prefer to edit a whole stage in Blender and then export to Godot and at much tweak the materials. Others prefer to import individual assets and build whatever they need in the engine.

I'm definitely the latter group, and Godot's importer has been pretty frustrating to use as a result. So I'm very glad that this is being addressed!

Anyway, this is basically exactly what I suggested in my comment here: #7494 (comment)

To make sure we're exactly on the same page, I'd like to sketch my current Unity workflow and see if this new proposal would allow that? I've translated all Unity terms to Godot terms.

The way I work is I treat imported mesh files as libraries with mesh resources, and it works like this:

• Import 3D File (.fbx/.gltf/.blend/whatever)
• Create new empty Node in a new empty Scene
• Add MeshInstance3D nodes as needed
• Drag Mesh Resources form 3D File into the MeshInstance3D nodes, or select with Quick Search
• Apply materials created in the engine
• Use the Mesh Resources, or select a different one, to create collision mesh nodes (?)
• Save the whole node tree I've just built as a Scene Resource

Then, whenever I want to iterate on the design of my scene, I can make adjustments in Blender, export a new file, import the new file in Godot, and all of the Mesh Resources inside the Scene Resource I built automatically update, allowing me to instantly test my changes.

I create 3D models in the 3D modeling program, and then use the game engine to put those models together into a scene.

From the way I understand this proposal, this should become entirely possible in Godot, but I'm writing this comment to double check and avoid making assumptions.

One thing I'm especially curious about is whether the mesh resources would automatically update across the project when an updated version of a 3D file gets imported? It would be rather tedious if I need to go through all of my scenes and manually update every mesh resource reference each time I import a new model.

Finally a small comment on the collision mesh node (?) part of my workflow:

I think the way collisions mesh nodes work in Godot is probably beyond the scope of this proposal. However in Unity, a single Mesh Resource can be used for both rendering and collisions, while in Godot (last I checked in 4.1) separate resources are required.

Will this proposal also streamline/automate the generation of collision meshes, or is that a wholly separate topic?

[JoNax97]

This looks very promising!
Regarding the slowness of text-based resources, I understand this is only an issue in-editor. Can the sub-resources be indexed/cached somehow to keep the slowness to a minimum?

And regarding the UX of the file system, I'd much prefer going with something similar to Unity, where assets can be expanded in-place to show their sub assets, like so:

Which brings me to the last point, which is that sub-resources would need some way to give them a human-readable name (probably optional) to help identify them in the editor.

[reduz]

@JoNax97 I thought about expanding assets in place, but in the case of Godot it's too complicated to do, maintain and keep performant, plus in Godot a lot of users also access assets via the filesystem dialog or quick open and don't touch the FS dock much, so we have to make those work too.

Ultimately it is simpler (for now at least) to just enter/exit the asset in our case. If at some point someone in the future wants to make a more complex interface and it works well, then that's fine.

[aaronfranke]

See also the discussion here: #7494 (comment)

@xzbobzx proposed the same thing in the comments of my proposal. It's a really good idea, I like this proposal.