Gameplay
Cubic Chunks: Reduced lag, infinite height, and more [The #1 Suggestion Thread of all time!][Updated! 6/14]
Poll: Which parts of this system do you like?
Ended May 15, 2014
Poll: Which parts of this system do you NOT like?
Ended May 15, 2014
Poll: Do you support this system's implementation overall? (If yes, if
Ended May 15, 2014
also you should check out Tall Worlds
Hmm...
Snapshot 14w05a
Presses F3
Sees Chunk: X Y Z in CX CY CZ
Seems that maybe "Cubic Chucks" were added in this snapshot or the last one. (Proof Below)
Chuck Loading is different: (After toggling your render distance, just look around to tell.)
See for yourself.
16 - Max Y in Chuck
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Chuck cords change: CX CY CZ
16 - Max Y in Chuck
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
My brain still thinks that Notch makes minecraft *facepalm*. It is a proof of concept... A good one at that. It would definately make minecraft better if they added this functionality.
It happens to the best of us.
The scenario where you are saying there is more lag is comparing the current systems 256 height world to a cubic chunks system with infinite height. Which is comparing apples to oranges, as in one you have infinite build height the other you do not. So yes in that scenario you will lag a bit more, however probably not as much as you might think.
Just for fun I decided to write up a bit of the formulas and do some of those comparisons with a bit of explanation. (Note: I am not 100% sure on how the exact formulas for the render distance works but this is my best stab at them, if I made a mistake please let me know and I will correct)
So let us start off with the current system. It's chunks load all 256 vertical blocks for all chunks it loads, so each chunk is 16 x 16 x 256 (another way to look at this is 16 x 16 x WorldHeight).
If you are using a render distance of 16 then you are loading an area of chunks of ((RenderDistance*2)+1 x (RenderDistance*2)+1) (this is derived the info on from http://minecraft.gamepedia.com/Chunks ) or 33 x 33. So the calculation becomes ((RenderDistance*2)+1 x (RenderDistance*2)+1)*(16 x 16 x WorldHeight) = (33 x 33)*(16 x 16 x 256) or = (1089)*(65536) = 71,368,704 blocks
For cubic chunks the calculation is a little different the chunks are all 16 x 16 x 16 or 16^3 regardless of the world height. Normally cubic chunks would load a sphere around the player, however if the WorldHeight/ChunkHeight is less than RenderDistance*2 then really the system would be loading a cylinder due to the fact that with RenderDistance*2 greater than WorldHeight/ChunkHeight then the system would be trying to load chunks that CANNOT EXIST. Note the cylinder calculation would only be used in the WorldHeight/ChunkHeight is less than RenderDistance*2
For the volume of the spherical chunk load the calculation is ((4/3)pi*(RenderDistance+.5)^3)*(16^3)
For the volume of the cylindrical chunk load the calculation is ((WorldHeight/ChunkHeight)*pi*(RenderDistance+.5)^2)*(16^3)
In the current scenario WorldHeight/ChunkHeight is 256/16 = 16 while RenderDistance*2 is 32 so the cylindrical load should be used. Which means the calculation is ((WorldHeight/ChunkHeight)*pi*(RenderDistance+.5)^2)*(16 x 16 x 16) = ((256/16)*3.14*16.5^2)*(4096) = (16*3.14*272.25)*(4096) = 13677.84*4096 (lets round up for the decimal) = 13678*4096 = 56,025,088 blocks.
So with this first scenario current system has 71,368,704 blocks while the cubic chunks would load = 56,025,088 blocks
With a WorldHeight of 512 then in the current system the formula would be:
((RenderDistance*2)+1 x (RenderDistance*2)+1)*(16 x 16 x WorldHeight) = (33 x 33)*(16 x 16 x 512) = (1089)*(131072) = 142,737,408
Where as for cubic chucks we can use the spherical formula which turns out to be:
((4/3)pi*(RenderDistance+.5)^3)*(16^3) = ((4/3)3.14*16.5^3)*(16^3) = ((4/3)3.14*4492.125)*(4096) = (18807.03)*(4096) (again round up for the decimal) = 18808*4096 = 77,037,568 blocks
So at a WorldHeight of 512 blocks current system is 142,737,408 blocks with cubic chunks it is 77,037,568 blocks.
Now if you are looking at the "infinite" height, which is really +-30,000,000 which is 60,000,000 total blocks for the WorldHeight, the current system formula comes out to be:
((RenderDistance*2)+1 x (RenderDistance*2)+1)*(16 x 16 x WorldHeight) = (33 x 33)*(16 x 16 x 60,000,000) = (1089)*(15,360,000,000) = 16,727,040,000,000 blocks
Where as with cubic chunks which can now use the spherical render would be:
((4/3)pi*(RenderDistance+.5)^3)*(16^3) = ((4/3)3.14*16.5^3)*(16^3) = ((4/3)3.14*4492.125)*(4096) = (18807.03)*(4096) (again round up for the decimal) = 18808*4096 = 77,037,568 blocks
current system 16,727,040,000,000 blocks, cubic chunks 77,037,568 blocks. Notice the number of blocks loaded for cubic chunks did not change between 512 and "infinite".
As per the original apples to oranges comparison the current system with a height of 256 has 71,368,704 blocks loaded, a cubic chunks world with infinite height is loading 77,037,568 blocks. A difference of 5,668,864 blocks or 86.5 additional chunks which is fewer chunks than moving your render distance from 16 to 17 which is 136 more chunks. So yes you would lag a bit more going from 256 to infinite cubic chunks however your system would still lag less than with a cubic chunk render distance of 16 and then in a world in the current system with a render distance of 17.
Tested with water, it still loads the full 256 build height even with a view range of 2, but that may not mean anything.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI was JUST going to link this: http://www.minecraftforum.net/topic/2351876-snapshot-14w05a-ready-for-testing/page__st__40#entry28513388
Yeah, at least... no one in the #minecraftForge channel can confirm that this is a thing... the UI seems to make it LOOK like that though...
We think Minecraft is just showing that it renders stuff on a 16x16x16 block basis, and the debug screen helps them with that, but it's not actually using a 16x16x16 chunk system... especially because the save format didn't change... and the worlds are still backwards compatible...
Who knows... If anything, it's most likely a small front end change that could improve some performance... it's not a full 3-d chunk implementation.
Just because Infinite Height is possible, DOES NOT mean that a converted 256 height world will start generating chunks above and below the current world. A converted 256 world is still a 256 world. In order to get an infinite height world, you will have to generate a NEW world. It will be available at world creation only, as stated in the OP.
Here's some graphics to help you.
256 Height world:
512 Height world:
Infinite Height
Try this: (Red is Height map)
My Favorite Texture Pack is OVO's Rustic Pack:
No
There are no 512 height worlds with the Anvil format
Also, think about DIFFERENT WORLDS. In some worlds it will load less with the current format than others with infinite height. That's relevant.
also you should check out Tall Worlds
I'm certain Petsquirrel understands that. It's a hypothetical example showing the full advantage of the efficiency of cubic chunks.
I mean an infinitet height Anvil world is practically impossible so what's the point of showing it? To demonstrate the obvious advantage of cubic chunks, that cubic chunks has an upper limit on chunk loading lag regardless of word height. In anvil chunks, the taller the world, the laggier it gets. Ad infinitum.
If you're comparing traditional anvil format to infinite world cubic chunks, then OF COURSE infinite world cubic chunks will lag somewhat more (18,816 blocks vs 13,684 blocks). But there is really no point of comparing those two because the infinite height is just a thing that cubic chunks makes possible. It is not a core feature.
Uh, I'm not sure what you're getting at here. Are you talking about differences in terrain generation in different worlds? (i.e. two worlds of the same format with different seeds) Then yes, clearly the generated terrain will have an effect, air chunks are very quick to load, I don't see how that has any bearing on the current discussion though.
also you should check out Tall Worlds
I want to point out that the current system loads chunks in a SQUARE, not a cylinder; this is easy to prove by creating a new world, then quitting without moving and using a mapping utility to look at the world; what you will see is a square. Or use Optifine to turn fog off and fly up and look down - again, a square; fog simply gives the impression that the world is round (this also means chunks in the corners are wasted since the distance to a corner is 1.414 times greater than the distance to a side, or the fully obscured fog distance; fog is also just an overlay that has no effect on rendering load).
This also means the difference between the current format and cubic chunks will be less since the cylinders you show have less volume than a rectangular prism of the same dimensions (to be exact, 78.5% of the volume/chunks loaded).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI personnaly think this a good idea.
Let's improve it a bit:
People always assume that "light calculation" should come after terrain generation.
We can reverse this thinking and perform "light generation" before terrain
Choose a chunk (seed-randomly, "biomes", ...) to be first loaded in a "free" chunk column. (only needed for spawn, once a player is spawned, use traditional chunk loading)
Decide (seed-randomly, biomes...) what light should be for each 16*16 columns ("lit" or "unlit") in that chunk .[Light generation]
Set the chunk column as not "free".
Generate above chunks accordingly. (nothing if light should be received, "something" =continue "light generation" above, till reaching the "lit" flag, or the limit of current chunk generation, if it shouldn't). [Terrain generation]
Light-generate below chunks accordingly. ("unlit" state continue downward endlessly, while "lit" can be recomputed, till reaching "unlit" space)
World generation is now done, and all lights are already accurate, even if above chunks are not generated yet, because they will obey it, instead of changing it.
Known costs: Need to keep the data of the highest and lowest block generated light, to continue generating above and below, respectively. Can be optimised by using a flag when all columns in a chunk are in the same state.
Light updates (when players place/break blocks) should be done, like someone else on this thread suggested, at a defined vertical speed.
Preferably in separated threads for each column in each loaded chunk.
You also need to save the light data in the world, to avoid costly updates when reloading a world.
Let me know if you find any issue with that solution.