GeForceLegend

Can confirm this is some rendering order related issue. Sometimes the game will draw like this: wolf > armor crack > collar > wolf armor. There might be some other orders, when the crack is drawn before armor itself, crack will disappear.

Consider banner patterns also require a strict rendering order, maybe we can apply similar thing on wolf armor crack?

Should be fixed in 26.1 snapshot 11 alongside MC-275014

Looks like it was fixed in certain snapshot of 26.1. Smoothed sky light level around most opaque light sources is no longer reduced.

Sorry that I haven’t found this before submit a new one. I’ll copy my info from MC-307156 to here.

It’s caused by vanilla now force redstone wires being translucent, and as vanilla tried doing something close but not equals to nearest sample in a linear texture, screen pixels near redstone wire pixels may contain some very low alpha value. Even though it does not do some obvious effect on scene color, it does write to depth and result in z fighting with other redstone wire layers. If the layer with very low alpha pixels win, the seams appear.

Above assumption can be approved by the seams disappear if sample texture with texelFetch like vec4 color = texelFetch(Sampler0, ivec2(texCoord0 * TextureSize), 0) * vertexColor; in terrain shader, which let redstone wire pixels be fully opaque or fully transparent, without the possibility of any low alpha pixels.

Personal suggestion: as vanilla now can correctly handle tranlucent texture, there is no need to force redstone wires being translucent. And, multi layer models like redstone wire does not fit translucent well after vanilla added RGSS and anisotropic filtering.

I can understand banner pattern is removed after moderator’s edit since it looks correct behind block entities. However, this is also one of the transparent overlays for solid objects. There might be potential scene that can also make banner pattern disappear behind transparent objects.

Here is the minimal setup resource pack only add minecraft:block/oak_planks into item atlas.

These two do not relate to a problem. MC-204939 is caused by display value in item model file, but this one is caused by player animation.

This is caused by ambient occlusion of emitting opaque blocks are achieved by modifing smoothed skylight. This can be easily seen when loading with Optifine and a shaderpack. Lots of shader features uses skylight, for example, puddles in rainy weather. You can see there is no puddles near these blocks.
And for emitting opaque blocks with light level less than 14, their ambient occlusion seems also modify smoothed block light map. Smoothed block light of pixels near them can even drop to 1 (since this is smoothed light map in rendering, the light value in F3 screen is normal).

Using builtin/generated still cause some color change like [198,198,198] to [196,196,196], same as rotation (form -2.6° to -89°, the color keeps same). It seems that the new render engine makes the game can't restore the texture color in GUI.

Why not use the translation version on Crowdin? That version is pretty good and favored by we players.

If you guys just want models look like default in GUI, why not try rotating your model like this?
"gui":{
"rotation":[-60,0,0],
"translation":[0,0,0],
"scale":[1,2,0.01]
}
By rotate it 60° and rescale it, item models will be like using builtin/generated too.

They just need "cullface", but for some blocks like iron bars, adding cullface data will cause other bugs.

This is not a duplicate of MC-60242! This bug will even appear when using multipart in blockstates file!

Even Feather Falling can be applied on other pieces of armor. All protection enchantments do not mutually exclusive anymore.