MC-269347Exported texture atlases are different each time
The bug
When using F3+S to print dynamic texture atlases, the files will be different almost every time as the game doesn't account for animated textures properly.
How to reproduce
- Use F3+S to create a debug folder in the screenshots directory
- Rename this folder
- Use F3+S again
- Compare the versions of minecraft_textures_atlas_blocks.png_0 generated
Expected results
The files would be an exact match.
Actual results
There are major differences where the animated textures are.
How to fix
When printing the atlases, only use the first frame of each animated texture as to remove this nondeterminicity.
Created Issue:
Exported texture atlases are different each time
The bug
When using F3+S to print dynamic texture atlases, the files will be different almost every time as the game doesn't account for animated textures properly.
How to reproduce
- Use F3+S to create a debug folder in the screenshots directory
- Rename this folder
- Use F3+S again
- Compare the versions of minecraft_textures_atlas_blocks.png_0 generated
Expected results
The files would be an exact match.
Actual results
There are major differences where the animated textures are.
How to fix
When printing the atlases, only use the first frame of each animated texture as to remove this nondeterminicity.
Attachments2
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
The bug
On certain operating systems and certain hardware, the "unused" regions of texture atlases can be filled with graphical data from elsewhere.
This is an issue due to in introducing unwanted nondeterminism when saving atlas files for analysis (see also MC-269347), and the fact that keeping this information in memory will also eat up extra video RAM for no benefit (see also MC-263119).
This happens on my computer with Linux (Kubuntu 24.04). Windows 11 on the same machine does not exhibit this issue.
How to fix
When generating a new atlas, fill the entire field with a single texture. I've opted for a green-and-black checkerboard, similar to the missing texture; if this ends up being displayed in-game, we can narrow down the issue to UVs pulling from an incorrect region of the atlas.
Once the image has been completely tiled over, we then add each texture to it, overwriting the checkered texture we wrote to it earlier (including transparency).
This way, any garbage data that may have persisted from earlier iterations is completely overwritten by the new checkered texture.
Further notes
A screenshot with F3 open is included, which should contain machine specifications. Do tell if further information is required.
Can confirm.
This is not a bug, the changes are from animated textures changing to different frames. This directly copies it from the dynamic textures and if it only changed the first frame then the animated textures wouldn't animate.
Obviously, and that shouldn't happen for a debug output.