Semi-transparent model parts are rendered in the wrong order when viewed in third person or when held in first person.
From certain locations, semi-transparent blocks with multiple parts, notably plains, are rendered in the wrong order.
In the screenshot, the "plains" are on top, then the lower "block", then the upper "block", instead of the upper "block", the "plains", then the lower "block".
In the third screenshot, the upper block appears behind the lower block, it is location dependent though.
Steps to reproduce:
Apply a solid texture to the slime block, or use the provided debug pack
In hand
Hold a slime block in your hand
Notice the center cube is sticking out at you.
In third person
Hold the slime block in your hand
Notice countless errors in it's rendering
Edit in 14w30a: Fixed the incorrect rendering every sixteen blocks vertically, which causing the upper block to render behind the lower block.
Related issues
Attachments
Comments


What block is that ?

Slime block, but it also works with stained glass. I think it's always been happening, but since it was transparent, it was not noticed.

Here is a screenshot of the slime block by default, not how bright the one in the back is.

Please force a crash by pressing F3 + C for 10 seconds while in-game and attach the crash report ([minecraft/crash-reports/crash-<DATE>-client.txt|http://hopper.minecraft.net/help/finding-minecraft-data-folder]
) here.
Please attach your resource pack.

Resource pack with all affected

Crash report.
Something to note (just discovered), the issue with the blocks placed in the world only happens at y=80

I'd say your slimeblock.json model is buggy.
Happens too after switching off your resourcepack (the models won't be reloaded until restart, but that another issue)
slimeblock.json
{
"__comment": "Fair warning, this format is highly likely to change even more in the future!",
"name": "slimeblock",
"elements": [
{
"__comment": "upper body",
"type": "cube",
"from": [ 0, 12, 0 ],
"to": [ 16, 16, 16 ],
"shade": [ 0.5, 1.0, 0.8, 0.8, 0.6, 0.6 ],
"uv": [
[ 8, 0, 16, 8, "down" ],
[ 8, 0, 16, 8, "up" ],
[ 0, 0, 8, 2, "north" ],
[ 0, 0, 8, 2, "south" ],
[ 0, 0, 8, 2, "west" ],
[ 0, 0, 8, 2, "east" ]
],
"cull": [ false, false, false, false, false, false ]
},
{
"__comment": "lower body",
"type": "cube",
"from": [ 0, 0, 0 ],
"to": [ 16, 4, 16 ],
"shade": [ 0.5, 1.0, 0.8, 0.8, 0.6, 0.6 ],
"uv": [
[ 8, 8, 16, 16, "down" ],
[ 8, 8, 16, 16, "up" ],
[ 0, 6, 8, 8, "north" ],
[ 0, 6, 8, 8, "south" ],
[ 0, 6, 8, 8, "west" ],
[ 0, 6, 8, 8, "east" ]
],
"cull": [ false, false, false, false, false, false ]
},
{ "type": "plane",
"from": [ 0, 0, 8 ],
"to": [ 16, 16, 8 ],
"uv": [ 0, 8, 8, 16, "down" ],
"facing": "south",
"rotation": [ 0, 45, 0 ],
"cull": false
},
{ "type": "plane",
"from": [ 0, 0, 8 ],
"to": [ 16, 16, 8 ],
"uv": [ 0, 8, 8, 16, "down" ],
"facing": "north",
"rotation": [ 0, 45, 0 ],
"cull": false
},
{ "type": "plane",
"from": [ 8, 0, 0 ],
"to": [ 8, 16, 16 ],
"uv": [ 0, 8, 8, 16, "down" ],
"facing": "east",
"rotation": [ 0, 45, 0 ],
"cull": false
},
{ "type": "plane",
"from": [ 8, 0, 0 ],
"to": [ 8, 16, 16 ],
"uv": [ 0, 8, 8, 16, "down" ],
"facing": "west",
"rotation": [ 0, 45, 0 ],
"cull": false
}
]
}

The reason for the halfway points it a bit of a cheat to include more texture space

I don't think it's the model, here is the default slime block model with a solid texture.

Uploaded new version of the debug pack using just a solid texture. Bug still present.

Figured out the certain locations for transparent blocks rendering in the wrong order (the non-plains thing), vertical chunk borders, or every 16 blocks

The semi-transparent blocks no longer render oddly on vertical chunk borders, it seems the new chunk threading fixed that. The other two issues are still relevant though

It seems this is a duplicate of MC-44373, though that issue only lists two of the three issues (one of which is fixed as far as I can tell) and has note been updated since 1.8 release.

Resolved as Duplicate of MC-44373 (that one has more duplicates), but made you the reporter of that ticket.
Still there in 16w20a.

This issue has been resolved as a duplicate, so head over there for confirming it still exists.