| Type: | Bug | ||
| Reporter: | Vasil Bochev | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 421 |
| Labels: | chunk, display, invisible, rendering, visual, x-ray | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Sometimes, quite often, chunks are not loaded visually in a line. What I expected to happen was...: What actually happened was...: Steps to Reproduce: |
| Comments |
| Comment by sem versluis [ 24/Nov/20 ] |
|
i still have it |
| Comment by Jukitsu [ 16/Oct/20 ] |
|
It was way worse before 14w31a. Before, chunks near you would not render until you update it. This is mostly fixed now. |
| Comment by Sam Anderson [ 28/Feb/20 ] |
|
This was never fixed so why does it say it was |
| Comment by Fabian Röling [ 07/May/19 ] |
|
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. |
| Comment by Jay Jaegar [ 07/May/19 ] |
|
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 |
| Comment by Jeremie Dexter [ 06/May/19 ] |
|
Agreed, it's gotten particularly bad over the last week or so. Many times I will be walking/rowing over unloaded chunks. |
| Comment by Brandon (Inactive) [ 28/Mar/19 ] |
|
well it wasnt fixed properly then cause lrge chunks are still not loading properly |
| Comment by Fabian Röling [ 17/Aug/18 ] |
|
Please look at the resolution of the bug report before you comment. This bug was already fixed three years ago. |
| Comment by Michael91273 [ 17/Aug/18 ] |
|
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. |
| Comment by Ryan Rolet [ 11/Sep/14 ] |
|
Ah, sorry, didn't know that |
| Comment by Patrick Dinklage [ 11/Sep/14 ] |
|
"... How can a CSP bug be server-side..?" |
| Comment by Kumasasa [ 10/Sep/14 ] |
|
You're searching for |
| Comment by Ryan Rolet [ 10/Sep/14 ] |
|
... How can a CSP bug be server-side..? EDIT Also, what's the code for that bug then, if it isn't this one? |
| Comment by Patrick Dinklage [ 28/Aug/14 ] |
|
Ryan, that's another bug. 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. |
| Comment by Ryan Rolet [ 28/Aug/14 ] |
|
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) |
| Comment by a [ 02/Aug/14 ] |
|
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. |
| Comment by Anon Ymus [ 02/Aug/14 ] |
|
This is as fixed as it's going to get. |
| Comment by Patrick Dinklage [ 02/Aug/14 ] |
|
I can confirm it. |
| Comment by Andrés del Campo Novales [ 02/Aug/14 ] |
|
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 |
| Comment by Andrés del Campo Novales [ 26/Jul/14 ] |
|
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. |
| Comment by jonathan2520 [ 26/Jul/14 ] |
|
I suspect that as the snapshots settle down, these bugs will all evaporate. We'll see. |
| Comment by Tomas Slavotinek [ 26/Jul/14 ] |
|
This is NOT same issue as |
| Comment by Kumasasa [ 26/Jul/14 ] |
|
This ticket got superseeded by |
| Comment by Daniel M [ 23/Jul/14 ] |
|
Confirmed for 14w30a and 14w30b shows for a split second or two. |
| Comment by Daniel M [ 23/Jul/14 ] |
|
This might be fixed with 14w30a, we will see if that happens |
| Comment by Anon Ymus [ 21/Jul/14 ] |
|
Holger, that's |
| Comment by Eric Dusenberry [ 21/Jul/14 ] |
|
I guess that's what Mojang meant by bending time around space instead of space around time. |
| Comment by Holger [ 21/Jul/14 ] |
|
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. |
| Comment by Andrés del Campo Novales [ 18/Jul/14 ] |
|
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 |
| Comment by a [ 17/Jul/14 ] |
|
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, |
| Comment by Bob Dobbs [ 16/Jul/14 ] |
|
press F3+A. This has beea serious problem the last few snapshots without change. |
| Comment by [Mod] Michael Wobst [ 16/Jul/14 ] |
|
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. |
| Comment by Kumasasa [ 10/Jul/14 ] |
|
Most probably you've described |
| Comment by Matt Sheridan [ 10/Jul/14 ] |
|
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. |
| Comment by Christopher Martin [ 03/Jul/14 ] |
|
Is it just me, or is this much improved under 14w27b? |
| Comment by Grigoriy chekanov Vladimirovich [ 02/Jul/14 ] |
|
Yes, I have the same settings, just change the pieces and yet lost |
| Comment by Eric Dusenberry [ 29/Jun/14 ] |
|
Usually after a while, Minecraft undergoes an intense amount of lag (<1 fps) while trying to load all the chunks, but fails. |
| Comment by a [ 29/Jun/14 ] |
|
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… |
| Comment by Eric Dusenberry [ 29/Jun/14 ] |
|
Try changing your render distance - it worked for me! However, it may still happen later. |
| Comment by Warren Liddell [ 24/Jun/14 ] |
|
Thankyou Anton .. this issue had been really annoying since latest snapshot an your trick has solved it big time |
| Comment by Kumasasa [ 23/Jun/14 ] |
| Comment by Anton Morozov [ 23/Jun/14 ] |
|
Thanks, Kumasasa! |
| Comment by Kumasasa [ 22/Jun/14 ] |
|
That's |
| Comment by Pika who [ 22/Jun/14 ] |
|
None of the chunks are loading for me in the 1.8 snapshots. :/ |
| Comment by Tomas Slavotinek [ 21/Jun/14 ] |
|
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: 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... |
| Comment by Christopher Martin [ 20/Jun/14 ] |
|
OP or mod, 14w25b to the affected versions list, please. |
| Comment by Warren Liddell [ 19/Jun/14 ] |
|
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 |
| Comment by a [ 18/Jun/14 ] |
|
This is actually better for me in 14w25a than 1.7.9 (MacBook Air mid 2012) Anton Morozov: does your computer have a HDD or SSD? Yup, the game is unplayable on my iMac. |
| Comment by Anton Morozov [ 18/Jun/14 ] |
|
Snapshot 14w25a!!! 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. |
| Comment by Paul Kerry M. Quinn [ 30/May/14 ] |
|
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 !!! |
| Comment by Anton Morozov [ 29/May/14 ] |
|
14w21b, I'm joining the club. As someone mentioned, a showstopper |
| Comment by Warren Liddell [ 15/May/14 ] |
|
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. |
| Comment by a [ 15/May/14 ] |
|
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). |
| Comment by Christopher Martin [ 14/May/14 ] |
|
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. |
| Comment by a [ 14/May/14 ] |
|
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? |
| Comment by Christopher Martin [ 14/May/14 ] |
|
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. |
| Comment by fienxjox [ 14/May/14 ] |
|
@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. |
| Comment by Christopher Martin [ 14/May/14 ] |
|
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. 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. |
| Comment by a [ 08/May/14 ] |
|
14w19a. The below is on the ATI Radeon HD 4670 w/ 256 MB and 8 GB 1067 MHz DDR3 (6GB for the JVM). |
| Comment by a [ 02/May/14 ] |
|
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. |
| Comment by a [ 30/Apr/14 ] |
|
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. |
| Comment by Aaron Bell [ 30/Apr/14 ] |
|
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:
|
| Comment by a [ 24/Apr/14 ] |
|
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. |
| Comment by Andrés del Campo Novales [ 24/Apr/14 ] |
|
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! } |
| Comment by a [ 24/Apr/14 ] |
|
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). |
| Comment by Aaron Bell [ 24/Apr/14 ] |
|
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? |
| Comment by a [ 24/Apr/14 ] |
|
Changing the framerate slider from Unlimited to 10 fps does nothing for chunk loading/rendering in 14w17a. 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 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). |
| Comment by aaaa aaaa [ 21/Feb/14 ] |
|
Voted for this issue. It's simply annoying, and worthy of an Alpha version of a game. |
| Comment by Andrés del Campo Novales [ 04/Feb/14 ] |
|
Well... to summarize a bit so far for newcomers, and in the hope of getting news from Mojang: To reduce the effect (roughly):
To remove it completely:
Why fix it: Still relevant and popular"really annoying. it destroys the gameplay feeling I love so much." (Tom Mate) 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. |
| Comment by Pixelgraph [ 06/Dec/13 ] |
|
@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. |
| Comment by Aaron Bell [ 06/Dec/13 ] |
|
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. |
| Comment by Daniel Whitney [ 05/Dec/13 ] |
|
Biggest rendering error I've ever encountered, This is in the new 13w49a snapshot. |
| Comment by Bas Dingemans [ 18/Nov/13 ] |
|
f3 + a seems to fix this too |
| Comment by Andrew Bryant [ 07/Nov/13 ] |
|
Thanks for the quick fix, I was going nuts with the slow loading |
| Comment by Daniel Whitney [ 02/Nov/13 ] |
|
@Travis |
| Comment by Bill O'Brien [ 29/Oct/13 ] |
|
Thanks, Tobyn And, like Ezekiel says, it doesn't eliminate the problem. |
| Comment by [Mod] Ezekiel (ezfe) [ 27/Oct/13 ] |
|
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. |
| Comment by Tobyn [ 27/Oct/13 ] |
|
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. |
| Comment by sharon johnson [ 26/Oct/13 ] |
|
I have started having this issue with 1.7.2. Seems odd that I didn't have problems until this update. |
| Comment by Ilya Landa [ 25/Oct/13 ] |
|
@thefoot I'm not sure what effect this mod has on Multi-Player. |
| Comment by thefoot [ 25/Oct/13 ] |
|
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! |
| Comment by Jennifer [ 21/Oct/13 ] |
|
(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.) |
| Comment by Andrés del Campo Novales [ 03/Oct/13 ] |
|
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 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. |
| Comment by _zombiehunter [ 26/Sep/13 ] |
|
Still quite common in 13w39a ! |
| Comment by Bob Saggot [ 20/Sep/13 ] |
|
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. |
| Comment by Tavis [ 14/Sep/13 ] |
|
I don't think this ever happened before beta 1.8. |
| Comment by Damian Lee [ 14/Sep/13 ] |
|
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 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! |
| Comment by [Mod] Ezekiel (ezfe) [ 14/Sep/13 ] |
|
Guys, while we wait for this issue to be resolved, I recommend you use (fn on a mac)+F3+A to reload the chunks. |
| Comment by Patrick Dinklage [ 14/Sep/13 ] |
|
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. |
| Comment by _zombiehunter [ 13/Sep/13 ] |
|
Confirmed for 13w37b (still very common) and 1.6.3 ! |
| Comment by _zombiehunter [ 12/Sep/13 ] |
|
Confirmed for 13w37a ! |
| Comment by Christopher Wassall [ 11/Sep/13 ] |
|
@Damian Lee |
| Comment by Damian Lee [ 11/Sep/13 ] |
|
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). |
| Comment by Christopher Wassall [ 07/Sep/13 ] |
|
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 |
| Comment by _zombiehunter [ 06/Sep/13 ] |
|
This bug seems to be quite common in 13w36a. Same with 13w36b. |
| Comment by Daniel Sturk [ 29/Aug/13 ] |
|
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. |
| Comment by Wulfdao [ 28/Aug/13 ] |
|
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. |
| Comment by Tavis [ 19/Aug/13 ] |
Sounds like you have "Advanced OpenGL" turned on. See
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 |
| Comment by Damian Lee [ 19/Aug/13 ] |
|
I'm noticing this mainly in single player though. |
| Comment by mike [ 19/Aug/13 ] |
|
Can someone please remove the duplicate pictures? There are many of them and it is clogging the page. |
| Comment by mike [ 19/Aug/13 ] |
|
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 |
| Comment by Damian Lee [ 19/Aug/13 ] |
|
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. |
| Comment by MightyPork [ 12/Jul/13 ] |
|
Still in 1.6.1 and 2, best noticeable when riding a horse or travelling by boat / minecart. |
| Comment by _zombiehunter [ 06/Jul/13 ] |
|
Was playing SMP in 1.6.1/1.6.2, happens all the time. Anyone update the "affects versions" ... ? |
| Comment by Katie Matthews [ 01/Jul/13 ] |
|
I've always had this problem and presumed my PC wasn't powerful enough. |
| Comment by mike [ 29/Apr/13 ] |
|
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. |
| Comment by dirk (switched to Minetest) [ 29/Apr/13 ] |
|
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. |
| Comment by Andrew Mancini [ 29/Apr/13 ] |
|
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. |
| Comment by Tavis [ 23/Apr/13 ] |
|
Still happens with smooth lighting turned off. |
| Comment by Charlotte Buff [ 23/Apr/13 ] |
|
@Aotr It's not. |
| Comment by mike [ 10/Apr/13 ] |
|
Even though it has become more rare, I can most commonly find it in a superflat world. |
| Comment by mike [ 24/Mar/13 ] |
|
Confirmed in 1.5.1 official. |
| Comment by Ilya Landa [ 23/Mar/13 ] |
|
Didn't help me. Not in SP, at least. |
| Comment by George Gates [ 23/Mar/13 ] |
|
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. |
| Comment by Pixelgraph [ 22/Mar/13 ] |
|
Do you have Advanced Open GL on? Try turning it off. |
| Comment by Ilya Landa [ 21/Mar/13 ] |
|
I started seeing this in 1.3.1, possibly due to a major change that "Made Singleplayer internally use a Multiplayer server". |
| Comment by Tavis [ 21/Mar/13 ] |
|
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. |
| Comment by Fjodor Dostojewski [ 20/Mar/13 ] |
|
Still a problem in 1.5.1 pre-release. |
| Comment by dirk (switched to Minetest) [ 20/Mar/13 ] |
|
Started getting worse with one of the latest snapshots. Also confirmed for 1.5.1-pre |
| Comment by Tavis [ 13/Mar/13 ] |
|
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. |
| Comment by MisterSanderson [ 13/Mar/13 ] |
|
The problem still occurs in 1.5. |
| Comment by Tavis [ 21/Feb/13 ] |
|
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. |
| Comment by Tavis [ 16/Feb/13 ] |
|
To reproduce: 1. Set render distance to far Notes: Hypothesis: |
| Comment by [Mod] Ezekiel (ezfe) [ 15/Feb/13 ] |
|
Updated Affected Version |
| Comment by _zombiehunter [ 15/Feb/13 ] |
|
In the 13w07a snapshot, chunks still don't display properly. Please update the "Affects Version/s:" tag. |
| Comment by Alex G. [ 13/Feb/13 ] |
|
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. |
| Comment by darkinnit [ 31/Jan/13 ] |
|
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. |
| Comment by George Gates [ 31/Jan/13 ] |
|
@Tavis: The framerate FRAPS records at is variable. 60, 50, and 30 are built-in options, with a custom option as well. |
| Comment by Tavis [ 29/Jan/13 ] |
|
Minecraft limits the number of render updates per frame. 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. |
| Comment by Michael Burgwin [ 28/Jan/13 ] |
|
@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. |
| Comment by Brandon Slade [ 28/Jan/13 ] |
|
@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. |
| Comment by Tom Willshire [ 28/Jan/13 ] |
|
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. |
| Comment by Tavis [ 26/Jan/13 ] |
|
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. |
| Comment by Michael Burgwin [ 14/Jan/13 ] |
|
The new Renderer has not been implemented yet, as far as I know. |
| Comment by Paulquappe [ 13/Jan/13 ] |
|
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. |
| Comment by user-4cf05 (Inactive) [ 10/Jan/13 ] |
|
Confirmed as of 13w02a |
| Comment by Leon Ericsson [ 25/Dec/12 ] |
|
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. |
| Comment by Alexander Hammett [ 13/Dec/12 ] |
|
It is official mod support. You'll be able to just drag and drop mods. |
| Comment by DyO Kasparov [ 13/Dec/12 ] |
|
And what's that? |
| Comment by Alexander Hammett [ 13/Dec/12 ] |
|
Because without fusion of SP and MP there will be no Mod API |
| Comment by DyO Kasparov [ 10/Dec/12 ] |
|
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. |
| Comment by Tavis [ 02/Dec/12 ] |
|
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. |
| Comment by Tavis [ 30/Nov/12 ] |
|
Hiram: I was actually referring to further experiences with this bug. |
| Comment by Hiram [ 30/Nov/12 ] |
|
Tavis: See |
| Comment by Tavis [ 29/Nov/12 ] |
|
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. |
| Comment by Tavis [ 29/Nov/12 ] |
|
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. |
| Comment by Hiram [ 29/Nov/12 ] |
|
Tavis: Yes and yes. And if i turn it on again it reappears. |
| Comment by damien payne [ 29/Nov/12 ] |
|
confirmed... TY. |
| Comment by Tavis [ 29/Nov/12 ] |
|
Hiram: Do you happen to have Advanced OpenGL (in video settings) turned on, and does the problem go away if you turn it off? |
| Comment by Hiram [ 27/Nov/12 ] |
|
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 |
| Comment by Sascha Hüls [ 22/Nov/12 ] |
|
The first picture is in a Singleplayer game. |
| Comment by Tom Mate [ 21/Nov/12 ] |
|
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 |
| Comment by Rickard Åberg [ 19/Nov/12 ] |
|
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. |
| Comment by Jack Dandiels [ 18/Nov/12 ] |
|
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. |
| Comment by Holger [ 16/Nov/12 ] |
|
+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... |
| Comment by MisterSanderson [ 13/Nov/12 ] |
|
The issue |
| Comment by Paulquappe [ 09/Nov/12 ] |
|
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. |
| Comment by Fabian Klüpfel [ 02/Nov/12 ] |
|
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. |
| Comment by Mike Johnson [ 02/Nov/12 ] |
|
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. |
| Comment by neotask [ 02/Nov/12 ] |
|
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. |
| Comment by Rickard Åberg [ 01/Nov/12 ] |
|
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. |
| Comment by [Mod] Ezekiel (ezfe) [ 26/Oct/12 ] |
|
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 |
| Comment by Rickard Åberg [ 26/Oct/12 ] |
|
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. |
| Comment by Sean Caruso [ 26/Oct/12 ] |
|
This seems to happen very often for me in the Nether. I don't see it very often in the normal world. |
| Comment by [Mod] Ezekiel (ezfe) [ 25/Oct/12 ] |
|
Yeah. If you load up a 1.7 Beta world, chunks load as far as you can see in all directions, it actually works. |
| Comment by Dickson Yamada [ 25/Oct/12 ] |
|
I think Ezekiel is right. But that is certainly annoying as well. |
| Comment by [Mod] Ezekiel (ezfe) [ 25/Oct/12 ] |
|
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. |
| Comment by John Smithson [ 25/Oct/12 ] |
|
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. |
| Comment by [Mod] Ezekiel (ezfe) [ 25/Oct/12 ] |
|
The F3A thing worked, thanks! |
| Comment by Vasil Bochev [ 25/Oct/12 ] |
|
The F3 thing doesn't work for me. |
| Comment by Tavis [ 25/Oct/12 ] |
|
F3+A (reload chunks) fixes it without having to cycle through render distances. |
| Comment by Talven81 [ 24/Oct/12 ] |
|
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. |
| Comment by [Mod] Ezekiel (ezfe) [ 24/Oct/12 ] |
|
A workaround is resetting your rendering distance. |