The Bug:
The inner cube faces of slime blocks darken when solid blocks are present nearby.
This issue can more easily be seen when smooth lighting is disabled but still occurs regardless.
Steps to Reproduce:
Place down a slime block.
Place down a solid block directly adjacent to the slime block.
Look closely at the inner cube texture of the slime block.
Take note as to whether or not the inner cube faces of slime blocks darken when solid blocks are present nearby.
Observed Behavior:
The inner cube faces are darkened.
Expected Behavior:
The inner cube faces would not be darkened.
Related issues
is duplicated by
Attachments
Comments


Is this a bug ?

Just a check here, are you actually doing
"cull":"false"
?
Because that would be incorrect.
"false" is a boolean value not a string, and thus does not need to be in quotations, and should be written as:
"cull":false
So, I'm assuming invalid as that's your issue. I tried "cull":false in 14w11b and it worked just fine for me with glass. Also, I don't think leaves would be possible if this didn't work, unless that was hard-coded to be turned off.

No, these are the default models. And it only affects certain few blocks. Several of my models which worked before now have darkened spots, so either the format changed and they missed some models, or the "cull" tag is broken, either way it's a bug.
And yeah, I mean "cull":false, I typed it here from memory (I usually copy/paste for making my models)
Kumsasa: Yes, if you notice, the top face is darkened, even though you still see it. That is why "cull": false was added, to stop that, and why it not doing it's job is a bug.

Darker faces doesn't always equate to culled faces. I believe that's still ambient occlusion or just lighting in general making things darker than they likely should. Mog tried to fix it, and in some cases he did, but it's not completely fixed.
For instance, in 14w11b, iron bars seem to be fixed completely with smooth lighting, but doors seem to be a little not as dark, but the top still is darker than it should be if a block is above.

Here is a screenshot of slightly modified of the default files.
The one on the right has ""useAmbientOcclusion": true"
The one on the left has ""cull": true"
Note with or without cull the bug still happens, and useAmbientOcclusion does not fix the problem.

Also note that only certain blocks are affected, notice the anvil looks fine, but not the end portal frame, and I used the same process to make both.
Try it yourself with the end portal frame, or the slime block (or some other I have not found)

Okay, using Spectator mode, I've found it is not cull, it just visually looks identical to the cull darkening.

And I found what those two blocks have in common, they are both solid blocks that are rendered as transparent.

still in 18a

I've noticed (17a/18a) that my custom trapdoor model has a darkened face (different element on each, but the same place) for the east/west open placements if there is a block to the north. These are the ONLY variants it occurs for, and culling is not enabled anywhere. It's like it's rotating the block, but forgot to change the shading values just on that element.
Possibly related/interesting: looking in spectator mode, the non-Y-rotated version has all covered faces blacked out accordingly, while the others only black out a few faces.

Confirmed for 14w19a.

Confirmed for 14w26c

Fixed in 14w29a Nevermind, only fixed when using night vision...

I would say this relates to MC-51447

Still a concern in 1.8.2 pre 2

Fixed on end portal frames in 15w46a, along with stairs it seems. Slime blocks are still affected.

Confirmed for 1.13.1 (fixed End Portal Frames).
Is this still an issue in 19w41a?
Since this issue has reappeared in 1.19 Pre-release 3, would it be okay if I can request ownership of this ticket and update it accordingly to include the necessary details? This ticket also relates to MC-249087.
Thanks greatly for the ownership transfer. 😃
I've updated this ticket to purely mention how this issue affects slime blocks as it was previously stating that end portal frames were also affected under certain circumstances, but this no longer occurs. Furthermore, I've removed the "Environment" field of this report as this issue isn't exclusive to Windows 7 and I'm leaving a comment here stating my actions and reasons just for documentation purposes.

Confirmed in 1.21.3