Creating modified scene copies during import can clutter the filesystem

[fire]

Project Description

I am currently working on a VR Virtual Worlds project. The project has the potential to be an open world and is being developed using the Godot Engine.

Describe the problem or limitation you are having in your project

For our project we don't have this problem because each entity scene is loaded dynamically from an online cdn. We have to live with thousands and thousands of scenes.

The main issue EMBYRDEV is facing is minimizing the number of instanced scenes in her project. A common method involves setting a target, executing an action, and then making adjustments based on the outcome. However, this approach doesn't allow for adjusting the initial target, which results in an additional, unnecessary instanced scene.

Moreover, it's challenging to check the advanced importer scene settings for optimization. Modifying the result creates yet another instance. For more details, refer to the proposal by @EMBYRDEV here.

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

To overcome these limitations, I propose the following enhancements:

1. Expose the properties to the importer as described here.
2. Find a way to merge the settings back into the .import file to eliminate the difference.
3. Provide a way to quickly assign classes of imports.

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

The specific implementation details are yet to be determined.

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

This enhancement cannot be worked around with a few lines of script because a new script needs to be written for each type of import.

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

This should be a core feature rather than an add-on in the asset library. Our aim is to make developers' lives easier and ensure consistency across the board.

[EMBYRDEV]

Thank you!

[fire]

@EMBYRDEV I forgot something, did you know that if you rename an .tscn as .escn it'll reimport and the settings can be advanced imported again. There's some generational loss though.

[lyuma]

I put a link in #78803 since I was told this was the proposal for that feature PR. The title is somewhat misleading since it is using plurals when in fact this proposal can only solve the case of a single modified scene copy. To be clear, after importing a scene, if customization of the imported scene is needed, only a single extra file per imported scene is needed, and it should be inhertied rather than instantiated. Does that make sense.

That is to say, when you import a .glb file, if you want to change mesh layers, the current workflow will create foo.glb, foo.glb.import and a foo.tscn which inherits the imported scene. This proposal would be to eliminate the .tscn by allowing properties changed in the .tscn to be saved as part of the imported scene.

Now, I'll try and generalize the points I made in a comment here: godotengine/godot#78803 (comment)

As I noted in the above linked comment, this proposal is already implementable as an addon. This was the intended design behind the new EditorScenePostImportPlugin system, which permits exposing project-wide advanced importer settings, and to do post-processing on the scene of a similar nature to what can be done by inhertiance.

In short, I'm missing elements of the design. For "Expose the properties to the importer", does this mean that all node properties which could conceivably change in an inherited scene should be exposed?

[fire]

Yes, all modified scene properties as per our saving process

[akien-mga]

Is this fully addressed by godotengine/godot#78803?

[lyuma]

In my opinion, this proposal has not been addressed.

#78803 added some helpful options commonly used by some users, but I think there are many more workflows which require creating inherited scenes that were not addressed.

That said, it would be helpful to hear from users about what their needs for inherited scenes are.

[EMBYRDEV]

Is this fully addressed by godotengine/godot#78803?

I don't believe so either, this is a wider reaching problem that godotengine/godot#78803 only partially addresses.

There are a few more properties that are likely useful to expose but as @lyuma stated I'd like to hear some more suggestions.

I'm not alergic to the idea of creating inherited scenes to do very specific setup but I dont think it should be something we have to do by default.