Animated part of sculk sensors's texture is incorrectly mirrored from behind
This is pretty hard to notice (way easier if you use a resource pack to remove the animation of sculk sensors), but the moving part of sculk sensors gets incorrectly mirrored from the other side
Linked Issues
relates to16
Created Issue:
Animated part of Sculk sensors's texture is incorrectly mirrored
This is pretty hard to notice (way easier if you use a resource pack to remove the animation of sculk sensors), but the moving part of sculk sensors gets incorrectly mirrored from the other side
Added Labels: sculk-sensor
Changed Summary:
Animated part of Sculk sensors's texture is incorrectly mirrored from behind
Added Category: Textures and models
Removed Category: (Unassigned)
Changed Summary:
Animated part ofSculk sensors's texture is incorrectly mirrored from behindAnimated part of sculk sensors's texture is incorrectly mirrored from behind
Added Linked Issues:
relates to
Added Labels: sculk_sensor
Removed Labels: sculk-sensor
Added Attachments:
Added Affects Versions: 20w51a
Added Attachments:
Added Affects Versions: 21w03a
Added Linked Issues:
relates to








Relates to
MC-206570Can somebody please attach a screenshot or video? I'm not sure I understand.
Cannot reproduce with the provided model to replace the tendril planes with debug2 - the mirroring is completely as expected and nothing is wrong at all.
sculk_sensor_active.json
Still able to reproduce, despite what commenter above says.
Have you tried using the provided resource pack?
I modified vanilla resource pack's files, and mirroring is incorrect
I still fully stand in my position of the sculk sensor's current mirror behaviour being the expected behaviour. Attached is a resource pack which replaces the textures of sculk tendrils, rails and ladders with debug2, and does not at all touch models. These are to be shown as examples of what mirroring behaviour is to be expected of flat planes within models. As the original creator of the vast majority of said tickets, the expected behaviour would be for a plane to render flipped on the rear side rather than having the exact same rotation, as having the exact same rotation usually results in paradoxical situations. (Models with intersecting planes, notably crosses, are a potential exception to this rule, but I've already clarified that in such tickets anyway, and I believe Mojang has been contacted for clarification on this matter.)
Case 1: An example of correct mirroring
An example of a correctly mirrored plane can be seen with vanilla's rails. Placing a rail atop a transparent block will reveal four clear quadrants with the debug2 texture. Note how, when seen from below, all of these sectors are in the exact same positions as they were when viewed from above, due to the texture being mirrored. This is an example of correct mirroring - having it be any other way would be clearly wrong and look weird with some textures.
Case 2: An example of incorrect mirroring
An incorrectly mirrored block in the vanilla resources is the ladder. Again, placing this on a transparent block will show the four quadrants, but going around the back will show the exact same texture but not mirrored, resulting in none of the quadrants being in the right position. This is an example of incorrect mirroring and is reported under
MC-199237.Case 3: The sculk sensor
Now we take a look at the sculk sensor texture. In the provided screenshots, a specific section is targeted on both sides of the same plane. As it turns out, the color remains the same at the same position on the plane, lining up with our example of "correct" mirroring, and this can be proven true of all four of the tendril elements. Therefore, the current sculk sensor mirroring behaviour is correct, and this report is Invalid.
As the tendrils are an animated texture, I can fully anticipate and understand that the mirroring behaviour here could have been misinterpreted (on several accounts, including even Mojang's). However, the fact still stands that the way it currently renders is correct, and that what this ticket reports as incorrect behaviour directly contradicts what is reported in all other such tickets in its vein.
Despite all of this, I'm still able to reproduce the issue. Is it possible that it is.. perhaps... graphic card specific?
Is this still an issue in snapshot 21w05a or later?
Can no longer reproduce the issue. Seems to have been fixed in between the snapshots
Please resolve the issue, as it is no longer present in the latest snapshot.