Can reproduce, but only by placing atlas json under custom namespace.
[media]When placed in minecraft namespace, all block and item textures would be erred, but when placed in custom namespace nothing happens.
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 shearing (right_rotation) seems to only be M = UΣ, where V* is missing and has to be compensated with left_rotation.