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
This NBT tag contains the hex values "3F 00 00 00 3F 00 00 00 3F 00 00 00 3F 00 00 00" repeated for 1024 lines. This tag appears to have the same value for every chunk I check.
also you should check out Tall Worlds
That is nothing new:
As far as I can tell, it has been present ever since the Anvil file format was introduced in 1.2; here's a look at a world started in 1.5.1/played through 1.6.2:
Of more interest are the new things added in 1.7, the lightPopulated and V tags, not present in worlds(chunks) created in 1.6.4 and earlier, but I'm sure they have nothing to do with Cubic Chunks; no idea what the V tag is but LightPopulated is likely a flag to indicate that light levels were updated (probably to improve performance so the game doesn't have to recheck), similar to TerrainPopulated (in your case the chunk hasn't been populated yet, with only basic terrain and caves).
ETA: I just created a world in 1.2.1 and the HeightMap tag was present, so it is part of the basic Anvil file format, maybe even used in MCRegion (Wiki doesn't say).
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?
Unless you want to play with it before v1.0.0, in which case look for Robinton's mods.
also you should check out Tall Worlds
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumTo start: YES! Servers would have enough information to selectively send less data. That's just how the breakdown works.
This won't improve the interaction between the server->client though. While it's hard to imagine at first (I had to go talk this over with all my friends in networking) Less data does not always mean better performance.
Servers send data to clients in packets. No surprise there. Turns out, that in networking, you hate packets. They're always a bother. They get lost in the internet, they move slowly from place to place... packets just generally ruin your day. (please laugh at the mild sarcasm) With that in mind, we want to send as few packets as possible. but, we also want to send all of the data from the server to the client... which means that we can't simply just have 0 packets... So, the reality is that we find out how large we can make a packet, and chock it as full of as much data was we can. We'd even compress data before putting it into the packet (to make it a little smaller), and then send it out to the clients in hopes that we don't have to do it again!.
So, if this data is of critical performance (and it is) then we want to send as few packets as possible, but for every packet, we'd better get our money's worth.
The Chunk System does this:
Minecraft actually has a decent amount of it's internal storage broken up into cubits. (16x16x16 cubes) From my direct experience, I can tell you that light data is stored per cubit, along with all block data. It's mostly broken up into cubits, then Minecraft went ahead and decided to stack 16 cubits on top of each other to a make a chunk. When sending packets, Minecraft will pick one chunk, null out empty cubits, and stack 16 (or less) cubits all on top of each other (this fills the packet). That stack is then compressed, and then shipped out to the client for them to decompress it...
Radius = 5
Chunks in cylinder of radius 5: 61 chunks = 976 cubits
Cubits in sphere of radius 5: ~523 cubits
The all important question:
"Is it better to send 61 compressed lumps of data, each containing 16 cubits, or is it better to send up to, but most likely less than 523 lumps of data, each containing one cubit. In both cases, empty cubits are skipped, making the 61 compressed lumps smaller, and removing close to half of the cubits. Packets receive equal treatment, including compression."
I posed this question to my friends in networking. Turns out, they sided with the vanilla method on this one. When posed this sort of problem, the immediate and first reaction is to always group up and send one giant lump of data, versus individual packets. Network communications consistently work better this way. So with this in mind, we'd want to send as much data as the packet can hold.. which suspiciously happens to be about one chunk, or 16 cubits stacked on top of each other. If you clobber the chunk system in favor of cubic chunks, you experience a drop in performance from turning that 1 packet into 16 (or 8 even, if you choose to neglect empty chunks... 1 compressed chunk is still better than 8, a small test confirmed this in my light mod)
So, if you move to cubic chunks, you are more than welcome to, but on the networking side of things. You need to group your cubits into stacks and send them as packets...
So, modularizing this whole system is still an amazing and impressive goal, but you won't experience massive increases in world loading and performance related to the server->client relationship. Turns out, that's basically optimized already. At best, you could selectively send less data per "stack of cubits" but now all your trading off is data size versus pre-processing. A marginal improvement when you're still sending the same number of packets.
But at least it won't make it worse!
So that's good.
also you should check out Tall Worlds
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSupport
Question - how come everybody assumes that the current system loads chunks in a cylinder (this isn't the first post I've seen that claims chunks currently load in a cylinder)? If you use Optifine to disable fog (or use Far on 1.6.4, which is actually 10 chunks due to the internal server, but fog still moves out to 16 chunks) it is clear that chunks load in a square; for example, same for when looking at a world in a mapping utility; generated chunks are square regions. True, the game renders chunks starting from your position, which does initially assume a cylindrical shape but when all loaded chunks are in a square.
Also, when calculating how many chunks are loaded under the current system you must multiply render distance by two, as expected, but also add one since the chunk you are in doesn't count towards the render distance. Thus, a render distance of 5 loads (5 x 2 + 1) ^ 2 = 121 chunks, double your assumption, so reducing the difference you calculated by a factor of two. Similarly, this is why 1.6.4 and below always report the MultiplayerChunkCache as 441; (10 x 2 + 1) ^ 2; in singleplayer.
Also, the game can combine chunks (cubits) to improve network performance; I see no reason why this can't be done; just send chunks in packets of 16 with x, y, z coordinates for each chunk, the last packet may have less than 16 chunks.
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 PremiumGood catch on the square versus cylinder, so we can run the comparison on the new numbers:
Radius = 5
Chunks in rectangle of radius 5:
((5*2) + 1) ^ 2
121 chunks = 1936 cubits
Cubits in sphere of radius 5:
(4/3)*(3.141592653)*(5 + 1)^3
~905 cubits
But aside from the number semantic, you still arrive at the ultimate point I was trying to make.
We'll have to continue to put 16 cubits into a packet, and then ship it out. The old system stored the X and Z of a chunk in one packet, and then when you pulled data out of the packet, Y started at 0, and continued to 15. This meant that getting a packet allowed an entire vertical section to be loaded at once in a very orderly fashion.
If you want to suggest that we might break that up, and let packets come in willy nilly, that might work. By adding in the each cubit's x,y, and z into the stack of cubits, you'd be able to theoretically send and receive data corresponding to exact cubits.
Edit: I'm clearly wrong with the comments that follow. Content left for context, but the spoiler contains my ramblings on a faulty premise.
But sending this critical information, specifically the x,y, and z coordinated of every cubit raises another minor alarm bell when you consider packet loss and transfer. What happens when a packet got "smooshed" or "corrupted" ever so slightly? (or maybe it didn't arrive at all) You're cubits that were botched now have to be dealt with in game. The most common approach, (and what makes the most sense to me) is to simply not render the missing/corrupted cubit, and then not allow anyone inside...
Does this sound a bit familiar?
Vanilla does this to!
But vanilla is better in this example:
Both systems have this problem. When a packet get's messed with, programs usually have to call into question the entire validity of the packet. It is usually discarded, and then clients have to sit and wait and hope the server sends them another one soon. (walking near unloaded chunks can cause the server to send you that packet again, among other conditions)
So why would vanilla be better than cubic?
Think about what's missing. In vanilla, entire column is missing. Does the server know what their clients are missing? Nope. Should they? That's an entirely different point of discussion.
So, the server may know that there's an issue if the client walks into the unloaded chunk (because the server sees the client freaking out in terrain that clearly exists) So the solution is to resend the ENTIRE column. Otherwise, clients just wait around until that chunk packet comes in again.
Because an entire column was missing, then entire column can be fixed with (hopefully) one repeated packet!
In cubic, this gets worse:
Remember, the server doesn't know what chunks the clients ended up with... but if we sent a random array of whatever cubits we needed to send at the time, then those could all potentially be lost at one point in time. If they don't follow the same column structure, and fail to make their own structure, then we run into a myriad of problems.
Clients will have random speckles of missing cubits sprinkled around the world (say, 8 cubits didn't load). When the client walks into one cubit, then it has to be resent from the server.
The server can easily detect that a client may be having issues (like in the vanilla example) but here's the kicker. The server wouldn't know what other cubits might have had issues...
So the server might be able to send another packet to fix the missing hole, but then there still might be 7 other holes to patch later on. The server won't be able to easily fix this problem by sending only one packet.
You'd either have to create a system to resend old packets (I don't recommend doing this, because it won't upscale well) or to store cubits in a similar chunk system, maybe more fit to a cubic structure. Instead of long columns of 16 cubits, maybe it'd be good to send a 2x2x4 rectangle or something.
________________________________________________
Hopefully this makes a bit of sense. We can't abandon the idea of a chunk completely. However, it'd totally be worth changing the shape of what we think as chunks. Simply pointing out that a sphere of cubits will fit inside a rectangular prism of cubits doesn't always mean there will be performance increases. There could be! But they haven't been discussed/implemented yet!
Tl;dr: Packets..... everyone hates them, but they are completely necessary. No one's completely proven how a cubic chunk system can improve network performance, but it's still possible. There is more discussion to be had here.
If I'm misunderstanding part of your post, please tell me.
also you should check out Tall Worlds
I like some aspects of this but I dislike many others. Infinite horizontal ability isn't something I want. Have a set top and bottom is a constraint that is accepted and rarely seen as a limit.
also as others have said how does the game figure out light sources without loading chunks the possible light sources are in. On top of what others have said "natural light" is one of the reasons chunks are top to bottom of the world. Not to mention mobs, water, lava, redstone, etc. I know the OP talked about this but didn't give any way as to now the game would actually (not theoretically) handle unloaded components of the game. Creating the background processes to keep all that going even when unloaded would remove many performance gains one would get.
Also without testing their is no real way to test that this will increase frame rates or reduce lag. The amount of extra code needed to implement this would more than likely double the existing code which would make the game overall more demanding on machines. Also completely rethinking the way worlds generate and blocks are shown would more than likely cause a top to bottom update of the game. Basically causing a complete reset. It's a lot different than going from the original way Minecraft worked to now.
Interesting idea that has been thought of several times already. But nobody seems to be really into testing it. This is one of those things that sounds great in theory but implementation in a game already played by millions of people is going to be much much harder than anyone here is even thinking about.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEdit: I'm clearly wrong with the comments that follow. Content left for context, but the spoiler contains my ramblings on a faulty premise
The same problem DOES occur in vanilla... If a packet is corrupted, is lost, or dies somehow, then all of that data will appear to be missing in the Client's world.
The distinction is that the server can fix the problem easily on the vanilla system. In vanilla, one vertical stack of cubits will be missing because the packet died, and only contained one vertical section. Walking near or interacting with the missing data will cause the server to resend one packet, which has all of the missing chunks. Once that makes it to a client, then the problem's solved!
_____________________________________________________
In a cubic chunk system, this behavior may not transfer. If a cubic packet was lost containing 16 cubits, then we have a problem on our hands. Did the packet contain random cubits all with a separate xyz location? If we lost 16 cubits from a cubic chunk packet, then there are 16 cubits missing throughout the world. This is the worst case scenario. When clients walk around, they might find a hole, causing the server to resend a packet in order to fix the hole. Because the server doesn't know what was lost, it only has enough information to send out a new packet to guarantee a fix for that one cubit. The problem is that a server might send out a packet that only fixes one hole out of 16, which would mean that a cubic chunk server may need to send out 16 packets to fix a problem, that vanilla could have fixed with one packet.
If the server sent the client a selection of 16 cubits, and they were lost, then the server will have to find a way to resend those exact chunks back that were lost. There currently is no discussion of how this will be implemented, which leaves the problem at its worst. Currently, it appears that in order to fix all 16 holes, up to 16 additional packets would have to be sent.
This is a huge setback.
We need to find a way to group cubits into groups about the same size as a packet, which will be sub-classified and sent to clients based on where they are, and their render/chunk loading distance. That way, when a packet is lost, the same packet can be sent out again, to fix all of the missing cubits in a client.
But if you watched that last sentence carefully, you'll realize I just described the old chunk system...
I suggest you read the OP, as 4 of your major points have already been addressed.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYes this would change how the world is saved, and how it's perceived. However, the perceived shape of the world isn't a physical constraint that we should limit ourselves to. If you're alarmed at the presence of an infinite plane/universe that changes your perspective in the physics, geometry, and realism of Minecraft... then we have a different opinion... not a problem per se. I mean... what about gravity?
Don't discard this idea, simply because it's a change. You have your right to an opinion, but it carries no weight in a discussion over performance, and additional capabilities. If you have a different argument, then we can discuss something.
Alrighty, the good news is that it hasn't happened yet, but you're simply stating your opinion. Most of us here have a different opinion. Again, it doesn't carry much weight in a discussion of whether this is should be implemented. Currently, there might be several optimizations that can come from a cubic chunk system, and the door is open to much larger and much more expansive biomes and worlds.
If you think that more content and optimization is a bad thing, or that cubic chunks somehow actually removes these things, only then can you say that it shouldn't be added. But for now, an opinion saying "I don't like it" doesn't mean that it shouldn't make it in the game, simply because most everyone else would appreciate more content, and a more efficient system.
Yup, this is a very good point. Of all of the discussion I've seen, the only solution would be to create a height map of all of the blocks that are on top of the world. Like a blanket of sand placed over every block. This height map would keep track of where sunlight can peak through, and the vanilla lighting engine could take it from there.
How would one maintain this lightmap? As new world is generated, or users add/remove blocks, the heightmap would have to change, but only in those instances.
This already occurs in vanilla currently, but it would have to be expanded slightly to account for the hard limits at 256 and 0. Other than that, it's not that big of a performance hit.
Code will not double. Some parts will become a little more complex. Some parts will become a little less complex.
The biggest Change: memory usage on clients drops considerably, as users would be storing cubits from the radius they're in are loaded, not a giant box...
Second biggest change: Packets made completely of air wouldn't have to be sent. Lowering network communications through efficient and logical means will improve load times, and client performance. (walking around worlds won't incur as much lag for others on lower end servers, and users might notice chunks loading faster/more efficiently)
Packets are an interesting discussion, and I can see ways of implementing (if anything) a slightly better method of data transfer compared to vanilla.
What would get slower? Not too much. Yes, there might be some more code in some places, but nothing that would change time complexity to an awful number.... out side of well.... light maps. From my experience in the lighting engine though, this could be solved and calculated just as fast as vanilla does it. You are correct in pointing out that no-one else has done this yet, but numerous informed opinions (including my own) think it's possible.
The beauty is that object oriented languages at least make this change possible. Yes, several things would need to be altered and changed, but it won't involve a complete rewrite of the entire game. You'll still have pistons, redstone, crops, sunlight, you name it. It will still be there.
I'd like to disagree, lots of people are thinking about it, including yourself! Even some Mojangsters left comments! It's not that it's impossible. It's just a really big challenge! People have made demo's already, and it's just a matter of time before mod writers figure out what's going on.
also you should check out Tall Worlds