The bug
The cracking animation is darker on the sides of grass blocks than it is on the top and bottom, and darker than on the sides of other blocks.
How to reproduce
Punch grass
Expected results
The side cracking wouldn't be darker than the top.
Actual results
It is.
How to fix
This is without a doubt due to the sides of grass blocks using two textures (a base and an overlay), making this issue effectively the same as MC-166101 for blocks.
For cutout-rendered blocks (of which minecraft:grass_block is one), this issue could be mitigated by not drawing the crack animation over pixels with 0 alpha. This would fix MC-142156, and would largely mitigate this issue with grass blocks (the darker cracks would be localized to only where the grass overlay is, rather than the entire side face). If those pixels were removed from the non-tinted grass block underlay area, the issue would be fixed entirely.
Related issues
relates to
Attachments
Comments


and would largely mitigate this issue with grass blocks
It would be fixed if the non-overlay texture would have the grass parts deleted from the texture file then.

@Dhranios @Connor Steppie The fix you are suggesting (the one that would also fix MC-142156) cannot be applied without rewritting the whole rendering system, as there is currently no way of detecting pixels with alpha=0 while appliying another texture (literally you would need to add a way to insert two or more textures to the shader files, and then compare the alpha value between every one. There are also more ways of detecting 0 alpha pixels, but they are not perfomance-friendly)
It would be better to merge overlapping layers when building models on resource reload (so just one layer of the destroy texture is rendered) and cache them as baked faces at BakedModel.java on separate fields, and use them only when textures like "enchant_glint" and "destroy_progress" are being used. I made some tests yesterday and both MC-166101 and MC-265667 (this issue) seem to be fixed.

armor trims have a setting that only makes the trim pixels applied to pixels which exist at the main texture. It's not new functionality, but applied to a new area.

Interestingly enough, this issue was also present in Beta 1.5, but then got fixed in Beta 1.6

In 1.20.3

Can confirm in 1.20.4 Release Candidate 1

This appears to have been introduced in 14w06a or 14w06b (the former crashes when trying to break grass blocks). 14w05b is unaffected.
[media][media]
[media]
[media]