Chunks not loading surface, revealing caves, etc.

A workaround is resetting your rendering distance.

The rendering distance is definitely a workaround. However closest chunks to the player should be loaded and processed first. At the moment it seems to be random with no priority on distance from the player allowing visibility underground at long distances. This could be used as a cheat on multiplayer servers.

F3+A (reload chunks) fixes it without having to cycle through render distances.

The F3 thing doesn't work for me.

The F3A thing worked, thanks!

I'd like to echo that I would consider this one of the worst flaws of Minecraft. Chunk errors have been around for a long time in various forms. Dinnerbone did some work to make it better in 1.3, but they still occur frequently. I think everyone has gotten used to them at this point, and yes there are workarounds, but it's still super annoying.

Actually, there is a difference between this and what Dinnerbone fixed.

World Holes occur on servers in 1.2.5 and earlier. They are chunks that have no blocks on the client side. You can jump in, but the server won't let you fall. Relogging fixes.

What we see here is a rendering problem, and it usually fixes when you approach the chunk.

I think Ezekiel is right. But that is certainly annoying as well.

Yeah. If you load up a 1.7 Beta world, chunks load as far as you can see in all directions, it actually works.

This seems to happen very often for me in the Nether. I don't see it very often in the normal world.

There's a workaround in the server/client that should fix "chunk holes" . Hopefully they find a better fix than just to reload the missing chunk since it's very obvious when you see it happen.

Slow chunkloading in general might be becuase of various reasons. I know for a fact someone kind of had the problem you describe but it was working for everyone else on the server, in that case I think it was some weird connection issue.

Its not a chunk issue, however it is per client. If you press F3+A to force a chunk refresh it will work. I know its not a connection issue because it occurs in a localhost as well

Ok, well the original description matched what I've seen. Yet again, I only play Minecraft in multiplayer so I can't say how it behaves locally. But since Minecraft now uses an internal server for singleplay you might get the same chunk/render weirdness that's been in SMP for a long time.

I have the same problem both in SSP and SMP. I have tried various settings. I think it is better with shorter viewing distance but still occurs quite often.

I have been running 1.4.2 directly from RAM and still have this issue. It's not a hardware latency issue. Chunks that I'mabout to walk onto will load at the last moment, but I often see no chunk until then.

I'm playing only in singleplayer mode, and I'm having the problem mostly when moving by boat. When I walk, the rendering seems to be ok (although chunks are loaded more slowly then before version 1.4). But the higher speed with the boat seems to confuse the order in which chunks are rendered. So sometimes distant areas are already visible, while close chunk surfaces get only visible just before I move on them.

it happens to me mostly when i switch fast between running and walking. i do this often when i build things like seen on the attached file (yes, there is a big hole behind the not displayed chunks). it also occurs when i move by mincart and turn around (looking in different directions in short time) or tavel by boat. the far away chunks are displayed before near ones, still there can be seen mobs moving on them. it occurs in all game modi (haven't tested adventure, but all other, even multiplayer) and is infakt client side, as mentioned from other.

if you get in a range of about 3-10 blocks near the not displayed chunk, it gets displayed. if you don't move and reload the chungs or reset the view distance, it will be loaded correctly.

The issue MC-2216 that I created is for the same problem related here.

+1 Ealrann Xor: Sometime the chunk terrain will be displayed (almost) upon entrance. This makes orientation extremely hard. Imagine a lava pit inside that chunk...

I know, this has been happening to me ever since 1.3.1. I have no idea why, because 1.2.5 never gave me any graphical issues or random lag.

Like I said earlier, could be because Minecraft 1.3 introduced an internal server, that's why some of you haven't seen this error before but it's been in multiplayer for a long time.
Still, it needs to be looked at, perhaps some chunk loading/rendering optimization can be done here.

really annoying. it destroys the gameplay feeling I love so much. happens to me mostly when I start playing and load an existing map in SSP

The first picture is in a Singleplayer game.
The 2. -4. picture is froman Server map with the minecraft_server.jar
The Chunk bugs are very big and its on every map that i had start

Two screenshots in my mine from almost the same position. I can reproduce both views repeatedly by moving one tile forwards/backwards. So the chunk appears/disappears depending on my position

It seems to me this bug could be an issue in the code that considers which chunk is 'visible'/suitable for rendering

EDIT: this is reproduceable on SMP even after quiting and reopening the world. I have a savegame if someone is interested

Hiram: Do you happen to have Advanced OpenGL (in video settings) turned on, and does the problem go away if you turn it off?

confirmed... TY.

Tavis: Yes and yes. And if i turn it on again it reappears.

Hiram: That is a fundamentally different bug. This report describes a problem that never reverts itself once corrected (at least until you leave the area), and is not affected by the Advanced OpenGL setting. You may want to report your bug separately and hope the mods don't decide it's a duplicate of this. 😉

When you experience this problem in the future, could you turn the debug screen on while taking screenshots? I'm curious about what kind of framerate you're getting when this occurs. It would probably be a good idea to include the pie chart (Shift + F3) for potential future reference as well.

Tavis: See MC-3998 for screenshots with debug. Apart from the visual change nothing else is affected: It is instant without hiccups or slowness

Hiram: I was actually referring to further experiences with this bug.

I was able to reproduce this by waiting for all the chunks to load around me, looking in a cardinal direction, moving backwards and forwards a couple of blocks for a while, and then turning and flying perpendicular to the direction I was looking. Using the overworld superflat preset may help you see what is going on.

Minecraft isn't able to download/read the map from a server fast enought, because there are to much players,thi might happen f your random access memory (ram) or your internet connection is slow.
Overall, Minecraft doesn't have enought RAM/VRAM/Connection speed

Because without fusion of SP and MP there will be no Mod API 🙂

And what's that?
I didn't find nothing new when they added that LAN server,all i got is lag and some more lag

It is official mod support. You'll be able to just drag and drop mods.
And adding features will be much easier for the mojang team.
Anyway, this discussion does not belong here 😉

This is an extremly annoying bug. I have it myself, whenever i change render distance half the world is gone. On multiplayer servers it can be fixed by placing something down on it (atleast it worked for me) like fire, cake ect.

Confirmed as of 13w02a

since 1.4.6 and on this bug occurs much lesser to me. in fakt, if a chunk is not loaded it will be loaded after all other chunks are loaded... maybe this only happens for me, but liked to share it with you guys.

The new Renderer has not been implemented yet, as far as I know.

Portions of it have, but the project has not been completed yet. One specifically noticeable part is the new texture loading system. I suspect we'll continue to get bits and pieces of it in coming snapshots. An unfortunate side effect is that this specific bug has lower priority because anything done to fix it will be rewritten anyway.
Confirmation that they are still working on it: https://twitter.com/Dinnerbone/status/294410000665821186

I haven't had this problem for about 5 official versions. It does happen occasionally in 13w04a for me, but they fix themselves immediately and are not too much of a problem.

@VasilBochev: This isn't a problem with rendering; it is a problem with client/server communications. The new rendering system will not remove this problem or make it obsolete.

@Brandon Slade

It is my understanding that this is due to the OpenGL pipeline data not being constructed yet. The actual data structures for the chunk are loaded, but the game has not yet created and cached the appropriate vertex data for the chunk.

This data is constructed client-side, as part of the renderer.

it also appears the issue has varying degrees based on the "performance" option. "Balanced" seems to mitigate it somewhat.

Minecraft limits the number of render updates per frame.
This bug occurs frequently in youtube videos, and it seems toggling the recording "fixes" the problem nearly instantly (as reported by the youtuber). In general, professional youtubers have machines that can get upwards of hundreds of frames per second. When recording, Fraps limits them to 30 fps.
By stopping the recording, Minecraft can increase it's framerate and render all the chunks within view distance, and then re-render the chunks that were not rendered properly.

I have personally seen chunks rendering behind the unrendered chunks through the hole that they left exposed. If it was server lag the closer chunks would render first, and the sides of the chunks that the client did have would be rendered. The client doesn't render the sides of chunks next to these holes because there is data there.

@Tavis: The framerate FRAPS records at is variable. 60, 50, and 30 are built-in options, with a custom option as well.

Yep, but the "V-Sync: On" setting in the video settings in Minecraft does a similar thing. Limits the framerate to your monitor's refresh rate.

This setting is on by default.

I find I get the invisible sections of land far more often with V-Sync On than when it is off. In fact I rarely get invisible sections of land at all when it is off.

From experience (I'm not really a programmer) it's my opinion that the issue is certainly something related to anything that limits the framerate, whether it is the built in v-sync option or an external program like Fraps. Of course correlation does not imply causation so this is just my speculation.

I found a good way to trigger this glitch is to idle for a couple of minutes in the same spot and once all the chunks closeby load, then proceed to walk in one direction where I'm 95% certain you will see a line of missing chunks. Oh and have VSync On.

In the 13w07a snapshot, chunks still don't display properly. Please update the "Affects Version/s:" tag.

Updated Affected Version

To reproduce:

1. Set render distance to far
2. Look straight in one direction
3. Turn on the debug screen
4. Wait until framerate increases dramatically, chunk updates decrease dramatically, and/or E: ##### (at the end of the second line) stops changing
5. Turn around and start walking or teleport outside of render distance in the direction you were not looking
6. Notice holes in the world that stay until everything else on your screen has rendered

Notes:
It may be easier to see the location of the problem on a flat world.
If the above does not work in singleplayer, you may need to artificially limit your framerate. I don't think changing "Performance" to "Power Saver" will work, so use something like fraps, another GPU intensive game, and/or set "Performance" to "Max FPS"
If you are playing on a server that has the view distance set to 13+ you will not experience this problem.
Below view distance 13 the problem seems to be inversely proportional to the view distance, because the client is recieving fewer new chunks outside the render distance to distract it.
You may have this problem with a shorter render distance if the server has a shorter view distance.
If you look at a corner of the world, the hole will begin to render once everything else you can see is rendered. If you immediately look at another part of the world that has not rendered yet the hole will stop rendering.

Hypothesis:
The client is trying to render chunks that it has not recieved from the server. If the player is not looking in that direction, they will be marked as not in the frustum (http://en.wikipedia.org/wiki/Viewing_frustum). For some reason it stays that way until the game has a chance to render chunks that are not in the frustum or the player gets close enough to force it to render.

Here's a patch that fixes the problem. Works with MCP 7.34 (13w05b).

--- old/minecraft/net/minecraft/src/WorldRenderer.java	2013-02-21 12:19:37.668954895 -0700
+++ src/minecraft/net/minecraft/src/WorldRenderer.java	2013-02-21 12:36:12.384921752 -0700
@@ -315,5 +315,8 @@
     public void markDirty()
     {
         this.needsUpdate = true;
+
+        for(int i = 0; i < 2; i++) {
+            this.skipRenderPass[i] = false;
+        }
     }
 }

"2" is probably a constant.

Edit: Other areas in the code use a for loop.

The problem still occurs in 1.5.

In addition to the patch provided, it would be ideal to sync client render distance with server view distance, and increase the single player server view distance to 13 when render distance is set to far.

Started getting worse with one of the latest snapshots. Also confirmed for 1.5.1-pre

Still a problem in 1.5.1 pre-release.

It affected beta 1.8.1 as seen at 3:42 in season 2 episode 1 of VintageBeef's Mindcrack LP, but I don't remember it happening at all in beta 1.7 and earlier.

I started seeing this in 1.3.1, possibly due to a major change that "Made Singleplayer internally use a Multiplayer server".
The "ssp" mod link I posted above re enables single-player mode and resolves this issue, but I don't think it is compatible with 1.5 yet. You can always roll Minecraft back to 1.4.7 and use the mod there.

Do you have Advanced Open GL on? Try turning it off.

Hm, I just tested with it off, and my superflat redstone test world, which normally shows this issue while first loading, instead seems to be loading everything in the proper order.

Didn't help me. Not in SP, at least.

Confirmed in 1.5.1 official.

Even though it has become more rare, I can most commonly find it in a superflat world.

@Aotr It's not.

Still happens with smooth lighting turned off.

You can reliably reproduce this bug by reloading chunks (F3+A), facing in one direction until the F: and E: values in the second line on the debug screen stop changing, and then turning around and walking/running/flying in the direction you were not facing.

As a few have commented, I believe the rendering problem was due to AdvancedOpenGL (mine was on without me knowing). Turning it off will fixed the rendering problem.

I believe AdvancedOpenGL is a "fast" rendering option for those with performance issues.

AdvancedOpenGL only renders blocks (or in general: all visible things) that the player can actually see and is a general performance thing that should be used by default (almost all modern games use AdvancedOpenGL or a similar technique).

The reason why it’s disabled by default and toggleable by the user is that it’s poorly implemented and causes trouble for some users – but has nothing to do with this issue. This issue only makes the result of using AdvancedOpenGL visible.

I can find this bug in superflat worlds such as the one I play often. How I find it is by flying more than 20 blocks high, and go in the direction of an unloaded chunk while still flying.

I've always had this problem and presumed my PC wasn't powerful enough.

Was playing SMP in 1.6.1/1.6.2, happens all the time. Anyone update the "affects versions" ... ?

Still in 1.6.1 and 2, best noticeable when riding a horse or travelling by boat / minecart.
It can be pretty dangerous to ride a horse into invisible chunks.

I have found a rough fix, switching the render distance from Far to Normal makes this almost completely go away (in Normal it only happens for small square chunks for a split second and is barely noticeable, in Far it happens all the time!)

Before the mapping was changed to the multiplayer mode this only used to happen a few times in single player and never really bothered me, but since the change to the multiplayer map format this happens ALL THE TIME and is really annoying! It completely spoils the experience IMO. I've noticed that it renders the blocks around where you first load the map, but as soon as you start to explore further it just never stops happening, it's constant! Version is Mac 1.6.2. This is definitely not a system issue, I'm running a 2008 Pro Mac with 4gb ram and an ATI Radeon HD5770! Also, when I notice this and press F3 my system is only using 25% allocated memory (it's only allocated a gig of ram as well!) What spoils it the most is you can easily pinpoint the location of caves, and although I've not seen one yet I expect to see a Stronghold, which just ruins things for me as Strongholds aren't supposed to be easy to locate.

I agree. It may be because minecraft has to keep an eye out for every player, and has to keep up accordingly. This happens almost guaranteed with large maps with lots of people. I think that it has trouble keeping up, but not causing lag, its just in the coding. As the versions became more feature ridden, the original design for servers just cant keep up. The only way to fix this is to have a different way of rendering chunks on large servers or to have then pre-loaded. This would take a long time to craft, but may be the only way to fix it. If this way were to be added, there might be a waiting period before going on to affected maps

Can someone please remove the duplicate pictures? There are many of them and it is clogging the page.

I'm noticing this mainly in single player though.

in Normal it only happens for small square chunks for a split second and is barely noticeable

Sounds like you have "Advanced OpenGL" turned on. See MC-3998.

It may be because minecraft has to keep an eye out for every player, and has to keep up accordingly.

Nope. It's a client side issue. By default, the server doesn't send enough chunks to "fill" far render distance but the client goes ahead and renders the empty chunks anyway. The client prioritizes rendering chunks the player can see but it doesn't re-check empty chunks until they get re-rendered, so the ones the player was looking at when they got rendered will render fine (unless you have Advanced OpenGL on - this is unrelated to MC-3998), but the ones you weren't looking at at the time they were rendered don't get re-rendered until everything else you can see gets rendered.

You can work around this if you have a server by setting the view distance higher (about 12 or 13 I think), but unfortunately I don't think there's a way to change it in singleplayer. Alternatively, as mentioned above, setting Render Distance to normal works fine.
Note that this only applies to "chunk errors" you can see through. If you can see the sides of chunks it's an issue with the client never actually getting the data in the first place.

Here is some info that may help developers diagnose this problem:

Using the Windows 1.6.2 client in multiplayer, I have noticed that looking forward (in the direction you are traveling) causes chunks ahead of the player to get drawn very late, to the point where the player is almost in the chunk itself. However, if the player looks directly down for a few seconds, then when he looks forward again, the chunks ahead of the player – out to a distance of several chunks – will be visible.

This is very repeatable on the server I play on. The effect is even more dramatic when traveling by boat because of the greater speed. It is necessary to look down every few seconds to make the chunks far enough ahead of the boat visible so that you can avoid hitting something.

The fact that the chunks ahead of the player can be made visible by something the player does (looking down) seems to indicate a problem with how the client uses the player's looking direction to determine which chunks become visible.

I've seen this many times, of course there has to be some order in which the chunks are chosen to be rendered, but It sorta seems like the priorities aren't properly chosen.

This bug seems to be quite common in 13w36a. Same with 13w36b.

A good workaround for me, as mentioned above a few times, is to turn VSync off and to set Performance to Balanced. As for the graphical glitches, where chunks are not rendered at certain distances/angles (not a chunk loading problem), turning Advanced OpenGL off is a workaround. Of course, these are only workarounds and not a fixes... I am finding the problem much more obvious in 13w36a and 13w36b, and although that might be partially because I usually have OptiFine installed, which is obviously not compatible with the snapshots, I don't remember it being quite this bad in vanilla.

Edit: Fixed typos

This is much worse on Snapshot 13w36a and 13w36b! In 1.6.2 it doesn't happen at all when you set the render distance to Normal, but now it happens when you set the render distance to Normal as well (tried with both regular biomes and amplified and the issue is the same... I initially thought it was just an issue with Amplified worlds, but it's exactly the same on regular biomes too). This problem has gotten much worse and is in serious need of being fixed IMO as it really does spoil the experience for me.

Saying that I've not tried any of the work-around's mentioned above (I've got Advanced Open GL On, Vsync On and Max FPS for the performance - on a side note is Advanced Open GL really necessary as it seems to cause more problems and doesn't seem to make a difference visually whether on or off).

@Damian Lee
I believe Advanced OpenGL is there to try to optimize performance by using some advanced OpenGL techniques, so apart from when it isn't implemented properly (by drivers or software such as games) it shouldn't make much difference at all visually. At least that's my understanding of it! 🙂

Confirmed for 13w37a !

Confirmed for 13w37b (still very common) and 1.6.3 !

I have not played 1.6 a lot, but in 13w37b this seems to be AWFULLY common compared to 1.5. It doesn't seem to be network related at all, but happens as frequently in single player. It is practically impossible for me to see a whole landscape because there are holes everywhere until I go to the first block that doesn't display. Then it suddenly display that "chunk" and quickly loads the sorrounding ones.

My render distance is set to far, but that was fine for me in 1.5, where I rarely experienced this problem. My hardware has not changed since and I am still running Java 7, 64-bit.

Guys, while we wait for this issue to be resolved, I recommend you use (fn on a mac)+F3+A to reload the chunks.

Thanks for that key command Mod Ezekiel, I knew about it but couldn't remember it.

As for a current work around, as suggested by Christopher Wassall above is to turn V Sync Off, Performance to Balanced and turn Off Advanced Open GL. This even works for me with the render distance set to Far, so the experience is now nicely unbroken by glitches 🙂 I can't really see any difference between these setting being On or Off TBH.

As far as I recall I think this issue started happening once the single player game started using the multiplayer map format, or something like that. AFAIK this has always happened in multiplayer, from what I can gather from other people that is (I've never played in multiplayer though, so I don't personally know).

As a side, now I've limited this bug with a work around the Amplified world type looks even more impressive now!

I don't think this ever happened before beta 1.8.

In 13w37b and above some chunks don't load at all even if you step onto them, unlike in most cases they render if you get closer.

Still quite common in 13w39a !

Ok, it is being a looong time of this one... so I decided to take action too. Consider it my gift to the community. I believe I have a fix for and it does not harm performance significantly (or ironically even seems to improve it ?!?). I will do code references to Forge documentation (class, method, property names, etc).

Though the original cause behind the bug is something I have not checked, I tend to believe / confirm that it is not having the chunk data when trying to render it. As a result, the affected chunks (WorldRenderer instances) inside updateRenderer keep skipRenderPass as true as they did not manage to render anything. The problem comes later, when there are two places that check those skips through the skipAllRenderPasses method. One is when clipping the view to set what is inFrustum (RenderGlobal.clipRenderersByFrustum), and another one is to set anything skipping render passes to inFrustum false automatically in RenderGlobal.sortAndRender. So, even though the blocks data is finally there, it will not get updated again because it is not inFrustum (it thinks it is not in the screen!) while it is skipping rendering passes ending up in the chicken and egg problem. On the other hand, the chunks have the needUpdate set to true, which can be used to our advantage and force an earlier render.

So the best way I have found at the moment after a bit of trial/error, and the one that does not seem to hit performance as all the previous I tried, seems to be to enhance the WorldRenderer.skipAllRenderPasses method to make sure it only returns true if both skipRenderPass are true AND this.needsUpdate is FALSE. So just "&& !this.needsUpdate" in the right place, and this issue is probably gone forever 🙂. Converting to real Minecraft sources should be trivial, and the fix cannot be easier to apply.

Note that the original repro from Tavis Hansen does not repro any longer after this. Actually... looking back now, why wasn't Tavis' fix applied? It seems also consistent with my findings -if not even better?...

Mojang, Jeb, would you mind giving any of them a try? I would love to see this gone for good.

(Linux, 64-bit: java version "1.7.0_40", OpenJDK Runtime Environment (IcedTea 2.4.2) (Slackware), OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode)

I only had a problem with this one since 13w43a. I found that turning off VSync fixed it. I can keep Advanced OpenGL on (earlier in the thread it was recommended to turn off vsync and advanced OpenGL.)

This has become a major issue in the recent updates and in 1.7.1. This is one of those bugs that really undermines my desire to explore the new biomes. If I do I am constantly jamming F3A to reset the loading. Also the new horizon lighting is ruined when you can see straight through the chunk to empty space. Please fix this!

@thefoot
This has been an issue for quite a while. You can use this mod to fix Single Player:
http://www.minecraftforum.net/topic/534818-152-olddaysnbxlite-spawnhuman-ssp-sspc/
(Very first post, "Daily builds" section, "SSP") It's working 100% perfectly for me in 1.6.2 - I haven't upgraded yet to avoid the hassle of re-installing the mod, but the guy who makes it is usually pretty good with keeping it up-to-date.
When you install it correctly, you'll see a "Play SMP" button on the "Select World" page. DON'T press it - start the game normally.

I'm not sure what effect this mod has on Multi-Player.

I have started having this issue with 1.7.2. Seems odd that I didn't have problems until this update.

Hey, for those having this problem in 1.7.2, I had this problem in 1.7.x pretty bad. As noted earlier in this thread, the bug was happening only when I had both Advanced OpenGL and VSync turned on. If either or both were off, chunks loaded normally.

Game went from nigh-unplayable to quite lovely. I should note I had no issues with the same settings on 1.6.4 or earlier.

That may contribute to it, but I have both of those off and experience some issues (though again not worse than 1.6). I think there is still an underlying issue.

Thanks, Tobyn 🙂
At least now we have a workaround for this very annoying chunk loading problem.
It was spoiling the game to have to do F3A regularly while exploring.

And, like Ezekiel says, it doesn't eliminate the problem.
But, it does make it more tolerable.

@Travis
I tried your little patch and its works fine as far as I can tell, is there something preventing that fix from being viable? If not why doesn't mojang fix it.

Thanks for the quick fix, I was going nuts with the slow loading 😛

f3 + a seems to fix this too

Biggest rendering error I've ever encountered, This is in the new 13w49a snapshot.

Holes in the landscape are caused by slow chunk updates, as reported in the debug screen.

1.7.2 suffers from slow chunk updates. After watching http://www.youtube.com/watch?v=yc565Rqt3lY and experimenting, it is clear that the Max FPS slider alone is directly linked to chunk updates.

If your Max FPS slider is set high - even if your client is totally incapable of reaching that FPS - your chunk updates will be crippled. The lower your max FPS slider, the better the chunk rate - even if you are not actually capping your FPS.

So the workaround is: set your Max FPS as low as you can tolerate.

@Aaron Bell. Confirmed. I played around with the FPS slider and found that the world had far fewer world holes at 10 FPS than Unlimited. Also the world loads much faster on low framerate settings.

Well... to summarize a bit so far for newcomers, and in the hope of getting news from Mojang:

To reduce the effect (roughly):

• Advanced Open GL -> Off

• Reduce Max FPS

• F3+A (works for some)

• Reduce the render distance

• VSync Off

To remove it completely:

• Apply Tavis Hansen's fix or mine (needs MCP, recompiling, etc). Included in the comments.

• In the future it may hopefully be fixed in the official product (Mojang's decision hopefully based on the community as well)

Why fix it: Still relevant and popular

— "really annoying. it destroys the gameplay feeling I love so much." (Tom Mate)
— "This is an extremly annoying bug." (Leon Ericsson)
— "This bug occurs frequently in youtube videos" (Tavis Hansen)
— "This has become a major issue in the recent updates and in 1.7.1." (thefoot)
— "This is one of those bugs that really undermines my desire to explore the new biomes." (thefoot)
— "Biggest rendering error I've ever encountered" (Daniel Whitney)

Ask to MOJANG:

The community has fixed this bug already for previous versions. The fixes are really short, even 1-line fix.

We kindly ask you to apply any of the proposed fixes. We are willing to accept feedback to improve them if that were to be the case. We cannot upload the fix to the official branch ourselves, we would if we could. Thanks for your understanding.

Voted for this issue. It's simply annoying, and worthy of an Alpha version of a game.

Changing the framerate slider from Unlimited to 10 fps does nothing for chunk loading/rendering in 14w17a.
(So therefore I believe that https://bugs.mojang.com/browse/MC-129?focusedCommentId=123516&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-123516 is false)

In fact, in 14w17a, most holes will never render no matter how long you sit and wait. The only solution is to walk/fly close (very close) to the holes.

Here is a demonstration: http://imgur.com/a/yVVON
Note that for all the images with holes, the game was clearly not attempting to fill them in. The images with everything filled in are immediately after reloading the chunks using F3+A.

Render distance was only 5 chunks, and note that I could get ridiculously close to some of the holes before they were filled in (for example that small hole in the swampland).

Hi Jonathan. In my tests I noted that the Max FPS slider directly impacted the chunk updates number. This seems a good measurable metric.

In your screenshot I see chunk updates=8, which is low. Could you do a test to see if that number changes when you set your Max FPS slider at different places?

Attached 2 screenshots. 2014-04-24_13.42.20.png and 2014-04-24_13.43.06.png

The first was set at Unlimited max framerate (83 fps, 1 chunk update), the second was set at 10 fps max framerate (10 fps, 0 chunk updates).
On neither setting did the chunk updates ever go above 10 consistently. When I first opened the world, it was up around 50 or something for a few seconds and also while I was flying around a bit. I stopped when I found a hole that was abandoned, and then the chunk updates settled down low.

While I do not have the code for the snapshot, in MCP for 1.7.2 the code fix seems to be still ready to be applied there...

The fix at the time was adding the "&& !this.needsUpdate". Worth a try?

WorldRenderer.java

public boolean skipAllRenderPasses()
{
    return !this.isInitialized ? false : (this.skipRenderPass[0] && this.skipRenderPass[1] 
                                       && !this.needsUpdate);    // This second line is the fix!
}

Versions Affected: 14w17a & 14w18a

I attached a short video of a demonstration of how this occurs even without moving (took forever to find a good export under 10MB). Just start up a brand new world, and it will fail to render certain chunks. Using F3+A rerenders everything fine. (on a funny note, the world in the video spawned a suffocating horse)

Keep an eye on the chunk updates. They settle down very low and the holes are still ignored and not filled in. I highly doubt those holes would ever get filled if I never moved.

I did a lot of experimentation with my MacBook Air (Intel HD 4000), and I can't get this issue to appear at all, on 1.7.9 or 14w17a. The iMac (ATI Radeon HD 4670 256 MB) and the MacBook that I'm using were both running Java 8u5.

Hi Jonathan,

I just tried 14w17b, and chunk updates do seem dramatically slower than in stable 1.7.9: unloaded chunks everywhere no matter where I put the FPS slider.

Jonathan maybe you could try on 1.7.9 to compare results.

On the stable version 1.7.9 on my 8-core desktop:

• Cap at 60 FPS or lower = chunk updates go as high as 850 ⚠️

• Unlimited FPS = chunk updates are much lower, ranging 30-60 and never above 60.
  Hence the idea that capping your FPS has a real effect on chunk updates.

You're identifying a phenomenon that is not necessarily related to the real problem of chunk abandonment by the renderer.

Yes, framerate caps do affect chunk updates. However, I don't believe that chunk updates are the same thing as the 1-time-only event of loading-then-rendering a chunk. Every time you open a world, the chunk updates are automatically going to skyrocket. If you just sit still and do nothing for a while, they will inevitably settle down lower.

Personally, since I don't have access or knowledge of the code (other than the snippets of apparent fixes posted here), I'd much rather get some more information from the actual developers. Yet for some reason there is no assignee to this issue.

After some testing, it is true that 1.7.9 is ridiculously more stable than 14w18a. Abandoned chunks do not occur at all in 1.7.9 under normal circumstances on my 3.06 GHz Intel Core 2 Duo, 8 GB 1067 MHz DDR3, ATI Radeon HD 4670 256 MB, running OS X 10.9.2. I can however force some abandoned chunks by teleporting far away and flying a bit. EVEN THEN, if I mess with the camera and fly around a bit more, I can trigger the holes to be filled in without getting the minimum distance to them. This is impossible in 14w18a. The game will completely ignore the abandoned holes unless you approach the minimum distance to force a refill.

As I stated, my system with I believe a 2 GHz Intel Core i7, 8 GB of faster memory, and Intel HD 4000, has zero holes on both 1.7.9 and 14w18a.

Attaching 2014-05-02_12.04.19.png to show that 1.7.9 does in fact have this issue, albeit in a slightly different form. Isolated holes don't show up, but I can replicate the abandonment of chunks on the edge of the horizon. I waited for a while until chunk updates fell to around zero to five. I believe the render distance in this case was 10 chunks. You can see the cutout near the horizon that should be filled in, but it never was. In this case, the "minimum distance" that it takes to force a load of the edge chunks is very high (if I flew forward a little bit it would quickly load itself), not the tiny distance of the standard hole phenomenon. Nevertheless this is not supposed to happen.

14w19a. The below is on the ATI Radeon HD 4670 w/ 256 MB and 8 GB 1067 MHz DDR3 (6GB for the JVM).
Attached 3 screenshots to show that Max fps has nothing to do with this. I was using /kill repeatedly on a newly created creative world. MASSIVE amounts of chunks were completely forgotten even after respawning multiple times. I would immediately fly above the minimum refresh threshold and almost immediately the chunk updates dropped to zero (in both Unlimited and 30 fps max).

Jonathan,

Just wanted to let you know some things I have found out from comments Mods had left on other bugs. Firstly (rightly or wrongly) Mojang don't follow corporate style IT support systems. I know, a decent dose of ITIL might work wonders for them, but it's not happening today. Where you would normally expect a ticket to be picked up by someone as soon as it was verified, Mojang tend to lurk until they are ready to actually fix it, at which point it's assigned and fixed. It's a small team, so ambiguity of ownership of issues may not hurt them that much in terms of efficiency, however...

This is not support ticket best practice.
This gives the false impression that the bug is effectively dormant and not being taken into account by Mojang.
This generates community ire because it fails to manage user expectations in any useful way.

Mojang's community engagement level is very weird. They are hugely active on Twitter and Reddit (neither of which are mediums I have time to engage with, having a real job and more than enough on-line communities in my life already), but their own, internal, communication channels languish with a dearth of information and very brief announcements regarding to feature changes and bug handling.

This bug has 387 votes (at the time of writing) and should get addressed, so I wouldn't panic. If it's taking a long time to get assigned it's likely that Mojang just aren't sure how to fix it yet, or have other priorities right now (Realms is likely to be their focus for some time as there appears to be a lot of money at stake, right or wrong as that may be). I would assume that as a 1.8 release approaches they will stop making new feature changes and actually start to address some bugs. Of course, as we have NO actual data regarding the internal release engineering process within Mojang, nor a detailed release roadmap, this is all complete speculation, but a guy can dream.

@Christopher Martin

Please be aware that the Mods are community volunteers chosen by Mojang to handle the routine maintenance of tickets, we are not employees or in any official capacity. Having said that, if you look at even a few of Dinnerbone's tweets (or other Mojangsters'), you will see a LOT of re-factoring (i.e. redesigning the interior of the game) is going on, much of which is required before some tickets are resolved. I.e. tickets related to mobs clipping out of areas is related to their hit boxes and may, or may not (we mods cannot say), be related to code around those hit boxes. There is a SIGNIFICANT amount of code dating back to Alpha or "the old days" that must be re-worked for some things to be finally fixed, so please be patient with the developers. In other cases, such as performance, re-factoring may help things work in a more optimal or "clean" way, but as the game becomes more complex, performance on older systems, may, and most likely will degrade.

fienxjox,

I am aware that the Mods are volunteers, and I am not making comment about them. Mods are likely doing the best they can with little or no guidance, given the lack of appropriate community engagement Mojang displays in other areas.

Your comment makes my point very well. Jonathan assumed that an unassigned ticket was dormant: this is a safe assumption as that is what it means in a normal support ticket environment. Is there a FAQ that answers questions about Mojang's support process that outlines this difference? No, another user has to pass on the information that they themselves learned through side-channels. And instead of you recognising that the system had failed, you instead came to the defence of the mods, when I hadn't actually said anything about the mods other than what I had seen them post on other tickets.

I don't watch twitter, as I said in my post. As this is the official channel (the Mojang website and bug tracker) by which Mojang (the corporate entity I purchased my game from) expects me to manage my bugs and interactions with them I don't see why they shouldn't do the same, or at least give equal time and effort to.

Yes I am aware that Mojang is making major changes. My comment was how I acquired this information: rumour, community discussion and short, detail-poor release comments from Mojang. There are plenty of community, open source software projects run far more professionally than this. Check out FreeBSD's release engineering process, and it's not $35 a copy, it's free. It's not a dinky little Java game, it's a full operating system. I don't expect it to be that good, but half that good? That'd be nice. A quarter as good? It's a start.

I am not saying I don't want issues fixed. In fact, that's what I want: Mojang to focus bedding down the internal re-engineering and keep its focus there. There have been many, many new features in the 14w snapshots. How about letting it be for a while so we can actually get the new API out so the community has a stable base to work from? I think the majority of users would prefer 1.8 sooner with just the re-factoring and API done than it later with slime blocks and new minecart physics.

I've understood for a while that Twitter (and Reddit) are favored over this dedicated channel. I also understand that poor solicitation and communication is not a unique feature of Mojang. Take a look at the Spotify community forums and you'll find another company incapable of effective user interaction.

My main reason for being here is purely documentary. I'm just going to keep dumping info regardless of how it's handled.

In any case, my personal opinion on bug reporting is that they should only be solicited as strongly as you are willing to deal with them. And we all know that Mojang STRONGLY solicits user reporting. It was my intention to stay on the stable releases. I got roped into the snapshot releases precisely because Mojang has made such a public showing of them. And what am I to do now but troll this site and add any and all info I have on a particular issue?

Jonathan,

I hear your pain. And, yes, I understand that poor support is not unique. Updating with new information is not 'trolling' and I find myself in a similar position on other issues.

I guess we'll wait and see how things evolve, and keep posting new data when we can.

14w20a.

I used the word trolling with the fishing activity in mind specifically. Then I realized that even that definition is not what I meant to convey. So just never mind that little comment :S

I attached another screenshot just to show how you can see this from underneath bedrock as well. Further, the blocks can be fully interacted with, broken, placed, etc. without actually showing up visually (as shown by the cube outline on one of the bedrock blocks).

I have been experiencing this myself and had wonderd as i got a better Comp system which increased the performance of my Graphics card, so i increased my max FPS.

14w21b, I'm joining the club.
Definitely an issue of computer performance - a PC with SSD is much less prone to this bug, but a flying or riding player still eventually outruns world loading.

As someone mentioned, a showstopper 😞

this was happen to me to in 1.7.4 and 1.7.9 ! 38 fps... but i saw a chunk loading ...... IT NEEDS TO BE FIX ! even in my multiplayer i got a super chunk loading !!!

Snapshot 14w25a!!!
It just got real. The problem is now much worse than ever, chunks don't load almost at all beyond the initial sweep, and what's worse, they don't even load by proximity anymore.
Proof of didn't happen: http://www.twitch.tv/orcjmr/b/539657493
Win7 64, i5-2500K @3.3MHz x4, 8 GB RAM.

I do hope it gets so bad that it gets noticed, and once noticed, one of the fine folks at Mojang won't just settle with rolling back an offending change, but rewrites the thing for good.

EDIT: Oh, right, the most important spec: WD Caviar Green HDD.
I came to work and tested against an SSD - it works flawlessly. Previously I was able to eventually catch up to chunk loading front and get it to glitch - well, not anymore. Loading is smooth and orderly even on AMPLIFIED worlds. Well, I guess I'm down some $100.

This is actually better for me in 14w25a than 1.7.9 (MacBook Air mid 2012)
I have not tested this with my iMac (late 2009), which is the one that has the most issues with this.

Anton Morozov: does your computer have a HDD or SSD?

Yup, the game is unplayable on my iMac.

Im getting this badly now i have to reload the chunk after a certain distance after the inital sweep so i can c what the landscape is

OP or mod, 14w25b to the affected versions list, please.

I can't believe this issue has not been resolved yet. I have exactly same problem like other ppl in these comments (AND screenshots AND videos)...

Different HW configurations, SAME problem:
-tested CPUs: old/low end AMD Athlon X2 4000+; mainstream AMD Phenom II X4 965BE, mobile intel Core i5 3320M, hi-end intel Core i7 4790K
-tested GPUs: nVidia 8800 GTS (G92), nVidia GTX 285, nVidia GTX 680, integrated i5 3320M GPU (HD 4000), integrated i7 4790K GPU (HD 4600)
-tested storage devices: SSD Samsung 120GB 840 Pro, various Seagate Barracuda 3.5" 7200rpm drives, Seagate Momentus 2.5" 5400rpm, HGST Travelstar Z7K500 2.5" 7200rpm (drives connected via different SATA II/III controllers - intel Z97, nForce 750a SLI (eSATA), JMB363 and others...)
-tested memory configurations: 4GB DDR2 800MHz, 12GB DDR3 1600MHz, 16GB DDR3 1833MHz (VM memory configs: non-customized, preallocated 1GB, 2GB, 4GB for VM and many other configs)
-various OS environments tested: Windows XP SP3 32bit, Windows 7 Pro 32bit, Windows 7 Pro 64bit
-different verisons of JRE and/or JDK tested
-different versions of chipset/GPU drivers tested (also various performance settings, PCIe power saving profiles, swapfile enabled/disabled etc. tested)
-all 3rd party tools and programs like FRAPS, EVGA Precision, nVidia Shadow Play etc. disabled.

Problem is present on ALL these HW/SW configurations.

Various MC versions from range v1.4.1 - 14w25b tested and all these versions are affected by this problem (sooner or later). Bug might be present since v1.3.1 (SP/MP merge) -not verified.

This was one of the reasons why i left MC... still not fixed? Oh well...

None of the chunks are loading for me in the 1.8 snapshots. :/

That's MC-56897

Thanks, Kumasasa!
The problem for me was in the Advanced OpenGL setting (wasn't it the reason it was removed from options in the first place?). Despite the option being removed, the setting itself was preserved in the config file. Setting "advancedOpengl:false" in options.txt solved all my woes, even for large rendering distances. On to ocean monuments on Hardcore!!

@@unknown: I've put your comment in MC-56897

Thankyou Anton .. this issue had been really annoying since latest snapshot an your trick has solved it big time 😃

Try changing your render distance - it worked for me! However, it may still happen later.
By the way, this is in 14w26c.

Yes, there are some sweet spots with the render distances, but none of them actually solve the problem. It WILL reappear.

If you move it down to 2 chunks then it doesn't show up, but you can't see anything to begin with…

Usually after a while, Minecraft undergoes an intense amount of lag (<1 fps) while trying to load all the chunks, but fails.

Yes, I have the same settings, just change the pieces and yet lost

Is it just me, or is this much improved under 14w27b?

The issue has been very significant on realms. I purchased a realm and the rendering has lacked large sections nearly everywhere. I have run into mountains or walls that weren't there until I hit them. Outside of that, I cannot see much distance as everything is broken in to random chunks on the horizon. It is discouraging. The problem doesn't seem to exist on single player.

Most probably you've described MC-56897.

For me it has been significantly improved in 14w29b. For some reason it now only appears at the very first spawn in a newly created world where you can look thru the ground which reveals caves, etc.

press F3+A. This has beea serious problem the last few snapshots without change.

In 14w29b with VBOs on, with OS X 10.9.4, Java 8u11, ATI Radeon HD 4670, HDD (not SSD), this issue is SIGNIFICANTLY improved. It's almost impossible to see this problem, though it does happen occasionally. The minimum distance before a chunk is forced to render is MUCH higher. Also, I can only get my computer (with the HDD even) to cause this issue on very high render distances.

And as an aside, as far as I can tell, MC-56897 has been eliminated for me on the above setup.

I can confirm more or less the same in Windows (high end PC). Snapshot 14w29b seems to have practically removed this bug as it can load the chunks more than fast enough to cover for the situations in which they were lost in the past due to not keeping up when generating/loading them.

One curious thing though, it works great with 60 fps or Unlimited ⚠️ , but other settings like 90, 120 fps and so on do affect quite a bit the chunk loading. But, as 60 fps feels great already... to me this bug is no longer an issue 🙂. This version is now as speedy as good old 1.2.5!! I look forward to 1.8 and the next MCP/Forge. Thanks team!

Since 14w29b the effect has kind of reversed.

Before, once the block was loaded and visible everything worked just fine.

Now changes to the nearby environment (placing a torch, breaking a block) are subject to delay. Sometimes it's just a split second (annoying when placing a torch takes time to illuminate the cave), sometimes the are quasi permanent: I can break a couple of blocks above my head and then jump into the new space gaining clipping errors like being in "spectator" mode. I need to place another torch then.

I guess that's what Mojang meant by bending time around space instead of space around time.

Holger, that's MC-62166.

This might be fixed with 14w30a, we will see if that happens

Confirmed for 14w30a and 14w30b shows for a split second or two.

This ticket got superseeded by MC-63020

This is NOT same issue as MC-63020. The occurrence of this problem does not depend on viewing angle. Please, reopen this ticket.

I suspect that as the snapshots settle down, these bugs will all evaporate. We'll see.

I agree. This is NOT the same as it does not happen only in edge of screen / FOV.

In 14w30c the bug is especially obvious in my system when pushing the chunk distance very far. The rendering system is initially missing some chunks during the first render, which it finally corrects after it finishes with all the rest. The problem is that, if there are plenty left to render, it can be very noticeable and for some time. On the other hand, with lower render distances it is not that visible as it finishes the first rendering fast and then it corrects them. This is a half fix of the original issue, which I think it is still there. Those chunks should not be skipped and should be prioritized in the first rendering.

This is not a nice way of taking out of the way one of the top 3 issues (top 1 for a long time). But, at least the rendering improvements are definitely making this less painful.

There is a lot of story behind this bug which should not be ignored, including suggested code fixes which were never neither contested nor applied.

Great news! I think this is finally fixed in 14w31a! I have been flying around, with no random chunks missing. Anyone to confirm?

There is a separate bug also in previous snapshots related to changing rendering distances or just choosing one too far (28-32) that the game and computer cannot keep up with, and being able to fly beyond the edge of the world, but again, this is a separate bug much less important in my opinion and should not be confused with this one. 1.8 is definitely looking great!

It's been a long wait, but better late than never 🙂. Thanks Mojang!

I can confirm it.
I suffered from this since it was reported. It's finally gone in 14w31a, I can play Minecraft again!

This is as fixed as it's going to get.

I don't mind marking this as fixed, but the change from 30-31 was less than 29-30. Again, these kinds of tickets are very anecdotal and oftentimes can manifest themselves with specific settings and machines. I'd rather see (hear) Mojang do firsthand investigations with lots of crappy machines instead of them listening to us, specifically these render tickets. Other things are black and white, but the render stuff is not reliably reported by users.

I've still got a single missing chunk, running newest MC version. Walking into the effected area causes me to fall down a few blocks and get stuck, flying over it seems to meet little resistance. (CSP)

Ryan, that's another bug.
One snapshot caused chunks to break beyond repair, the result was void chunks like you described.

We had the same on our server. It was quickly fixed by another snapshot, but it was too late. We ended up generating a new world...

In any event, that's not a rendering issue or a client-side issue at all.

... How can a CSP bug be server-side..?

EDIT Also, what's the code for that bug then, if it isn't this one?

You're searching for MC-63020

"... How can a CSP bug be server-side..?"
SP is the same as multiplayer these days, just that the server (a listen server) and client are on the same machine, in the same JVM. That's why "publish to LAN" works.

Ah, sorry, didn't know that

this happens because the game still has to render... this could be fixed but they would have to rewrite the code completely to generate the surface first, resulting in slowdown.

Please look at the resolution of the bug report before you comment. This bug was already fixed three years ago.

well it wasnt fixed properly then cause lrge chunks are still not loading properly

Agreed, it's gotten particularly bad over the last week or so.  Many times I will be walking/rowing over unloaded chunks.

I dont know why these bugs keep saying resolved, this one, the issue with overly rapid iron golems spawning, and a few others continually occur, but every time I report them they are marked as resolved or duplicated even though they continue to occur. Its been bad lately, and doesnt appear resolved

The issue reported here was fixed almost 5 years ago, the one in 1.14 is completely new and caused by a different issue in the code.
"Duplicate" does not mean "Fixed", otherwise it would say "Fixed". If you report something that was already reported, it will be linked to the original, because there's no point in having multiple reports open for the same thing.

This was never fixed so why does it say it was

It was way worse before 14w31a. Before, chunks near you would not render until you update it. This is mostly fixed now.

i still have it