Some chunks are not rendered in first person from some angles in certain situations (incorrect frustum culling)

I can confirm!

Linked here from MC-63235 by an incorrect "duplicates" ruling. Anyone else have a mod just randomly say "must be the same thing" and mis-link them here?

Relinked "Edge of screen / FOV issues" to MC-63075

Under request of Dinnerbone, this issue has been separated. MC-63070 will be used to track the render issue with F5, while this issue will be used to track the render issue in first person.

Still affects latest snapshot (14w30c).

easiest to notice by going into spectator mode, then flying underground into solid rock.

the caves will be flashing in and out while you're down there.

Odd.. this appears to be fixed entirely for me in 14w30c.

Not fixed for me in 14w30c either. Screenshot attached "14w30c.png". Please re-open.

An observation: First off, it appears that this occurs most for me with a crafting bench. I can't replicate it with a furnace or chest or natural blocks (so far). It appears most often when the left side (my left) of the bench is at the point where it is both at the left side of my screen and has nearly vanished due to perspective - at the point where it is about to become a hidden surface.

This issue has definitely been fixed. You are seeing MC-129.

wouldn't it be consistently affecting the same chunks until you forced them to appear then?

in my case when i go underground in spectator mode it'll flicker. when i turn around big chunks of visible caves and other stuff will blink, appear or vanish.

The problem in the op is happening in 14w32a

Reopened

I think the title is missleading as it not only appears on the edge of screen.

14w33c

This looks like the right place to report what I am seeing, please assist if what I am reporting isn't exactly the same. I do think I am seeing chunks get culled when they are not supposed to be.

http://imgur.com/a/qCU5e

I report that this general location and orientation in my SSP world (seed 4462387242882506075 mined to and glassified an underground lava lake @ -181.5x 8y 144z)

This is on the border between chunks -12/0/8 and -12/0/9. When I step into the -12/0/8 side, eg x < -181.5, while facing anything north of northwest (>135 degrees orientation .. same issue facing to the right, anything north of northeast or < -135 orientation) all data south of position x >= -182 is no longer rendered even though much of it should still be visible on my screen. I am only using FOV = Normal @ 1920x1080 (bar exactly in the middle) although the effect is much more pronounced with high FOV and more hidden in low FOV (if I am careful I can leave just a touch of the effect visible @ FOV as narrow as 38)

When I F5 to behind-my-head, effect is tons more noticeable. If I do not move the mouse at all, then after pressing F5 to get into selfie-view, I just have stars behind me. Any touching of the mouse recalculates and erases that effect.

I tried finding other chunk borders to reproduce this with no luck, so the shape of the cave you are in might have an impact. I could offer my world file but this one is ~40MB so if there is interest I think I might first clean up the testcase a little bit.

Just encountered the same effect in a new room I am hollowing out, -216x 70y 192z. This time it is a chunk boundary (-14 4 11/12) on the z coordinate (Actually last report was also z coordinate, I was watching the wrong numbers change as you could tell by the chunk report :/ ) stepping between 191/192z. It happens when my view is between -45 and 45 towards south. Turning around and trying to reproduce the effect facing the other direction (stepping back and forth 191/192z facing north) I am not able to reproduce.

Be advised that in both instances I am facing into a fairly narrow, freshly dug room. To illustrate this, have the breathtaking view from my F5 behind-the-head: http://i.imgur.com/0ExoiK1.png

If it helps at all, I've walked back and forth and confirmed that the entirety of the segment of the room I am facing left visible by the culling bug (or at least the floor of it, though I suspect the whole shebang) does exist within the -14 4 12 chunk, with no traversable paths or avenues to other chunks.

To test this last hypothesis, I dug into a nearby wall and reproduced the effect until I poke a hole as far as -223x 70y 192z. Breaching the -223x step caused the effect to stop being reproducible for some reason, even though I am still in -14 4 12. Filling that hole back in brings the effect back, however.

Confirmed the issue I am reporting persists in 14w34b, and on a different computer (same SSP worldsave) no less: http://i.imgur.com/7yBbxoU.png

Thank you Grum, confirmed on 14w34c btw.

I whipped together a test case world in superflat:
3;minecraft:bedrock,100*minecraft:stone;2;

by following the meat of my hypothesis thus far and mining down in creative to y=84 (well between the y bounds of any vertical chunk) a few blocks north of the midpoint of a chunk boundary along the Z axis, and then mining forward (south, positive z) a 1x2 hallway through said chunk boundary by one step. This successfully created the enclosure that catalyzes overculling.

World save with player in position to view overculling here: https://docs.google.com/file/d/0B57wgZSp2XofSXc4V1BLc1c5aU0
Screenshots here: http://imgur.com/a/FpxfB

Best of luck, sir, and bear in mind that what I am reporting may not match the troubles that everybody else in this ticket is reporting, furthermore that it may also match lots of the troubles reported by folks in sister ticket MC-63070. My specific bug is viewable both in first and third person view, and my estimation of the meaning of the bugs is as follows:

MC-63020 - overculling so that from the camera's pov sometimes stuff you should be seeing gets culled
MC-63070 - improper assumption that you should always cull from character's head pov instead of tracking how the camera pov changes when F5 is pressed and culling from the camera. Furthermore, the fact that culling recalculates on mouse move (changed angle of view) but not on F5 press without mouse move (often time changed angle or vantage point of view).

Yes, happens in 1.8-pre too. Destroying single blocks sometimes causes 1 block X-Ray vision, happend to me with grass blocks a lot, maybe because I often use those to climb etc and then remove them..

I also had a weird X-Ray glitch when i was in a ravine and the end of it I could see the stars and landscape outside, when I got closer I noticed the ravine was solid wall.

Confirmed for 1.8pre2

Ooo, "attach files"? I only through the submitter could do that for some reason, which is why I was doing all the imgur links so far. :o

Lemme try this. ;3

yeah... the world generator is a little behind... especially if you go in one direction too fast. took a good 3 minutes for it to catch up hovering still.

Your issue Tom looks distinct from what others in this thread have been reporting on. Also I suspect that if you're in SSP your view distance is set rather high, and/or if you are in SMP your server view-distance may be set too high. Minecraft standard client memory allocation is 1GB but your debug screen clarifies that you are running at 83% used out of 2GB allocated.

What we are reporting on is overculling (the algorithm which decides which loaded surfaces to actually render onscreen omitting some surfaces which ought to be viewable, so you only see sky instead) but your screenshot demonstrates trouble with chunk loading keeping up to your avatar (all sides of all of the loaded chunks do render, showing dirt and stone faces below ground level), which is a different issue.

Perhaps issue MC-63020 could do with a bit better focusing? I think the issues should get focused into batches pertaining to some fairly precise and reproducible symptoms where possible, or we're stuck with folks thinking "what's on the screen and what should be there don't match" is just one huge issue. :3

Happ, I know. I've gotten the same results all the way up 4GB allocated. I've seen all sorts of manifestations of the invisible chunk issue. Going back over my cache of notes on rendering engines I think you're right and my issue is distinct from the one described here. My bad. If it was the same issue I wouldn't be able to see the sides of the blocks in the chunk.

confirmed pre3

With pre3 nearly all of my bugs went away with settings below 20 chunk rendering and 2gb allocated. I did remove everything other than the memory settings in the java settings as well. Still not perfect but almost all rendering issues and delays went away.

That's great news Tom, your symptoms did seem fairly distressing.

My unrelated symptoms of overculling issues which aren't related to chunk loading or memory allocation, and are easy to precisely reproduce, do remain.

Confirmed OSX

Adding a data point for reproducing:

Version 1.8
Ubuntu Linux 14.04
Seed -505506340

On day 1, I dug a tunnel into a rock wall at (67,79,303) for the night. I placed a cobblestone block at the lower half of the entrance to my tunnel. When I stood adjacent to the cobblestone and looked out (south) from my shelter everything rendered normally until I lowered my crosshair past the center line of the cobblestone block. At that point, a chunk directly in front of me dropped out of existence. The issue was easily repeatable by wiggling my crosshair up and down past the center of the cobblestone. Screenshots attached ahg1 and ahg2 demonstrate the issue.

Oh, Say Alan .. do you have a seed for your world so I could try to reproduce the same? 🙂

The seed is -505506340. I just recreated the world and reproduced the issue by running straight to the point I mentioned above, digging a 3-deep tunnel, and placing a block of dirt at the foot of the entrance. It's right next to an open-air lava outpouring.

Yep, confirmed. And the circumstances surrounding your vertical overculling behavior are quite curious, and show several differences from my horizontal example.

First fun thing to try: dig your hole in the cliff face exactly one block higher. Then you don't even need a waist high block in front of you, you can trigger the bug just by being in a 2x1 hole and looking far enough down to your feet. ;3

2. From where you stand to cause bug, dig sideways to the left as far as you like and as long as you can dig forward without moving your feet and reach open air, you'll still be able to reproduce the bug from this new horizontal position, too.

3. I've tried a few simple things editing the surrounding environment with no luck yet altering how the bug presents. I've tried stopping up the lava flow, filling in all of the caves to the left, digging a new cave in the field of view where the bug occurs, but I got fatigued because of constantly flying away from the important framing viewpoint to make decisions on what to change. If I could somehow leave one monitor with a player standing still and reproducing the bug in my RL view while I used another monitor and player to venture out into the depicted area to vandalize the landscape I could explore the limits of this effect somewhat more easily. :J

They said are sure there's no overculling...

First time I noticed this bug. Mining in Mineshaft. When it says I'm facing south, the chunk disappears. If I face east, it reappears.

Strangely, if I look up, the chunk renders, but when I look at it again, it disappears.

This is off-topic but what exactly is an "In Progress" issue? (Currently there are only 4 in this tracker, one (MCPE-4479) of which hasn't been updated since December).

There you see how hard some bug are to fix. @unknown is fixing since 20/Aug/14.

Ah, I see now. Thanks for explaining!

Can happen when shooting a bow. Go on a superflat world, pull back a bow, move your mouse a tiny bit, then release the bow without moving your mouse. Chunks at the edge of your FOV will not render.

Does this have something to do with lag? This happens very often to me even though I'm on fast graphics and use VBOs.

Yes I took a picture of this it has been happening to me since the 1.8.1pre 5 snapshot. it is a little more tolerable in the 1.8.1 release. The chunk that doesn't render properly will constantly flicker relatively fast. When I approach it just right it will stop and you can see through everything.

Confirmed 1.8.2-pre1

Issues on 1.8.2-pre1 Blocks not rendering on chunkborders

Look at the chunk coordinates where it says 0

in F5 mode it is very notable

I have a case in which this happens. I am uploading a .zip of my Minecraft Realms world. Download and open the world, and use /tp -71.7 74 -143.8 -43.5 18.9 to teleport your player to the sight where the bug occurs. You will see something similar to the screenshot I am uploading.

Details: If your y-rotation goes below -44.9, the chunks render and the glitch ceases. If your x-rotation goes below -41, the y-rotation range shrinks at an angle until the bug cannot be reproduced. The bug is happening in an underground room containing chests, signs, and torches, as well as andesite, granite, and diorite for the walls.

I hope these specifics will help Mojang fix this annoying bug!

Since my world is actually too large to upload, here is a dropbox link:

https://www.dropbox.com/s/y7u7d7t4fu9kqrx/Exhelah%27s%20Realm%20%28New%20World%29.zip?dl=0

MC-63020 confirmed 1.8.3

MC-63020 confirmed 15w31a

still happening in 15w31b
http://imgur.com/JK7pT19

Yes, I have the same issue too. I am using 1.8.8 with snapshot 15w31b.

https://lh3.googleusercontent.com/-yrTEnMuEowY/VbtOpQsdLuI/AAAAAAAAAOo/zAR1B2OiwP8/s1280-Ic42/2015-07-31_11.18.42.jpg

confirming it still happens in 15w35e

Some of your pictures simply show the chunk loading. You are standing on the line between two chunks and so the one you are basically not looking at is invisible. If you turn, it appears. This occurs with high FOV, because the game doesn't detect that you actually see that part.

That is exactly the bug. If any part of a chunk section should be onscreen, the section should be rendered. However, this is certainly not the case. It happens in fact regardless of the FOV setting.

I ment that high FOV does exactly what it does. And that causes the game to not recognize those areas. This bug excists for very long already

Just seen this problem in 15w37a, worked out I was at a chunk border. Have loaded an image. My FOV is default, fast graphics, etc.

Still present in 15w40b

Confirmed for 15w42a

Confirmed for 15w43b and 15w43c

Confirmed for 15w44a

Mods: may I be set to reporter on this ticket too, so that I can keep affected versions up2date? 🙂

I got it covered. Thanks for the offer tho.

I think

and

should be deleted or moved to MC-63070.

I have found that this bug can occur in 3rd person mode too. It is different from MC-63070 in that it does not go away upon moving the mouse.

Confirmed 15w44b

Confirmed for 15w45a

just had this in 15w45a too, mostly noticable in tight caves with high FOV

Confirmed for 15w47a (and 15w47c)

Confirmed 15w49a

Confirmed 15w50a

Confirmed 15w51b

Confirmed 16w02a

Confirmed 16w03a

Confirmed 16w04a

Confirmed 16w05a

Confirmed for 16w05b

Confirmed 16w06a

Confirmed 16w07a

Confirmed 1.9pre1

Confirmed for 1.9-pre2

Same :3

Confirmed 1.9-pre3

I think this is the same issue or one very similar; sometimes specific blocks don't render unless you're really close to them.

yes, that's the same issue

Confirmed 1.9-pre4

Confirmed 1.9

Confirmed 1.9.1-pre1

In 1.9, I have found that exiting the world, and then reloading it can sometimes fix the problem. Sometimes the problem is small and sometimes it is major. I recently had a time where a huge central portion of chunks would never render, and the chunks that wouldn't render would rotate with my position around the center.

I attempted refreshing the render of the chunks, changing video settings, etc, but nothing worked except closing out of the world and loading it back up. From what I can find it doesn't look like a rendering issue so much as it is a chunk loading issue. When the chunks are loaded into the cache, they must be corrupted by something that causes them to act up when being rendered or causes them to not be able to render at all.

Another (maybe) possible clue: When I am looking at a non-rendering chunk, my central pointer still activates the box outlining the blocks in the chunk, however, when I looked at the position of the outlining box, it was misaligned with the visible blocks. Either all the blocks that I was looking at were equally positioned tall grass, or the entire chunk was attempting to render in a misaligned position. If the latter, that could cause huge problems. If the position of a chunk is loaded as being different then where it should render, then that would cause chunks to cease rendering at incorrect times, such as when the chunk isn't entirely out of view (though it is calculated to be because its loaded position is incorrect). I think it is unlikely, but it may be possible. I'll observe closer and experiment more the next time it happens.

Hello, Steven.

It is possible that you've discovered either a different bug, or a different variant of the bug than I have been reproducing. In my variant of the bug it would be impossible for chunks under the crosshair (in first or third person views at least) to ever become culled.

Can you find a way to reproduce the issue you are seeing? The major portion of the issue we have been chasing can be reproduced by the method in the discription of this bug, and also by the method in the description of bug MC-63070 (which is not the same bug, but a bug that this bug helps to enhance the visibility of).

Or, if you start a brand new minecraft world do you see your copy of the bug at all? Or if you play minecraft from a different machine? I want to be certain your copy of the bug does not rely upon a certain specific save or a certain specific client environment.

Thank you, Steven! 😃

Confirmed 1.9.1-pre2

Confirmed 1.9.1-pre3

I found a bug almost exactly similar to this, the only difference being that no matter how far I go or how close I get to the missing chunk, it won't render. This problem happens for me with VBOs turned on and off, by the way.
EDIT
Adding on to that, whenever I press Escape and then un-pause the game, the chunk renders but now a different chunk is missing. Same issues from original post.

Confirmed 1.9.1 + 1.9.2

CAN CONFIRM FOR 1.9:
https://www.youtube.com/watch?v=c9J1GjtYntE

@unknown 1.9 is outdated

Confirmed 16w14a

Confirmed 16w15a

Confirmed 16w15b

Confirmed 1.9.3-pre1

Confirmed 1.9.3-pre2

Confirmed 1.9.3-pre3

Confirmed Minecraft 1.9.3 + 1.9.4

@unknown that's MC-90602.

Confirmed 16w20a

Confirmed 16w21a

Confirmed 1.10-pre1

Changed reporter to @unknown.

Reminder of why this bug would be good to fix, out of all of the ancient bugs:

It's sufficiently visually distracting to see parts of the world disappear that it even mars the videos of popular youtubers
It can frighten players to see sudden changes to large areas of the screen in the periphery of their vision. Making use of that form of jumpscare on purpose is fine — such as the specter of the elder guardian — but in cases like this it has no connection to the story narrative and does not train players to interact with the game in any sense.

I just learned (and confirmed) something interesting.

The client-side mod Optifine (at the very least OptiFine 1.11 HD U B1) not only absolutely fixes this bug, but also it's cousin MC-63070 to boot.

I have not yet tested older versions of Optiifine to see how long it's been fixed there, but I was lead to try this out due to a new chunk loading / culling finding that I've made.

Vanilla minecraft as of 1.11 makes some very very strange decisions about which nearby chunks in clear line of site it will keep unloaded for no well determined reasons. After trying out the latest optifine I noticed that while this problem may not be 100% solved, the odd choices are at least pushed quite a lot farther away from the camera.

On the other hand, I found places where vanilla MC 1.11 renders the landscape correctly, but OptiFine instead ignores a chunk (or even several) while rendering, depending on the camera position and viewing angle. If interested, I have a saved world available.
__

P.S.: Discussed this issue briefly in the OptiFine bug tracker, where sp614x provided an additional test world with a very obvious case, where both vanilla MC and OptiFine consider chunks accidently as not visible (don't move, just turn).

MediaFire shared folder with 7-zip packed world "InvisibleChunk" and a preview how it looks for me right after loading this world. In addition, "FlatCreative" world from the OptiFine tracker.

Hey, could this be because of going from a high render distance to a low one? Because I just experienced something bizarre. I usually stay in 8 render distance but I was having some lag so I lowered my render distance to 5 and for a few minutes everything seemed great until I slowly flew over to another side of what I was building and I noticed that the chunks right next to me were not loading. I looked over to other places and I noticed more of them. I went closer and they still failed to load. I went inside them and I fell to the ground for a moment, so it was there but then everything around me disappeared and then I turned the distance to 10 and everything came back. It was bizarre. If it happened again I will post a picture.

I was going to make a report because I thought it might be a different issue. I was in first person the whole time.

@ Tiya tehJak:

No, this is a different issue. If you can approach them and fall through the world, they were not loaded. But this report is about chunks which are only considered not visible although they should be, and they are loaded, as they are visible from a location or just in a different angle, and usually at least one chunk away from the camera.

Confirmed for 1.12 official.

Why is this "postponed?"

Postponed means it will be fixed later.

Affect 1.12.1

Affects 1.12.2-pre1, 1.12.2-pre2, 1.12.2, 17w43a, 17w43b.

This has been an issue for over 3 years. Is this actually postponed or is it just going to be "Will not fix?"
I'm sure it's been mentioned before, but this affects every single player. They can all see the same glitches. I've had one in my servers spawn and in many players' bases. I know there are a lot of old bugs, so I would like to ask if this is actively being worked on or if it's just been forgotten about for now?
Thank you

"Postponed" means that this is a known issue that they'd like to fix, but currently isn't actively being worked on due to e.g. significant other changes being required. So, that means that it's not forgotten but also not actively in progress.

Thank you for the clarification!

Still affects 1.13-pre6

Confirmed for 1.13.1.

confirms 19w02a, 

those disapears causes only visual effect by culling, at point 'C: 1/7056'

please do not add there bug where chunks stops to loads.

What does "C: 1/7056" mean?

it's doesn't mean anything but that chunk render is 1 of 7056

btw this bugs happens only at chunk edges, you can seen it more often as you set fov for 120~ or more

This bug affects 1.14.4.

confirmed, 1.14.3 to 1.14.4

my issue covers snapshot 19w34a
confirmed

i'm notice that that's happens when you look east (Towards pisitive X) at the moment when facing changes, it's back to normal.

I can detail the precise cause of this in 1.12.2 using MCP 9.42. I don't know how relevant this will be with the current Blaze3D work, but for anyone else looking...

In RenderGlobal.setupTerrain there is this line:

Set<EnumFacing> set1 = this.getVisibleFacings(blockpos1);

This creates an ad-hoc VisGraph to find all adjacent subchunks visible from the view position. In the situation described by this bug it will only find 1. Later, this happens:

if (set1.size() == 1)
{
    Vector3f vector3f = this.getViewVector(viewEntity, partialTicks);
    EnumFacing enumfacing = EnumFacing.getFacingFromVector(vector3f.x, vector3f.y, vector3f.z).getOpposite();
    set1.remove(enumfacing);
}

This removes any subchunks found in the previous call that are opposite the cardinal direction (or more precisely the 6 possible directions for EnumFacing) that the viewer is facing.

One scenario would be only the eastern side of the subchunk is open and the player is facing a heading of 45.1 degrees. Technically, the players cardinal direction is west. The visible subchunk to the east is removed from the set.

This causes the game to determine that the only visible subchunk is the one that the viewer is standing in, and it skips everything else to only render it.

The adjacent subchunk frustum checks later in this function are probably sufficient, and this attempt at optimization could be entirely eliminated. However, it would be more appropriate to perform frustum clipping checks here than than this naive cardinal direction check. 

Obviously, it affects 19w44a, since it's not fixed yet. But I still thought I'd say.

Is this issue still happening in 1.15 Pre-Release 1?

Yes

still in 1.15

Confirmed 1.15 and 1.15.1

I noticed this issue frequently on my game at the max FOV level. I took a look at the duplicates, and it looks like this glitch has been here for as long as FOV has been adjustable. Sorry if this was an obnoxious amount of screenshots and it is definitely still in 1.15.1

Confirmed 1.15.2

Please do not attach any more screenshots to this ticket, we already have enough.

Yay, I wonder if that's a sign that someone is now tackling the issue. 🙂

If they are, I'd recommend keeping in mind how this issue relates with MC-63070 (same problem except when camera position and player's head don't coincide) and with Field of View.

The algorithm to decide which faces to cull as "out of view" ought to take FOV into account on one hand, and the position of the camera instead of the position of the center of the player's head on the other.

In circumstances where re-calculating what gets culled is expensive enough that potential wild swings of the camera become problematic, one could alternately calculate what ought to be culled from the entire filled sphere centered on the player's head with a radius of the camera's maximal distance from that point.

</armchair-quarterback-advice>

MC-63070 is already linked, there is already quite a lot of Mojang activity on this report (see the "all" tab). Please restrict comments to useful new information about the report.

To reduce the amount of duplicate tickets, the technical term for this issue is frustrum culling. (Searching that phrase did not feature this ticket in the list).

In 20w10a

In 20w16a

We've taken this issue to specifically describe a bug regarding chunk "frustum culling" - that is the removal of chunks that are behind the player's viewable area - as the title and details for this issue specifically describe frustum culling with the 45 degree angle point being rather key.

Many of the bugs marked "duplicate" are not actually related to the fixed frustum culling issue, but are a separate issue regarding "occlusion culling" - that is the removal of chunks that are behind other chunks (not necessarily behind the player's viewable area).

MC-63021 will be re-opened and used as the issue tracking for "occlusion culling", which has not yet been fixed.

Good to see this finally fixed. This hasn't worked right since the day it was introduced.

The ticket about incorrect occlusion culling is now MC-70850.