blank3times

My apologies, it’s a combination.

This is not a duplicate of MC-300108, it is a duplicate of MC-141075.

I disagree with this conclusion because the glow (and thus fully powered) part of the redstone torch has not changed; only the firey part which is not the redstone power itself. When the photo attached is in thumbnail form (zoomed out), the colours look quite similar overall.

I have been unable to reproduce this, but it may relate to or be an evolution of MC-299683

What dimension and biome were you in when this happened?

An easy fix if we could revisit would be to copy a working texture from the Bedrock Edition of the game which would work just fine if we want to call it parity.

Hello, would it be possible to reopen this one as its own standing ticket? The original post is not articulate at all on the issue, and I would be happy to help update the description with new evidence.

In the time after the resolution of this ticket, Mojang choices suggest that this special case is actually not a duplicate of MC-169889:

As has been pointed out, old textures not from immediately prior to the Texture Update have been added to Programmer Art (see crying obsidian). Similarly, leather horse armour has been in the Bedrock Edition since 2016. Old textures already exist there, ready “for restoring” (the definition provided in MC-169889). This sets it apart from the likes of MC-159632 despite similar wording on the tickets.

Furthermore, the recent fixes for MC-280047 and MC-280278 demonstrate that additions need not be drag-and-drop for inclusion in Programmer Art. In fact, the 1.21.5 cycle demonstrates an openness and willingness to put in effort, such as the re-creation of previously generated spawn egg textures—some of which never previously existed on their own.

Please consider rectifying the current erroneous resolution. I acknowledge that reopening does not in any way guarantee a fix (I’ve seen that before). But for the integrity of bookkeeping, we ought to set the story straight by giving this ticket the opportunity to stand on its own in the current context. Thank you!

I think now is a great time to fix this, given the model adaptations from the Spring to Life release and the fix for MC-280047 also making minor adjustments to ensure the model works properly.

I think now is a good time to do this, given the model adaptations from the Spring to Life release and MC-280047

Perhaps as a starting point for finding what's actually happening, it looks like somehow the clouds aren't being blocked by any eyes geometry so they render in front of the eyes?

Updated to account for MC-276988, which now removes the shading inconsistency. The mapping issue still stands.

Taking the advice from Dhranios and restructuring both this and the breeze one, since that part still stands as inconsistent. Would it be possible to reopen if done so? Or maybe, would this be better combined with the breeze equivalent?

Thank you turbo.

Thank you. I will silently follow the issue there for the chance that anything happens.

I concur with original poster's likely intent on revisiting this issue in light of MC-275296. The creation and resolution (fixed) of MC-275296 with the same issue on another parameter show a willingness to improve item rendering, two and a half years after the previous ticket was closed, which also because the developer who fixed it was brand new on the team at the closure of MC-248766, I believe constitute new circumstances for this bug. This bug went previously WAI and got revisited previously, so I would hope this ticket can once again either be considered a clone and updated with details from there, or perhaps in light of MC-275296 being fixed we could at the very least reopen the older ticket with an update on emissivity.

If it were to be moved back to MC-248766, how would one propose it be reopened?

As seen in the description, relates to MC-224159

This one is also special because I would tend to intend to edit both, and if I don't I suspect there would be some blockstate solution