A dragon head is invisible if the entity wearing it is not in view

Confirmed to affect minecarts and signs, as well, as of 13w04a.

Confirmed in 13w05a for item frames and minecarts. Can't reproduce with signs though.

Confirmed in 13w09c.

Can reproduce with item frames, paintings, minecarts, boats, items, projectile arrows, all the mobs except for bats, slimes(also magma cubes), squids, ender dragon, wither.

All named things are entities.

But some entities are drawn correctly when they are very edge of the screen...

Which ?
You can show the hitbox of the entities with F3 + B, maybe there is a dependancy of beeing seen and the size of the hitbox.

Sorry, I meant just entities' drawn appearance not hitbox.

still in 1.5.

Confirmed 1.5.1

Happens with ropes in 13w16a. It only matters if the end is in view.

I can confirm this as well in 1.5.1. It seems to happen to all the entities, so far I have tested: minecarts, boats and a few mobs. I think it is caused by an incorrect viewing frustum culling.

also happens with beds. have two players sleep right beside each other and they can't see their own legs or the other players'

Can confirm 1.6.2 prerelease

It's because the entity disappears for lag purposes. once the hitbox is out of view the entity won't render at all. Some entities have a smaller hitbox than they actually are. A good example is the item frame. I uploaded a screenshot in which you can see the hitbox. This is done using the NBTEdit mod.

Please don't change the behaviour of minecarts with blocks, because they're useful for mapmakers and decorations, you can have diagonal/moving blocks.

Yeah but now they disappear when you don't look at them. I don't want them to change the behaviour. Just so that they don't disappear when you don't look at them. Or even easier. Add a tag to an entity to determine wether they should disappear or not.

That would be perfect.

Better fix: make minecraft calculate how big is the entity (x-y-z) and make the "entity boundary box" that big as the enity.

that will probably change the way entities react. Minecarts will for example take off even though there's not a block next it

Yeah, I'd suggest having a visibility box as well as the boundary box, but doubling the number of boundaries each entity has to track might make them laggy. Perhaps it could be added only to the ones with different visible/mechanical boundaries, or defining each entity's visibility box by a single floating-point number as a scaling factor on the boundary box? I'm not conversant with the code and how it decides whether an object is visible or not, but I imagine there must be some way to resolve the issue without making the engine do a lot of extra work for each entity.

Is this still a concern in the latest Minecraft version 14w03b? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

confirmed for 14w03b

Confirmed in 14w05a as well.

Yeah, I'd suggest having a visibility box as well as the boundary box, but doubling the number of boundaries each entity has to track might make them laggy"

Instead of a new box to check if the entity is off-screen or not, I'd suggest that if entity's boundary box is off-screen more than 1 or 2 meters then make it invisible.

Happens to me in the latest snapshots for 1.8 as well (14w05, 14w06 etc).

I can also confirm its occurrence in snapshot 14w08a.

Partially fixed in 10c (not fixed for maps in item frames)

Confirmed for 14w11b

I noticed this when I used a command block to create a minecart with a block in it, except I made the offset big so the block was at least one block above the minecart.

Confirmed for 14w25b.

Confirmed for

• 14w29b

• 14w30c

• 14w31a
  with maps in item frames

Please fix this issue for blocks in minecarts, this issue has been in the game for a while :/

It seems this has been fixed slightly , it is better now.
In case of maps in item frames, they are rendered until they are nearly at the very end of the screen boarder.
But in this small area when they are supposed to be still visible, they aren't rendered anymore.

So but yeah, still a (minor) bug until 14w34c
It would be great if the entities really are visible until the very end, when they are in the FOV.
Also it would be nice if the display offset from minecarts could be regarded

Last I checked, this also affects players.

I can confirm it with armor stands.

Confirmed for 1.8. Attached screenshots showing this issue for minecarts, note that this not only affects minecarts with custom blocks and block offsets.

Fixed in 1.8.1-pre2 for:
Item Frames
Item Frames with Item
Regular Minecart

Not fixed for:
Armor Stands
Armor Stands with Armor
Item Frames with Map
Minecart with Chest, Hopper, etc.

Can still reproduce with regular minecarts, but definitely fixed for non-map item frames.

Confirmed for Villagers in 1.8.1pre2. My ticket about it ( MC-73470 ) was closed as a duplicate of this one, so I'm reporting it here.

Same thing happened to me just now with a double chest...? Can anyone else confirm?

Confirmed in 15w31b for Ender Crystals.

Added some screenshots from MC-88176

Affects boat paddles (15w47c)

Confirmed for 15w51b

Armor Stand with large block equipped example.

Confirmed for 1.8.9 and 15w51b. Here's a video demonstrating it.

Confirmed for 16w02a.

Same for e.g. (invisible) giants wearing a helmet, 2 pictures attached.

Same for blocks on ArmorStands, 2 pictures attached.

Confirmed for 16w03a

Confirmed for 16w04a, also for >>>SOME<<< normal living entities.
2 screenies of a MushroomCow attached, doesn't render when you go slightly higher (but where it should still be seen).

Edit: Only some entities it seems, MAYBE dependant on their hitboxes?
No time for testing atm, maybe someone else manages to do that before me - higher than Y=63 please.
See my comment here https://bugs.mojang.com/browse/MC-88176?focusedCommentId=282465&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-282465

Will attach the 2 Zombiepics in this bugpost (1058) as well.

@unknown: What you describe is MC-88176?

Confirmed for 16w05b

Confirmed fixed for mobs, thank you }=)
Sadly blocks at ArmorStands still render invisible, 2 screenshots attached.
Or is the rendering on ArmorStands another bugpost/issue?

@@unknown: Screenshots?

@unknown Yes I attached 2 about 30 minutes ago.
A column made with blocks attached in the headslot of ArmorStand - the block renders invisible depending on how you look at it.
The screenshot (incl. F3 on so you see it's this snapshot version) names are:
2016-02-10_18.29.36.png and 2016-02-10_18.29.40.png
Edit: It has nothing to do with "being at edge of screen by the way, the block rendering invisible-problem also happens if it's frontal of you and you look up or so.

Give me a couple of minutes, I need to test if it only affects Marker:true-AS generally, a head on an AS turned invisible with Marker:true, not so with marker:false - getting back to you in here asap

Attached screenshots 2016-02-10_19.17.55.png and 2016-02-10_19.17.59.png
I can confirm that blocks at ArmorStands with Marker:1b render invisible, depending how you look at them; not so blocks at ArmorStands with Marker:0b though.
This might be "works as intended though" or "won't fix" (people who are deeper into that topic than me will know that).

Used summon commands:

/summon ArmorStand ~ ~1 ~ {CustomName:"Marker = 0",CustomNameVisible:1,Marker:0b,Invisible:1,ArmorItems:[{},{},{},{id:lapis_block,Count:1}]}

/summon ArmorStand ~ ~1 ~ {CustomName:"Marker = 1",CustomNameVisible:1,Marker:1b,Invisible:1,ArmorItems:[{},{},{},{id:lapis_block,Count:1}]}

Sadly blocks at ArmorStands still got that insivible-render-issue if they are "stacked" on top of each other like in my column-example, no matter if I set their Marker-tag to true or false.

I got no idea why and if this is a completely different issue or new bugpost, and this bug here is really fixed - just ArmorStands being an issue.

I will try to figure out more about that ArmorStand-rendering issue with "stacked" blocks, but maybe someone more professional would know the answer, I hope someone will comment.

Attached screenshots 2016-02-10_19.43.01.png and 2016-02-10_19.43.08.png of a column/"stacked" ArmorStands with blocks in their headslot.
I set the ArmorStands to visible for better demonstration.
All ArmorStands here have the Marker-tag set to 0, but despite the successfully rendering of 1 single ArmorStand with a block in headslot, in a column those blocks still can render insivible.

Last edit I hope:
It seems to be MC-88176
As far as I figured out yet this rendering-issue with "stacked" blocks only seems to occur if I stand on Y=63.
It doesn't seem to happen when I stand at Y=62 or Y=65.

If that changes in any way, I'll just ask on the Mojira-Reddit }=)

So I guess this bugpost is fixed for real! Thank you 😸👍

LordAro, it doesn't happen with chests because chests are not entities.

Confirmed for chests in 16w06a. Here are two screenshots from slightly different angles:
https://www.dropbox.com/s/xdmie22tpy3981o/2016-02-14_00.13.54.png?dl=0
https://www.dropbox.com/s/lytrsh1wmaes3ca/2016-02-14_00.13.55.png?dl=0

@unknown Can't reproduce.
Could you please:

• Remove the texturepack and check again?

• Tell me your Y-coordinate where you're standing and that of your chest?

• Your FOV?

• Edit: If you can reproduce it with the texturepack turned off / default texturepack, then please make new screenshots, with F3 on, to see direction+angles as well

There are currently two bugposts I know which could explain such a behaviour in theory, but I can't reproduce it with either of both:

MC-88176
MC-96853

I will keep trying! 😸 It'd be important to be fixed in case it can be reproduced.

@unknown, @unknown: MC-95096.

@unknown Fun fact: I was there, modding Panda's stream that day, when he discovered that chest "disappearance" }xD
I wanted to make sure it's not the texturepack and that the chests are at a chunk border (hence I asked also for F3) 😸
But I didn't know there's already a bugpost for it, thank you very much!
@unknown I hope you don't mind that I'll attach your two screenshots into that bugpost to visualize/confirm it };]

Here are the screenshots: https://www.dropbox.com/s/163rn5i7ge00s51/2016-02-14_15.49.53.zip?dl=0
I always forget to turn off the ressource pack, even though it's nowhere near finished and everything is mixed between my textures and Faithful.
Yes, the chests are at chunk boarders, I like building my base at 0 0. There are four torches that mark the middle of the world, maybe they are visible in some screenshots.

@unknown Thanks, I already attached them on MC-95096 }=)
Don't worry, as Panda4994 showed it happening live it's confirmed };]
Thanks again! Have a nice day.

Confirmed not fixed for 1.9

@unknown Which entities cannot be seen on the edge of the screen?
Could you please specify the entity type?

With the player on the server. But it happened only once, so I can't attach the proof.

@unknown Thanks for getting back }=)
For entities it is definitely fixed, except some related issues like large block models or if it's at Y=63.
Haven't heard about a player-problem yet, but if it happens again and is reproducable, please do tell }=)

Confirmed for 1.9.

This happened to me while riding a horse: I could not see the horse when it was offscreen, but only when I am facing northwest.

Edit: This only happened when the horse being ridden collides with another horse (or any entity?)

Edit 2: After more testing, this seems to be caused by a bunch more factors, such as colliding with a wall(?) (Video)

I've got to work, so I can't really test it myself atm, and I'm contemplating whether or not the issue with the Horses - they being a really large entity - might be related (or the same?) problem with MC-96853 - "Large block models stop rendering prematurely on ArmorStands/Entities when leaving player's field of view. (e.g.: Dragon Head on ArmorStand)"

Or if there is another bugpost which is more fitting to what you describe.
Maybe the mods could be so kind to look into it sometime and add the according bugpost here, if it exists.

And if the mods say it is likely MC-96853 then I will add your info to my bugpost and change the title into what would fit both occurrences of the bug.

Suspecting chunk section borders in this case. More investigation needed, likely different from MC-1058 and MC-96853.

Affects Version 16w43a

Confirmed for 16w43a with marker armor stand wearing dragon head.

I got it with Villager.

Fixed 16w44a?

Still an issue with small armor stands wearing blocks on their heads.

Confirmed on 18w11a using a dragon head on an armour stand. Seems to be fixed for item frames though.

I'll look at all the stuff in the report soon™, check what's still affected, change the text, etc.

Affects 18w14a, using the aforementioned method.

Since it will take me longer than originally planned to go through the reports, I've now made a few changes to fit it to the currect state. I've just assumed that the responsible hitbox is the stand without the head, correct me if I'm wrong.

Affects 18w14b

Affects 18w15a

Affects Xbox One Better Together edition, running version 1.2.13.54

The Xbox codebase is separate; this project is for bugs affecting the PC version only.

Affects 18w16a

Affects 18w20a

Affects 18w20b

Affects 18w20c

Affects 1.12.2 Java

Affects bottoms of iron bars mainly that I remember. I'm sure there's more but can't think of them at the moment.

@unknown That's not even an entity. Can you please upload a screenshot of what you mean? If you mean the left or right side of the screen with wide FOV (no matter what block), then that is MC-92250.

Ah ok, thanks!

Affects 18w21a

Affects 18w21b

Affects 18w22a

Affects 18w22b

@unknown, ticket is yours now

Confirmed for 1.13.1.

Confirmed for 19w03c

Comfirmed for 19w04a

Confirmed for 19w04b

Confirmed for 19w06a

Confirmed for 19w11b

Confirmed for 19w12b

Confirmed for 19w13b

Confirmed for 1.14 pre-1

Confirmed for 1.14 pre-3

Confirmed for 1.14 pre-5

Confirmed for 1.14

This also seems to affect villagers laying in beds, see MC-149832

Confirmed for 1.14.1 pre-1

Confirmed for 1.14.1 pre-2

Confirmed for 1.14.1

Considerably trickier to reproduce in 19w44a