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

[KoBeWi]

Describe the project you are working on:
A very big metroidvania game with lots of assets.

Describe the problem or limitation you are having in your project:
I have hundreds of assets in my project (and not counting text assets like .tres or .tscn). About 90% are PNGs and the rest is WAVs and OGGs. And because each of them have a corresponding .import file, this number is doubled.

Now, the amount of assets is not a problem in itself. The problem is that I spend lots of time in the system file explorer, because I can't do everything from the editor (e.g. I can't edit an image and duplicating files is more difficult). And the .import files make it really difficult to efficiently manipulate files. I organize everything in sub-folders and for almost each folder I have to change sorting to sort by type, because the .import files are intertwined with the relevant files and I often get lost because of this. It's horrible.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Most of the times, the .import files are completely useless. In my project, I only ever change texture filtering/repeat options (which will no longer be a thing in 4.0) and loop points in some OGGs. Every other .import file (so like 70% of them, or ~95% in 4.0 with the new filtering settings) has a default value.

My proposal is: remove these files. If an .import file has default settings it means it can be auto-generated and you don't need it in your project. They should just go away. Disappear. Vanish. Only modified .import files should be kept. This would reduce file clutter immensely.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
When importing asset, don't store .import file for this asset if it's imported with default import settings. This should be checked also on reimport and the file should be created/removed automatically whenever necessary. AFAIK .import files store some necessary information related to the file itself (remap or something). This is however auto-generated, so it can be stored inside .import directory.

Before:

After:

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Nope, there's no way to avoid it with scripts.

Is there a reason why this should be core and not an add-on in the asset library?:
Because it's tightly related to import system.

btw, this was formerly discussed here: godotengine/godot#24177

[Fatesight]

Not storing the .import files at all could be a problem if you change the default import configuration down the road.
Maybe storing the .import files in a dedicated folder instead of the asset's location would be a better solution. More explicit than not storing them (see the "explicit is better than implicit" principle), and doesn't litter the asset folders.

[KoBeWi]

Not storing the .import files at all could be a problem if you change the default import configuration down the road.

In that case, you can reimport all assets with previous defaults (although that basically reintroduces the problem...)

But tbh, is there any way for the new defaults to change and break anything? I doubt it will be decided that we should change something that will impact many projects and won't be necessary.

[Fatesight]

Major version numbers allow for breaking compatibility, so this could be done in 4.0, complete with automatic migration so you don't have to manually reimport anything (it would basically just come down to checking if an asset has an import file in the current location, and if it does, moving it to the dedicated import folder).

[escargot-sans-gluten]

Import files could also be hidden: .image.png.import

[bitsycore]

Maybe having a .import_config folder in every folder where a file have been imported could solve

• .import flood
• more clear because some people confuse the .import forlder and the .import files

[KoBeWi]

Maybe having a .import_config folder in every folder where a file have been imported

This is a totally bad idea XD
Although a single .import_config file per directory wouldn't be that bad.

[bitsycore]

This is a totally bad idea XD

Why ? The .import_config would be a carbon copy of the folder it's in but just with the config, so they would all be in the same place

[KoBeWi]

Why ?

Well, I have an aversion for having too many directories in the project, because they create more clutter than files.

Bun on a second though, if it was hidden in the editor (which is rather obvious it would), there wouldn't be a difference if it was a file or directory 🤔

[bitsycore]

Yeah it would be hidden.
I don't like the Idea of one file because of version control or even managing it manually (deleting a config)

[nathanfranke]

For people sorting their file managers by alphabetical, there could be a prefix for the import files. Kill two birds with one stone by putting a . in front.

While the input files would still be in the same directory, they would be grouped next to each other and separate from the actual assets.

[marcospb19]

This is however auto-generated, so it can be stored inside .import directory.

100% agree, this solves all problems, there's no point in having .import files at the same directories of the assets.

[gpp-games]

I was about to make an Issue concerning the *.import-files clutter, because of other reasons. Also because it's a mess and it's ugly. I support the idea to place the .import files in a dedicated folder under project-root. At least as option in project-settings
Another reason why this might be useful for some users ( including me):
It would make it possible, to create a link to e.g. a textures folder in multiple godot-projects.
So you don't need to have a copy of e.g a texture for every project you use it in.

[akien-mga]

We discussed this today with core contributors.

The consensus was that we don't think it's a good idea for the following reasons:

• The values in .import files are important to know how the file should be imported. If the default values change in a new version and you reimport resources (which typically happens if you don't version the res://.import/ folder), your project will start behaving differently.

• The default values are arbitrary and may indeed change from one version to another. It's not safe to count on them staying the same.

• Most importantly, the .import files don't just contain settings, but also metadata which is used by the engine. Notably the path is res://.import/ at which the file has been imported, so that it can be remapped automatically by the engine. This path contains a md5 sum, so if the .import files were removed, the engine would need to recompute the MD5 sum each time it needs to access the file instead of just reading the .import file.

• Some users rely on those .import files in their project to be able to load things manually.

Some of the reactions here also show a confusion between the files generated in the res://.import/ folder (which will always be re-generated the same by a given editor version for a given .import file, and can thus be safely ignored from version control systems) and the .import files which are also initially generated but which then contain user-defined settings to import resources. Those should not be ignored in the version control system, as they define how your resources will be imported. About that confusion, see #1521.

As for renaming them for visual grepping, I don't think that this is more useful than having them share the same prefix as the file that they qualify. IMO it's fine as is.

[marcospb19]

@akien-mga thanks for your response and explanations, there was one thing I did not understood yet, what are the problems involved with moving everything related to .import files into a single folder at the root of the project? That is, changing the location of file.png.import to .import/file.png.import.

I think that this is different from what you commented above, correct me if I'm mistaken.

[dalexeev]

Most importantly, the .import files don't just contain settings, but also metadata which is used by the engine. Notably the path is res://.import/ at which the file has been imported, so that it can be remapped automatically by the engine. This path contains a md5 sum, so if the .import files were removed, the engine would need to recompute the MD5 sum each time it needs to access the file instead of just reading the .import file.

@akien-mga Please note that this md5 sum is not the contents of the file, but only its path. For example, I have a file res://etc/icon.png. Godot generated the following res://etc/icon.png.import:

res://etc/icon.png.import

[remap]

importer="texture"
type="StreamTexture"
path="res://.import/icon.png-b0fd82336b2064d119cfeda1d5da9183.stex"
metadata={
"vram_texture": false
}

[deps]

source_file="res://etc/icon.png"
dest_files=[ "res://.import/icon.png-b0fd82336b2064d119cfeda1d5da9183.stex" ]

[params]

compress/mode=0
compress/lossy_quality=0.7
compress/hdr_mode=0
compress/bptc_ldr=0
compress/normal_map=0
flags/repeat=0
flags/filter=true
flags/mipmaps=false
flags/anisotropic=false
flags/srgb=2
process/fix_alpha_border=true
process/premult_alpha=false
process/HDR_as_SRGB=false
process/invert_color=false
stream=false
size_limit=0
detect_3d=true
svg/scale=1.0

Yes, this file contains the line path="res://.import/icon.png-b0fd82336b2064d119cfeda1d5da9183.stex".
But MD5("res://etc/icon.png") = "b0fd82336b2064d119cfeda1d5da9183"!
A copy of the image is stored at res://.import/icon.png-b0fd82336b2064d119cfeda1d5da9183.stex.
And the md5 sum of the res://etc/icon.png's contents
is stored in the file res://.import/icon.png-b0fd82336b2064d119cfeda1d5da9183.md5.

For example:

source_md5="47313fa4c47a9963fddd764e1ec6e4a8"
dest_md5="2ded9e7f9060e2b530aab678b135fc5b"

As we can see, these are completely different MD5s.

And all other import parameters can be saved to the project.godot file using this feature:

Fragment of the project.godot file

[importer_defaults]

texture={
"compress/bptc_ldr": 0,
"compress/hdr_mode": 0,
"compress/lossy_quality": 0.7,
"compress/mode": 0,
"compress/normal_map": 0,
"detect_3d": true,
"flags/anisotropic": false,
"flags/filter": true,
"flags/mipmaps": false,
"flags/repeat": 0,
"flags/srgb": 2,
"process/HDR_as_SRGB": false,
"process/fix_alpha_border": true,
"process/invert_color": false,
"process/premult_alpha": false,
"size_limit": 0,
"stream": false,
"svg/scale": 1.0
}

Thus, the algorithm for determining the parameters is as follows: if there is a corresponding .import file, we read the parameters from it. Else read from the project.godot. Else read from the engine defaults.

[kienvn]

I think .import files should be stored inside a directory like .import_info or .godot. Example res://.import_info/etc/icon.png.import or res://.godot/etc/icon.png.import

[Calinou]

I think .import files should be stored inside a directory like .import_info or .godot. Example res://.import_info/etc/icon.png.import or res://.godot/etc/icon.png.import

*.import files must be committed to version control as they contain important metadata (such as filter/repeat status for textures).

Note that the .import/ folder has been renamed to .godot/ in 4.0 to avoid confusion with *.import files.

[turtl8]

I just created a project for a quick test to report a bug, and in my rush I created the project in my home folder. I didn't realize what I had done until it was too late. Godot proceeded to mess up my entire home folder with import files without mercy, and there was no way to stop it.

I know it's my fault, but the approach used by git of creating any files inside a .git folder seems much better, and if Godot did the same messing up like I did would basically be impossible.

[YuriSizov]

@turtl8 Unlike the git folder, you are supposed to include these files in your version control system, so they must be a part of your project structure, and not hidden away.

[turtl8]

That's a different topic I think?

What I was saying is that the generated files could be in one place, and not created all over the place and polluting the user file system. That doesn't require that they are in a hidden folder or anything, I just used git as a popular example of having them in one place.

[Calinou]

The correct fix is to prevent Godot from creating a project directly within $HOME, as this can also "brick" the editor if its binary is located directly within $HOME (or if its binary is run with $HOME as the current working directory).

[YuriSizov]

That's a different topic I think?

What I was saying is that the generated files could be in one place, and not created all over the place and polluting the user file system. That doesn't require that they are in a hidden folder or anything, I just used git as a popular example of having them in one place.

There are two "generated" files associated with each asset. One is its import config, which is stored in the <asset_name>.import file next to the asset and another is its imported version, which is stored in the .import/.godot folder. The former must be committed to the repository, as it ensures deterministic outcome whenever you deploy your project on a new machine. The latter can be safely ignored and removed.

You gave an example of Git having a .git folder, which is its service folder, used for storing temporary information about your local working copy. Godot has such folder too, called .godot in Godot 4 (and spread all over the place in Godot 3, namely .import, .mono, and in editor's files). This folder is used for the latter generated file, the imported version of your asset. But putting an import config into such a folder doesn't make much sense. This folder should not be included into your VCS and import configs should, so we would need to create another service folder for import configs, which creates more noise for users. On top of that, it becomes harder for users to find import configs corresponding to each asset, because they are no longer clearly paired.

So as mentioned above, to solve your problem we should instead consider some paths protected and never allow to create a project in them. Your proposed solution, while also addressing your problem, has a negative impact for the normal use of the engine.

[turtl8]

This folder should not be included into your VCS and import configs should, so we would need to create another service folder for import configs, which creates more noise for users.

I would think creating a single folder in one place might create less noise than creating files all over the place. It's not just git, I can't think of any software that creates a bunch of files in a user directory and doesn't put them all in one place, vscode, dropbox, node_modules... all put things in one place, and git tracks dot folders by default: plenty of people keep the .vscode or .idea directories in their source control.

But the worst case scenario is probably just careless people like me messing up the home folder, preventing that might be good enough so I'll stop arguing and leave you to more productive things.

[KoBeWi]

I can't think of any software that creates a bunch of files in a user directory and doesn't put them all in one place

Unity and its .meta files. It's even worse than Godot, because every single file has a meta, not just imported files.