MC-265667Grass 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
- 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.
Linked Issues
Normal
LowAttachments10
Created Issue:
Grass block cracking animation is darker on the sides
Relates to MC-166101.
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).
Attachments4
Relates to MC-166101.
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.
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
Relates to MC-166101.
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.
relates to
@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.
Relates to: MC-176095 MC-199660 MC-208679 MC-250985
May also relate to: MC-159560
The bug
The texture file grass_block_side.png contains several pixels which are completely impossible to see under normal circumstances. While their influence on gameplay is currently nothing more than how they affect mipmapping, their existence may pose a problem in future as is detailed in MC-265667, and it may be advisable to remove these pixels to avert this.
How to fix
Remove all of the green pixels from grass_block_side.png. A fixed version of the file is attached, which removes these pixels. Removing these pixels would also fix MC-262954.
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
Discovered while testing MC-269348. Relates to MC-166101, MC-262933, MC-265667 and MC-268537.
The bug
When the book on enchanting tables is doing a page flip animation, the block crack texture will appear twice as dark as it normally does.
How to reproduce
- Punch an enchanting table
- Observe
Expected results
Constant intensity for the cracks on the book.
Actual results
It changes when the pages move.
Relates to MC-265667 and MC-268537. Discovered while testing MC-276756.
The bug
The cracking animation for shulker boxes is more intense on the bottom half of each side of the block than the top half.
How to fix
It may be advisable to have shulker boxes in their closed state be a simple six-sided cube like most other blocks, with dedicated new side, top and bottom texture graphics.
@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.
