eleazzaar

May relate to MC-130026.

It does not.

Except in the vague, general way that both involve UVs.

@Orbic

Each leg has a unique texture.

Both horns use the same UVs and are not mirrored.  

Arguably they should be, but it is less of a problem that the non-mirrored ears.

This skin should make the issue abundantly obvious.  There should be unbroken blue and purple stripes from head to toe-- as in this block bench screenshot.

If the blue and purple switch sides on the leg, then the model is still wrong.

This bug still exists in at least the Windows 10 v1.16.20.  The left leg (the one on our right as we look at the front of the mob)  is still wrongly mirrored.

It should look like this:

The above skin is from the marketplace pack: Lithos Monstrous Mobs

Brenden Scott Hand is correct.

It's not just chest plates.  If you use the "sleeve" area of the the texture (same location as any other player-shaped mob-- including player skins), the sleeve animates properly with the arm, except when doing the "staring at gold" animation. 

Note that because "Programmer Art" is basically the 1.13 art, this means it is impossible to build a texture pack that works correctly for 1.13 and 1.14.

For example in 1.13 zombie_villager.png has an area used for the arms and hands, where 1.14 looks for the hat.

Unless this is somehow fixed, 1.13 and 1.14 are really not using the same texture pack format.

OK, nevermind. I expected the standard 1= true, 0= false.

Confirmed in 15w37a.

It is fairly annoying. We can turn the shading to "false", but that has a miniscule effect compared to this lighting glitch.

I believe i'm seeing this same error. Custom models that worked fine in 1.8 (which doesn't specify all UV coordinates) have textures that have aligned differently in the snapshot.

"What is the fix for this when it only happens in certain resource packs? How exactly should the resource pack be fixed?"

All the files in the resource pack must be the same resolution, including banner_base.png which is not inside the banner folder. If not you'll get some or all of the banner looking white no matter what color it is dyed.

Sphax:

Good catch! I missed resizing "base.png". Once i resized that everything worked fine in HD.

See image "banners2"

Image Attached: Some "disallowed" HD banners. The only glitch is that the background isn't supposed to be white.

Maybe i'm missing something technical, but it looks like you have full entity HD support 99%+ complete.

As Sphax says, every single entity, except banners works perfectly fine in HD.

Additionally banners almost work in HD. The only issue with my HD banner textures is that the base color of the banner gets turned to white.

The original poster's problem is probably that he forgot to change banner_base.png. If that is a different res than the patterns the patterns don't show up.

I can confirm that the fix Carl suggested almost worked. 1% opacity wasn't enough to show up, but 10% did work. But that only fixed the appearance of the leaves the engine chose to show as opaque. Distant transparent leaves on fast are still there.

Carl and Brad: Your guesses do not explain the glitches i'm seeing. Opaque in the foreground, transparent in the distance.

This screenshot was taken with only the default texture pack and with mipmapping off. No vines are in the picture. Again 14w25b.

For what is is worth, this bug effects such popular resource packs as: Sixty Gig, Chroma Hills, Sortex Fanver, Good Morning Craft, and Frehdens' Meringued, as well as my own Lithos:Core.

For those who claim this is a case of artists making their pack "wrong", please explain what we did wrong and how to fix it.

Also have the crosshair issue in snapshot b with my resource pack – only when stuff is in the inventory bar.

Not fixed in 14w25b.

• Leaves still are only rendered opaque if they are relatively close to the player. More distant leaves are always party transparent. (At least on my computer)

• The Opaque leave version graphics is still ignored.

I'm getting similar results.
On fast graphics:

• leaf blocks close up are rendered opaque and ugly, while

• more distant leaf blocks still have transparency.

The opaque version of the leaf blocks has been removed in this release. I don't know if that was a mistake, but it was unfortunate. Choosing the "fill" color of opaque leaf blocks is an important way texture artist make fast graphics less noticeable.

I know about duplicates and searching. But i figured explicit instructions in the crash report overrode that standard behavior.