Don't store the .import file when using the default settings

[vnen]

Godot version:
master @ 99640ac

I know this has been dismissed before but I didn't find a proper issue about the topic, so I'm reviving the points about it. This is the result of a discussion I had with @jahd2602.

The problems

• The .import files sitting besides the assets clutter the folders. Essentially we have double the amount of files in the project, making it harder to manage.
• While those files are small, there are many of them and they occupy space in the repository. They also need to be dealt with when doing merges.
• Deleting, renaming, and moving assets require doing the same process to the related .import file. Failing to do so make the .import live there on its own, since there's no cleanup tool. While doing those operations with the FileSystem dock makes the .import file go with it, it's not always feasible to use the Godot editor for this.
• Changing the default import settings to apply to all resources requires you to delete all the .import files related to them.
• They occupy space in the exported project, even though the import options are not relevant there anymore.

The solution
Don't store the .import file when the resource is imported with default settings.

The problems with the solution

• We still need the remap information, such as path and type. This can be solved in the editor by asking the importer, but it's still needed on export. And while this information can be generated at export time, it breaks the possibility of running the source project with the release template.
• If the user change the default preset settings it should re-import everything (of the same type), but it's not clear for the editor to know what should be re-imported.
• If the new default is the same as an existing .import, it's not clear whether it should be removed.
• If we want the settings of a particular resource to be same as the default but not change with new defaults, it's not simple to force a .import file (though there could be UI for this).

[girng]

+1

also, another question is why does .import exist in the first place, of which it duplicates my files? this wasn't there in previous godot versions. for example, i have a background texture for my scene which is around 53kb. then, inside the .import folder, that file is in there again as a .stex, and is 53kb. it basically duplicated my .png file.

[eon-s]

Setting files for some resources like image files were always there (.flag I think?).

Default settings without files could make more confusing without a default settings setup on project creation and defaults manager inside the editor (plus current defaults are not too good).

[vnen]

Default settings without files could make more confusing without a default settings setup on project creation and defaults manager inside the editor

I don't think there's much of a difference since it creates the files with defaults without asking anything already. The difference is just not creating the files with the defaults. Also this all can be improved, and maybe they should anyway regardless of this proposal (same goes for the current defaults).

---

also, another question is why does .import exist in the first place, of which it duplicates my files?

This is not a big deal because it's only on the working directory. The imported assets can be ignored in the repository and the originals don't go to the exported version. In fact, this proposal does not get rid of the duplication, which is necessary to make Godot recognize the files (many resource types can change a lot in size after imported).

[girng]

imo it's a big deal because all the developer's files (textures, etc) are duplicated in the .import folder. this can drastically increase the project's file size. my example might be bad because it's just one 53kb file, which now the developer will need 106kb of space. i'm trying to say: imagine larger projects with tons of textures.

i think the .import file that sits next to the file should be sufficient

[volzhs]

what about having .default_import file on project root directory, and .import files if the individual file setting is different from the .default_import?

[NathanWarden]

imo it's a big deal because all the developer's files (textures, etc) are duplicated in the .import folder. this can drastically increase the project's file size. my example might be bad because it's just one 53kb file, which now the developer will need 106kb of space. i'm trying to say: imagine larger projects with tons of textures.

i think the .import file that sits next to the file should be sufficient

It's not actually duplicating the files though. It's importing them into a format that can be used by the engine. So, without the import folder your machine would have to re-import these files each time you open the project and then store all of these assets in RAM. So, it's highly necessary to have an import folder. It really isn't that bad as far as space goes. Unity does the same thing. I have countless 3D projects that I've worked on for clients over the years and have plenty of drive space. :)

[Zylann]

A note about the space .import takes, I think it has been reported that files in it are not always cleaned up, so it often grows unnecessarily over time (though I can't seem to find an issue about it?). This in particular should be an improvement to work on as far as space is concerned, but otherwise I agree with @NathanWarden.

About .import files cluttering the project... I just don't bother anymore. I'm used to it (and all points listed), working with Unity half of my time in a team project, there are such files even for scripts. We know what they are for, they aren't complicated (even readable) and in the end clutter is relative, because we don't work often directly with the raw filesystem for convenience and perhaps even scalability (editor's asset browser, IDE script explorer etc).
In that sense I would kinda not like the fact .import files sometimes are there, sometimes aren't, based on some exceptional rules about default properties, because it makes their behavior a bit more complicated. But overall I'm just used to that. I guess the benefit comes if you never change import settings?

How come they end up in exported projects though? I thought they were mostly useful for project edition cycle?

[groud]

But if you change the default import settings, what happens? All already imported resources are going to have a new .import file so that their import setrings stay the same ?

Honestly the current system is a little bit more clutter but at least it is simple.

[vnen]

How come they end up in exported projects though? I thought they were mostly useful for project edition cycle?

They contain the path remap information, so the the engine knows that the PNG you're referring to is now a STEX in the .import folder. They also still contains the import parameter, which I think should be stripped on export, but that's another topic.

But if you change the default import settings, what happens?

That's one of the problems. IMO though, if you are importing everything with default is because you want the defaults, even if they change.

what about having .default_import file on project root directory, and .import files if the individual file setting is different from the .default_import?

This can be done. Right now the changed defaults are stored in project.godot.

---

I want to add that a major point is that it's not always immediately clear what the .import files are for. This discussion started because of a project I joined and they were ignoring all the .import files in .gitignore because they were generated automatically, so the files don't seem important to the repository.

The current behavior is not as intuitive as one might think.

[realkotob]

That's one of the problems. IMO though, if you are importing everything with default is because you want the defaults, even if they change.

I think that's a good enough reason to accept the change.

[akien-mga]

I'm fine with not saving default import flags, but only if users are asked to select import presets for their resources when they create a new project, and this setting is saved (in project.godot). This way they know that their import flags won't magically change when upgrading their Godot version, as we'll treat any change to preset defaults as a compatibility breakage.

[aaronfranke]

For the last 2 points, perhaps existing files should never be deleted, but new files are not created unless the user changes anything. So then if you want to preserve the existing settings regardless of the defaults changing, you simply change a setting and then change it back.

This would mean that existing projects would have the same files, but...

Perhaps there could be a button in Godot that removes all default-only .import files?

[girng]

It's not actually duplicating the files though. It's importing them into a format that can be used by the engine.

well, i don't know how else to word it then lol. i just see a 53kb .png background in my Textures folder. then, there is a file that has the same name of it, inside .import, that is 53kb. i just thought of the word duplicate, but even if it's not a 100% duplicate of the file, it basically does x * 2 on storage space. which imo is not needed. and this was not a problem in previous godot versions AFAIK

[eon-s]

@girng 53kb is too much for import flags, even 1kb is a lot
It seems like a bugged import, can you look at it with a text editor?

[Zireael07]

@eon-s: He probably means .etc or .tex in .import folder, not .import file.

[aaronfranke]

@girng @Zireael07 In that case: #23368

[eon-s]

Oh, files inside the import folder, right...

Maybe the import extension needs to be changed to not confuse it with the folder, but that is for another issue...

[Zireael07]

@aaronfranke: I was gonna link that issue but I couldn't find it.

[vnen]

BTW I did a proof of concept of this proposal. Still don't solve all the issues. I save the *.import files inside the .import/ folder when they have default settings, so they are still there for the remap check but doesn't need to be tracked.

Link to my changes: jahd2602/godot@3882e0d...98eb965

[VitaZheltyakov]

The .import file problem is manifested when there are a lot of assets and they are in different directories. This is a big game problem.
We must respect the developers of the big games and give them the opportunity to choose.

[clayjohn]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!