mojira.dev
MC-265667

Grass block cracking animation is darker on the sides

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

  1. 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

Attachments

Comments

migrated
[media][media][media][media][media][media][media][media][media][media]
migrated

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.

ISRosillo14

@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.

migrated

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.

ISRosillo14

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

pulpetti

In 1.20.3

migrated

Can confirm in 1.20.4 Release Candidate 1

muzikbike

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]

muzikbike

(Unassigned)

Confirmed

Textures and models

1.20.2, 23w40a, 1.20.3, 1.20.4 Release Candidate 1, 24w09a

Retrieved