Creating AtlasTextures in Godot 4.0 beta 4 causes re-imports every time we reload, and engine runs slower

[LakshayaG73]

Godot version

4.0 beta 4

System information

Windows 11

Issue description

I've started using AtlasTextures on all my sprites for the massive VRAM savings.

There are three issues -:

1. Everytime I open the project now, I see errors like this that eventually go away:

2. There are reimports every time I open the project

3. The engine seems to be running on a different setting now. It is generally slower, and specially if I alt tab, it takes it a few seconds to wake up. This happens any time I change the window, and otherwise when navigating the filesystem.

The VRAM savings are good, but slowed development is bad. Thanks for your help.

Steps to reproduce

1. Use atlastextures in project

Minimal reproduction project

No response

[LakshayaG73]

Every time I alt tab and come back, CPU usage shoots up to 30%.

[Calinou]

@LakshayaG73 Please upload a minimal reproduction project to make this easier to troubleshoot.

We can't do anything here without a MRP, so the issue will have to be closed in 7 days otherwise.

[LakshayaG73]

Let me try and create an MRP for this with just one atlastexture, it should be enough to show that it keeps trying to load the texture.

The issue is very evident. Every time I alt-tab, or minimize the godot window, or even play the scene, I am reloading all the textures that point to sprite atlases:

This is happening every time I alt tab! This cannot be normal behavior.

[LakshayaG73]

MRP.zip

The project above is small but experiences all the issues as described above even with a single atlas texture. Seems like the feature is broken.

You will experience huge delays when alt tabbing and opening the project.

[LakshayaG73]

I can see that this is coming from:

Could it be because this cache mode has been set incorrectly? Shouldn't these resources be cached somewhere?

[LakshayaG73]

The cache mode could be set this way due to 'load from file' being called, because the image is not being loaded 'OK'.

Please let me know if this is the right path?

[AThousandShips]

Doing some digging it looks like the hash for TextureAtlas is broken, not sure exactly what's going on but on reload the md5 hash for the atlas file is changed, this would naturally cause the editor to reimport it, and thus force the target file to be reimported, on each entering of the editor, will see if I can find where this occurs and what is going on exactly with that

It appears it occurs even if the hash is the same, no clue what's going on with that now, suspecting something is going on with group imports or related, but the issue in any case is that the file is reimported each time due to some check failing somewhere

[AThousandShips]

Ignore all that, it turns out it was way simpler:
Files included from a group are not given a UID on import, possibly an oversight from past versions I don't know, however import files without one are always queued for import, therefore these atlas files are always reimported

I'll look at a PR for this tomorrow, some brief testing shows promise

[LakshayaG73]

Thank you for your efforts, much appreciated

[AThousandShips]

There seems to have been a second issue as well where under some condition (like opening the editor) the target file would be reimported on its own, and then the group would be reimported, which would more or less double the import time under those conditions, so adding a tentative check to prevent files that are groups from being imported twice

[AThousandShips]

Also, for the future I recommend you not include the .godot folder in your MRPs, it can contain information about your computer that could be a security risk, not a big deal in this case but a good practice to keep in mind

[Calinou]

Also, for the future I recommend you not include the .godot folder in your MRPs, it can contain information about your computer that could be a security risk, not a big deal in this case but a good practice to keep in mind

Is that actually the case? Please don't spread this kind of information without verifying it beforehand (and reporting it in a dedicated issue if it turns out to be the case).

[AThousandShips]

Oh I'm sorry I thought I had seen that being pointed out before! And considering the issues with files in git repositories

[AThousandShips]

I had understood that file paths external to the res:// filespace was an issue, and there is the reference to the executable in there somewhere

[kleonc]

Is that actually the case?

@Calinou I've briefly checked the files from the MRP and this can be found in the .godot\editor\project_metadata.cfg:

[editor_metadata]

executable_path="C:/Users/User/Downloads/Godot_v4.0-beta4_win64.exe/Godot_v4.0-beta4_win64.exe"

[Calinou]

The metadata storage in question was added by 2f15106, likely for use by the Godot Rider plugin.

@van800 Do you think we could make it a relative path if the executable is located within %USERPROFILE% (Windows) or $HOME (macOS/Linux) (or any subdirectory of it)? This prevents the username from being stored in the path. The path can be stored as absolute if the executable is saved outside the home directory, since it won't contain the username.

[van800]

I am under the impression that .godot content including project_metadata.cfg is not supposed to be added to the vcs. If so, then what is the issue with the username?

[Calinou]

I am under the impression that .godot content including project_metadata.cfg is not supposed to be added to the vcs. If so, then what is the issue with the username?

It's not supposed to be committed to version control, but some people still include it in ZIP archives they create to upload as minimal reproduction projects here (or on other places).

Including the username is problematic for people who use their real name as their OS username and wish to keep their online identity private. Not everyone can change their OS username (e.g. on corporate/university-owned machines). Even when changing the OS username is possible, it requires recreating a new and moving everything, which is a time-consuming process. This was discussed in another issue/proposal, but I can't find it right now.

[Zireael07]

We discussed it in #29674 (I managed to find it by searching for "privacy")

[LakshayaG73]

Sorry to derail this conversation a bit...

Regarding this issue. The PR from @AThousandShips works great.

There is one more thing that I've noticed. Which may be by design, but I'm not sure. I've noticed that the width of the atlastexture doesn't go below 2048:

Can't help but wonder about the extra dead space here as well. Is this done on purpose?

[kleonc]

There is one more thing that I've noticed. Which may be by design, but I'm not sure. I've noticed that the width of the atlastexture doesn't go below 2048:

@LakshayaG73 You mean it doesn't go above 2048? That's indeed the default value which is currently used for the max width by the atlas packer:

godot/editor/editor_atlas_packer.h

Line 71 in 256069e

static void chart_pack(Vector<Chart> &charts, int &r_width, int &r_height, int p_atlas_max_size = 2048, int p_cell_resolution = 4);

Can't help but wonder about the extra dead space here as well. Is this done on purpose?

Is there an extra dead space though? Looking at the preview you've shown it seems like it's just zoomed out and the preview's transparent background is rendered way bigger then it should (not just behind the actual image) as this rectangle has approximately 2048 / 18556 aspect ratio:

[LakshayaG73]

whoops. you're right. thanks for the clarification!

[LakshayaG73]

There is one more issue here it seems.

If I use a Mesh to pack these textures together, like I've done in the image above, and try to add the frames to a spriteframes, some frames show up as empty. The reason is that some frames are simply not added to the mesh. This does not occur if you select 'region' when creating the AtlasTexture.

Mesh2D, created with the same frames:

Region, created with the same frames:

[LakshayaG73]

The same frames are being skipped every time. Perhaps they are being considered duplicates?

[kleonc]

The same frames are being skipped every time. Perhaps they are being considered duplicates?

@LakshayaG73 No idea. But for sure it seems like a seperate problem. So please open a new issue and provide all needed details in there (and an MRP so it could be investigated properly).

[LakshayaG73]

#68350

[LakshayaG73]

Could you please remove the "needs testing" label from this @Calinou as there is a PR out. Thank you.