The Bug:
When using the directory type source and specifying a certain folder, all textures under the same folder name are stitched to the final atlas. This happens across all namespaces (including the default minecraft namespace) and all resource packs.
Steps to reproduce:
Download the resource packs attached.
Apply both resource packs.
Observed behavior:
From the log, another_custom:entity/bad_texture is stitched to the block atlas even when it is from another resource pack, causing miplevel to drop.
Expected behavior:
Only the entity folder of pack 1 is stitched.
Why it matters:
Suppose we have a lightweight resource pack (Pack A) and a massive resource pack (Pack B.) Both A and B share the same texture folder "custom", but Pack A uses this folder for item textures, while Pack B uses it for other reasons such as mod resources. Pack B texture would be stitched into the block atlas even though it is not used by block/item models, disrupting the atlas structure (such as the miplevel mentioned above.)
Attachments
Comments 6
The mipmap level drop is just to show that the texture is being stitched. The problem is not just related to ambiguous folders, but also to optimizations and scope restrictions. Stitching textures obviously costs some amount of resources to compute, and there is no guarantee that 2 separate resource packs couldn't have the same folder name for different usage.
The solution you mentioned works, but only if all resource pack creators follow that guideline, an aspect that is outside our control. Resource packs can have the same folder for different reasons, folders named ambiguously because of inexperience, or contain non-square textures by chance. Worst of all, debugging faulty packs would become painful when all packs can cross reference to other packs. It's only obvious in the example that pack A is referencing pack B's entity folder because there are only 2 packs. Now imagine someone with 5-7 packs installed at the same time, they will have to check the atlases of all resource packs and check the folder names to find which pack called for the wrong stitch.
My proposed solution is simple, to allow namespace specification within the source:
{
"sources": [
{
"type": "directory",
"namespace": "custom",
"source": "entity",
"prefix": "entity/"
}
]
}This way we can guarantee that only the folder under a specific namespace is stitched, instead of accidentally stitching a folder from another resource pack and having to hunt around to find a name that doesn't conflict with others.
Edit:
And just to demonstrate the importance of scope restriction, with a simple:
{
"sources": [
{
"type": "filter",
"pattern": {
"namespace": "minecraft"
}
}
]
}I can remove all textures under the minecraft namespace.
[media]Although not directly related to the directory source, just picture a faulty regex filter hidden in one of your packs. I can't imagine how long it would take to debug that.
The way it stands though, this is absolutely intended design, and you are requesting a change, not reporting a bug.
With the previous comments, and the fact that this has been marked as a likely feature request in mind, I can confirm in 1.20.4.
This is by design, no doubt about that, or mods/resource packs would all need to add the atlas jsons to add ANY textures. What you're concerned about is ambiguous folder naming; resource pack creators shouldn't be using ambiguous folder names to begin with.
Make the texture square and a factor of 2 (at least 16x16) to prevent the mipmap dropping.
The whole point of namespaces is to provide a unique ID, even if it has the same name as vanilla (or other mods/packs), if you're going to change it so only minecraft namespace works, you're going to breaking a lot more, and making the issue just more widespread.
Again, all this needs to be fixed, is using unambiguous folder naming, instead of "custom", use "custom_entity" and "custom_gui", for example.
Internally, the atlas json files from all packs are merged, then, using the sources, all textures are fetched; at this point what pack added what source is already forgotten).