Stuttering when crossing chunk borders/loading chunks

I'm seeing the same issue (see attached screenshot). Generally speaking the chunk loading is so much better, thank you! This test was done on a multiplayer server running 1.15-pre1. It's just a normal world, I changed to spectator mode and increased my speed a little, probably similar to elytra flight speed. I have my max FPS set to 120 and have a pretty good machine. As you can see from the screenshot, when I cross a chunk boundary there is a noticeable stutter. Thanks for the awesome work, 1.15 is shaping up very nicely!

Can confirm. Also happens when the chunk borders are not displayed (as those might be a potential cause for lag by themselves as well).

Affects 20w07a.

Same problem here

Vanilla minecraft 1.15.2, clean install

This is happening with my 2080ti, even in single player, new world, clean install of windows 10, no background apps running other than obs (but obs doesnt cause it).

I tested a gt710 in the same system, and it isnt stuttering anywhere near as much, and sometimes doesnt stutter at all when crossing chunk borders.

When testing with both cards, I used stock nvidia control panel settings, all default.  No overclocking. 

Nvidia driver 432.00 (stock windows 10 driver), although the driver version doesnt make any difference at all.

I tested with vsync on/off, framerate cap at 60fps/120fps/off.  A mixture of all, makes no difference.

Temperatures are in check, no overheating.  I tried underclocking the 2080ti memory/core clock in afterburner, and it didnt make any difference.

 Whenever i put the 2080ti in the computer, crossing chunk borders = stutters.  The 2080ti passes all stress tests, such as unique heaven and furmark, left for hours, no crashing/artifacts.

Maybe worth a mention.. When the mem : empties (garbage collection by pressing f3), there is a small micro stutter each time.  Alot worst on the 2080ti, hardly present on the gt710.

Strangely, i set up another computer, ryzen 3700x, 16gb ram, diifferent chipset, new clean install of windows 10, tried both the gt710 and 2080ti, new minecraft world, and still the 2080ti stutters when crossing chunk borders.   Its not the psu as i tested two different power supplies.

In game resolution / refresh rate seems to make no difference to the stuttering at chunk borders.  I tested both 1080p and 1440p.

Please watch the video below :

https://streamable.com/fwzx2u

or

https://youtu.be/it9nrux193w

Still happening on 1.16 snapshots, seems exacerbated by chunks that have blocks very high up

Affects 1.16 pre release 2

Affects 1.16 release candidate 1

Affects 1.16 prerelease 8. I've noticed it seems to be far worse in the nether than the overworld, perhaps due to blocks being generated all the way up to the top bedrock as moosefreak mentioned.

Confirmed in 1.16 Release Candidate 1.

Can confirm for 1.16.1

Still happens in 20w27a

I have noticed that every time I cross a chunk border, the server light goes "??" for a couple of frames. When it goes back to a proper number, I get a lag spike. So I am 90% sure this is caused by lighting updates. This could also explain why its exacerbated by chunks that have blocks very high up, as it takes much longer for the lighting to be calculated for something very high up in the sky. I could be wrong though, this is just an assumption based on what I am noticing.

Affects 1.16.2

Couldn't get any stuttering in singleplayer, but definitely confirmed in 1.16.3 in dark areas with lava on a server - makes me feel anxious and uncomfortable to play, knowing a stutter could happen at any time.

Lowering the allocated RAM to 2 seems to have solved the issue to a degree, it didn't solve the problem, I was wondering whether SP614X was going to fix this issue because it never seemed to be a problem before with 1.14.4 optifine, 1.15 is a bad performer in general. I hope this gets fixed. Read More>>> https://www.mamafacts.com/minecraft-stuttering/

can confirm this bug exists in 1.16.3. tried with and without optifine, and many variations of ram in the jvm args as well. 2080Ti, ryzen 7 2700x, and 16 gb of ram in my rig for reference. im just glad to of found someone with the issue as well and im not going crazy.

I can confirm the lag at 1.16.3, with and without optifine.

1.16.3 vanilla server freshly generated amplified world, stutters are noticeable while walking with normal speed (a little less while sneaking). Easy to reproduce by flying back and forth in creative mode in amplified world.

It's much less noticeable on a recorded video though, even on 144 fps.

Affects 20w45a

Affects 20w46a

I have tested on 1.16.4 with a remote dedicated server; the lag spikes seem to scale proportionally to the server view distance.

With view distance 16+ the lag spikes are the same no matter my client's render distance (even with 2), while they are way less high when server view distance is lower (i.e. 4 with any client render distance).

Affects 20w49a

Getting microstutter lag spikes on 1.16.4. Not 100 percent sure if my issue is related to the chunk border issue but I tested 1.12.2 and the microstutter issue wasn't present. On a render distance of 8 it seems to be happening every 12.5 seconds. Tested this with vanilla, forge, badlion client etc. (with Optifine on and off as well). Please fix this @slicedlime

I just want to say that this issue is already present in 1.14.4 but not yet in 1.14.3 on my end, so we could add this version to the list maybe?

Will this ever be fixed? I'm playing bedrock version because of this. I've had this problem since 1.13. the only resolution I found is setting chunks to 8. When 16 or 20 chunks should be fine at least for me.

To anyone playing on java edition experiencing stutters when moving between specific chunk borders, ive found a work around using the Fabric Mod loader along with the Phosphor mod. For me it fixed this issue. Hope this helps

Can confirm in 20w51a.

Affects 21w03a

Affects 21w05b

Affects 21w06a

Affects 21w11a

Can confirm for 21w15a. Made worse since the world height increase despite it being reverted. No noticeable lag ingame, but my computer makes grinding noise every time I cross a boundary, which is not normal.

Edit: It is normal for my computer to make that sound, just not specifically when I cross a chunk boundary.

Can confirm Brevort's comment. Even worse than just on fly and high velocity, just walking through multiples chunk is incredibly laggy.

So there seems some general behaviors regarding which chunk borders cause issues.  I'm starting to find patterns in a world I generated, testing on a server that is run on my computer, on 21w16a with the caves and cliffs data pack loaded.  It seems that for me, the issues exclusively occur on a server run with the datapack as it doesnt happen on a 21w14a server (before the datapack), nor in singleplayer, but still match the issues described in this report and should still be of use to know and may help pinpoint the general issues regardless.  My situation seems to have, if anything, amplified the issues.

note: upon further reading, it seems that while this issue can be taken generally, it does specifically address some sources regarding the server+C&C datapack combo in bug report MC-223383

There seem to be 'permanently problematic' (type A) areas, as well as 'semi-problematic' (type B) areas that I'll refer to as (fig.1, below).  I'll be referencing type A and type B regions numerous times, so here's how I'm defining them here on out:

• Type A Region, Permanently Problematic: The region in question always causes lag spikes.

• Type B Region, Semi-Problematic: The region in question only sometimes causes lag spikes, and depends on whether the player has loaded the type A region, and what the player is doing.

Fig.1 - Hovering in a location in the type B region, that is about to load in the type A region in front.

The area near spawn in my world was a village, and a type A region-- leaving the area and returning, logging out and back in, restarting the server... lag spikes always occurred when crossing chunk borders in the area, and also resulted in the shift+F3 pie chart reading increasingly higher "scheduled executables" with each lag spike to no bound.  This happened in other areas of the world too.  These type A regions can be separated by hundreds of blocks or more, discovered from any mode of gameplay.

It is worth noting that all villages I encountered were type A regions, but not all type A regions were villages (the issues also occurred in seemingly 'random' areas with no notable features/pattern).  **  Note in fig.1, that the chunks stopped loading at the village boundary, and a massive lag spike followed.  To verify that this occurs with villages at the least, and does not completely depend on what the player is doing, I recreated the world from scratch, and teleported to near the village in question.  Loading the village the first time (i.e. chunks freshly created) did not result in formation of a type A region.  However, completely leaving the area and returning to the village boundary (now that the chunks are already generated) results in type A region formation. So the general point here to note, is that the issue might only occur after the chunks are generated, when they are revisited.  In the case of the village, approaching the village from any side of the rectangular bounding box, results in lag spikes once the village boundary is loaded.

Upon leaving type A areas (i.e. villages), it induced type B areas, and it gets a little complicated in how it works.  There are two states that type B regions can be in: problematic, and non-problematic.  Chunks that were not problematic before, became problematic temporarily.  The problematic behavior however will vanish when moving further away from both the type A and type B areas to unload everything.  Returning to the type B area alone will no longer be problematic, you can move in any direction without any spikes, as long as you are away from the type A area.  Returning to the type A area again will restart the issues in the type B area.

Problematic behaviors noted:

• Directional-dependent lag spikes

  • **Example, directions are random: moving north, east or south across chunk borders caused lag spikes, but moving west didn't.  You can move east across chunk borders successively-- 1, 2, 3, 4 and 5, and every single crossing will cause a spike.  But, moving west in the opposite direction across the same borders successively-- 5, 4, 3, 2, 1, never causes a spike.

  • The directional dependence is somewhat inconsistent if speaking generally, however upon further investigation, there is one reliable pattern that occurs when flying through the problematic type B region, away from the type A region. When moving away, at some point the lag spikes will stop.  As soon as the spiking stops when moving away, indicating you are sufficiently far from the type A region, immediately backtracking causes the spikes occur, and switch behaviors to become directionally-dependent.  They no longer occur moving away, but will only occur moving toward the type A region.  Moving back and forth anywhere in the type B region at this point will stay directionally-dependent until either: (1) unloading the type B region, or (2) revisiting the type A region.

• Biome identifying and rendering issues

  • When a type B region is in a non-problematic state, biomes are identified correctly.  When a type B region is in a problematic state, as induced by loading the type A region, biome identification is scrambled-- biomes are misnamed in the F3 info, and therefore biome colors are also incorrectly rendered (see figures 2-4 below)
    

    [media]

    Fig.2 - Type B region in a non-problematic state with correct naming and (mostly fine) rendering.

    [media]

    Fig.3 - Same Type B region in a problematic state with incorrect naming and rendering.  The colors of the ocean shows a line along a chunk boundary revealing where issues are occurring.  The grass in the lower left corner of the image is also visibly less saturated compared to fig.2, due to it being miscategorized as ocean.

    [media]

    Fig.4 - Same Type B region, hovering over landmass that is being miscategorized as ocean, per F3 info.  Following the terrain in the direction of the bottom left corner of the image goes deeper into the type B region, towards the type A region, pictured in fig.1.  All of the type B region spanning 24-26 more chunks in this direction, is all land, but still all considered ocean by the game.

• Potential correlation to bug MC-214793 - Dark/Incorrectly Lit Chunks & Mob Spawning

  • In the type B region near its edge, several chunk lighting issues were found.
    

    [media]

    Fig.5 - Same Type B region, looking at the same area pictured in figs.2-4 from a different angle.  The landmass in the left side of the image here, matches the land in the middle of the previous figures.  Some chunks are completely dark, and other locations see an abrupt change in light level at chunk borders, particularly from the coral reef in the top part of the image.  The dark chunks also approximately defined the lag spike region-- moving up to the left results in lag spikes, chunks down to the right were not problematic.

Fig.6 - Two long strips of dark chunks, with potential correlation to type B regions.  The dark chunk strip on the right was created when moving away from a village type A region, located directly to the right.  The dark chunk strip on the left was created when moving away from an unknown source type A region, located directly to the left.  In both cases, the dark chunk strip is perpendicular to the line of sight to the type A region.

• • The dark chunk issues are inconsistent in the aspect that they do not always materialize every time the type B region is problematic.  While inconsistent, the issue is sometimes reproducible in the the exact same chunks if it occurs-- the dark chunks can appear in the same arrangement in the same location.  However, the abrupt lighting changes at chunk boundaries in the coral reef still remain regardless.

  • Dark chunk issues are however consistent in the aspect that they will occur no matter which side of the type A region that you start at and fly directly away from, and happen in the type B region when you move some distance away.

  • The perfectly dark chunks are treated as mob-spawnable by the game, regardless of night or daytime (mobs will spawn in such dark chunks midday)

  • On the rare occasion, dark chunks can sometimes be completely missing, and F3 gives "waiting for chunk" indefinitely.

Anyone else able to find and agree with any patterns?  On a server running the caves & cliffs datapack?  In singleplayer?

Hope this helps find the source of the issue!

Confirmed for 21w16a with Caves&Cliffs preview datapack. Stuttering is consistent and severe.

Made this video showcasing this bug for a bug report about this issue in 21w16a since I didn't know this one existed already.
The lag spikes are massive tho...
https://youtu.be/W8E8_l_PpYM

I'm noticing this on my server using the new-caves datapack in 21w16a. The lag spikes are consistent across certain chunk borders (as others have stated above) and take a few seconds each--enough to make the game practically unplayable. The only new information I have to add is that during each lag spike, the console fills with "Received invalid biome id: 1" warnings. In just a few minutes of play and a few border crossings, I have over 173,000 warnings of this type. Hope this helps.

I can confirm most of the comments here, especially the well-documented comment from Luna on 4/22.  I began to notice this issue when adding the caves & cliffs preview data pack to 21w16. What really struck me as strange is that broad areas do not exhibit this behavior, such as near the spawn point but even other areas away from it, with no identifiable rhyme or reason.  Then other areas were horrible, lagging while walking between each chunk.  Areas with an issue were 100% consistent in causing the lag, across restarts of the game as well. Further complicating the troubleshooting is that, as mentioned by Luna, it is directional.  It only happens when moving one way into a chunk (though the direction changes depending on the chunk).  You can walk back into the previous chunk without an issue and walk back only to "freeze" for a moment, each time without fail.  When attacking a mob across a chunk exhibiting this behavior the lag ends in the mob being able to attack you without you knowing it.

I can also confirm the "100,000+" error messages in the log regarding "Invalid biome id: -1" and the accompanying message related to many error messages in the log causing performance issues.  These errors occasionally cause the program to hang when loading the world and require a force close.  I am not sure if they are related to the chunk crossing problem or not.

@kristiani posted about the "Received invalid biome id: -1" error causing lag spikes when crossing chunk borders in the 21w16a snapshot with the data pack enabled. It seemed to be directly connected to what others here are experiencing, and was quite insightful, so I'm sharing it below here in the hopes it will help.

After testing this issue in several scenarios, can confirm in 21w16a. However it is rather inconsistent as @Willber mentioned... 

Some points worth mentioning:

• I can say for sure in all scenarios the log line is being written... "Received invalid biome id: -1"

  • However, having said that ... there are times when some kind of binary data is written to the latest.log, this causes a "lockup" of sorts, then subsequent attempts to write to the file appear to fail – i.e. the log file stops growing in size BUT the "Minecraft game output" GUI console ... continues to show logs for "Received invalid biome id: -1".

  • At this stage ...  the world appears fine ... no lag, no freeze, (probably because no more logs being written)

• When you do get the lag/freeze ... that's when the log keeps getting written... keeps growing... likely Disk IO causing the lag/freeze.

• This only happens when crossing chunk boundaries... moving up and down in a chunk causes no lag/freeze issues as no chunks are being (un)loaded, no logs being written.

• For the same worlds  that are freezing.... (as @Frostrix mentioned) far away from spawn (for example @ 10000 ~ 10000), no logs, and no freezing...

  • But again ... having said this, if you look carefully when at these distances, the log file grows for a short time... then seems to reach the "lockup" moment mentioned before (log file stops growing) ... which means you don't experience lag anymore.

  • Now this is where the FUN part comes in .... If I /tp back to spawn.... and the log file comes out of it's "lockup" and starts writing to disk ... causing the lag/freezing in game to start up again !?? very confusing.

Really hope this info helps the devs 😛 - this problem is very bad for an SSD with so many writes, and makes the current datapack somewhat unusable 😞 

All tests done on varying seeds with no obvious pattern (except for the points above) as to when the log file "lockup" would happen and when it wouldn't.

@TelepathicGrunt also provided some information on why this error seems to be generated; it is in reference to dimension data packs, but I think that the issues may be related. Perhaps some of the cave biomes in the Caves and Cliffs datapack are behaving in a similar way to dimension biomes added in json datapacks.

From my testing and debugging, this appears to be specifically caused by the json biome having any structures added to it and the user loads up an already generated chunk with that biome. The instructions about exiting and re-entering the dimension is not needed. Just fly forward in the dimension for a few seconds, turn around, and fly back and the issue will present itself. 

I was helping someone with their mod and they were using json biomes/json dimensions for their mod and they got this issue because their biome has structures in it. When I ran the debugger, their biome source was using the correct dynamic registry instance and was returning the correct biome instance. But within SChunkDataPacket class, it had the exact same dynamic registry so that was good. But the biome being returned from the chunk is a completely new biome instance that is not present in the dynamic registry at all. And that is what causes the massive lag spike as the game starts writing the error to the log like crazy. So as far as I can tell, the biome source is not the issue here. The chunk receives the correct biome as well as it doesn't error upon first generation. Rather, the issue seem to lie in how the chunk either saves the biome to memory or retrieves the biome from memory. But only when structures are present in the biome. 

Very odd situation but hopefully this digging I did helps

@i509VCB added:

I've checked with someone who has such a case in a modded environment. Simply we loaded the world, then put a breakpoint on the Biome class' constructor and replicated it like telepathic grunt did above.

What I noticed looking through the debugger is that when structures are loaded, what yarn calls `RegistryOps` will attempt to load the biome from json and decode the biome. This occurs somewhere in the call site of `RegistryOps.of(...)`. This occurs in the constructor of `PoolStructurePiece` which occurs as a result of loading structure starts.

Can confirm on 21w17a

After upgrading today to 21w17a what I have found is that there are no issues (related to stuttering or invalid biome id’s in the log) as long as it is a newly created world. If I save and exit, then reload the world, it now won’t even open, crashing Java and showing a repeating invalid biome id -1. I can recreate the world and there will be no problems until I save and exit.

It happens in 20w17a too. I reloaded a world I was playing on and it started happening. I had a game crash due to an invalid biome. I was able to load the world again after the crash, and this time I noticed that in the F3 menu the biome was listed as null. It also seemed to list random chunks surrounding the null area as ocean, despite them being plains, taiga, and a river. I am using the official 1.18 worldgen datapack. The pie chart in the f3 menu shows scheduled executables as taking up a large chunk of memory, every lag spike it increases and slowly goes back down to zero.

Just convinced the game to crash again, this time with the debug window open:

Process crashed with exit code -805306369

I checked this out, and both comments above are correct. However, the bug still happens in a fresh world when going through a Nether Portal and back, and the bug is still just as bad as ever when re-opening a world.
HOWEVER, this bug now more often applies to chunks farther from spawn too, whereas they hadn't before. This bug seems to still only target pre-existing chunks (chunks that were generated before you open the world again,) and using the "Optimize World" button doesn't do anything anymore, despite being able to sometimes help a bit before.

This fix was implemented back in January for this specific bug in case this helps anyone.

Can confirm in 21w18a. I've never noticed it before, but my Dell makes a grinding sound when crossing chunk boundaries, similar to my HP. No visual indication, though.

Affects 1.17 Pre-2

Still an issue with 1.17 RC-1

Can confirm in 1.17 and 1.17.1 Pre-release 1.

Can confirm in 21w37a, and it is significantly worse than 1.17.1 in my system.

It still happens in 21w37a, and is a bit worse

Turning biome blend in video settings completely off can improve performance (that is if you have it on or even high).

NelLexvul, that has nothing to do with the problem.

Affects 21w38a

The lagspikes are severely increased in a world with extended world height: Try this 4080 block tall custom world in 21w38a 

Can confirm in 21w40a.

Affects 21w41a

Affects 21w42a

Affects 21w42a, especially noticeable while running, using the elytra, flying in creative and spectator, and even boating around.

Affects 21w43a

Affects 21w44a too

Affects 1.18 Pre-1

Can confirm in 1.18 Pre-release 2.

I had the stuttering issue also, however after increasing the Java heap to 4gb (-Xmx4G) it was originally 2gb (-Xmx2G) things got a lot better. Not sure it was necessary to go to 4gb but that worked for me. 

Affects 1.18 Pre-3

Affects 1.18 Pre-4

Affects 1.18 Pre-6

can confirm in 1.18 pre-3.

please fix this this will prevent me and my potatoe device from playing on 1.18

The bug occurs only in 1.18 for me

Affects 22w11a

Affects 1.18.2

Affects 1.18.2

Affects 1.18.2

what the votes???

Turning off Threaded optimisation in Nvidia control panel fixed this for me in 1.18.2

still happens in 1.19.2 and even the new 1.20 22w43a

And yes. I vote the 200th of this issue. This bug makes the game about to be unplayable (as least in vanilla Minecraft).

Still occurs in 23w18a, despite the fix of similar bug MC-162253.

Can confirm in 1.20 Pre-Release 4.

This also affects 1.20 since 1.20 RC 1 has been added as an affects version, right?

i experienced this to, im using optifine 1.20.4, i fix this by change chunk builder to threaded (before im using semi blocking and thats why i experienced this)