Andrés del Campo Novales

Thanks for the hint Vladislav, it definitely seems to make a difference.

Furthermore... I have not measured it thoroughly, but 1.8.2pre6 significantly improves the rendering performance, almost back at the speed of 1.8.0!

Thanks Erik and team!!! 🙂

And in case it helps anyone while this gets fixed one way or another, at least for my system (high end, running in ram drive) the best fps value is limiting to 60. More fps or less fps end up loading chunks slower. I wonder if it has to do with matching the monitor refresh rate -vsync off anyway.

That's really sad to hear. To give an idea, here are some improvised perf. measurements (loading 21 chunks render distance -same world position, several attempts averaged, VBO on, Vsync off, etc):

• 1.8: ............. 5 s

• 1.8.1: .......... 6 s

• 1.8.2pre4: ..12 s (!!!)

Worse if instead of limiting to 60fps I raise to unlimited frames, instead of going faster i found this:

• 1.8: ................ 6 s

• 1.8.1: ............. 7 s

• 1.8.2pre4: ... 27 s (!!!)

So 1.8.2 seems to be having only 30-40% of the speed of 1.8 loading chunks.

Chunk loading was really amazing in 1.8 and may people praised it. To many of us (mostly single players), good/reliable chunk loading has always been the top feature request, which was fully realized in 1.8, finally surpassing 1.2.5 and even solving other long term rendering issues.

All those would be very disappointed if the loading speed drops so much. It is hard to see this go so shortly after finally having it at its best ever in 1.8, and would discourage upgrading.

1.8.2 may be a number over 1.8.1, but it actually feels going backwards. I am sure you guys put a lot of effort on this, and I thank you for that. Just please do not lose sight of what many people want -something you already delivered before! Several weeks ago a little girl wrote a letter to Satya Nadella asking Mr Nadella to just keep Minecraft as it is. I/we just ask to keep what is good as it is, and if not possible for multiplayer, at least optional or for single player. Keep the greatest game the greatest. It doesn't deserve less.

Thank you.
P.S. let me know if I can help

Actually, could it be reverted as it was in 1.8 / 1.8.1, at least for single player? Or if needed for slower systems, have it as optional? It is a real drawback for high end systems at least. Thanks / Hugs

Even with unlimited fps and vsync off, the performance of 1.8.1 is just not achieved in 1.8.2 pre1,2,3 by far. I think this is still a valid bug...

Interesting... see MC-64445. Duplicate?

I experience this only when going in the range 28-32 chunks. Note that switching the render distance with the world open seems to cause this issue no matter what the distance... it somehow loses a data structure about what chunks should have been rendered, and not even F3+A will fix it. Only saving the world and reopening it.

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 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.

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!

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!
}

In that case the remaining fix is as easy as a change of "==" to ">=" in the method I mentioned in my comment above. I mentioned 1.7.2 because it is the latest version currently with MCP. I know it fails in 1.7.9 still.

Mojang should find a (supervised and standarized) way of letting the community apply fixes... it is a pity to see all these bugs with fixes available left stranded.

Strange. In which version did you get that Markus?

While I agree with the part of not visiting any other biome, in 1.7.2 it cannot work (according to the code) without actually visiting FrozenOcean and Extreme Hills Edge.

The algorithm in EntityPlayerMP.func_147098_j() will only give the achievement if:
1. the list of visited biomes is 38 and
2. if it can remove from the list of expected biomes all of them after finding them in the visited biomes... -so actually visiting the 38 expected.

Technically two issues are causing not getting the achievement. That said, I ignore if snapshots have removed 10 and 20 from the expected biome list and reduced the size to 36? That would explain what you see. I think that this bug is pretty clear looking at the code -they just need to fix it 🙂 (the fix is easy, actually).

The code checks the list against 38 biomes (which is wrong, as there will be more in the visited biomes list -first issue). This is the list of expected biomes (extracted from 1.7.2 using MCP 9):

23 JungleEdge
15 MushroomIslandShore
35 Savanna
39 Mesa Plateau
29 Roofed Forest
31 Cold Taiga Hills
3 Extreme Hills
24 Deep Ocean
19 TaigaHills
32 Mega Taiga
26 Cold Beach
18 ForestHills
13 Ice Mountains
22 JungleHills
38 Mesa Plateau F
16 Beach
27 Birch Forest
6 Swampland
17 DesertHills
1 Plains
10 FrozenOcean
14 MushroomIsland
21 Jungle
0 Ocean
25 Stone Beach
33 Mega Taiga Hills
36 Savanna Plateau
30 Cold Taiga
7 River
2 Desert
34 Extreme Hills+
4 Forest
28 Birch Forest Hills
11 FrozenRiver
20 Extreme Hills Edge
12 Ice Plains
5 Taiga
37 Mesa

So, on top of that, the 10 FrozenOcean and 20 Extreme Hills Edge are nowhere to be found in my world seed -at least. I have not investigated whether they are naturally generated or not, but I suspect they are not -second issue.

No need to go crazy finding "JungleEdge M" and others -not required!!

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.

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.

I am soo looking forward to a fix for this. To me this one is major, as Fisico said.