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
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNo need to apologize. Discuss! Keep things going! These kinds of questions are awesome, as they help make light of a potential problem. Then, others can come forth and explain what's wrong, and a solution can ultimately be reached!
Yup.
I've run a few servers in the past that were small and just for a few friends. I had to keep adding mods or changing packs entirely to keep interest up. Once everyone got to the ends of tech trees and such like in buildcraft or thaumcraft they usually got bored. Mystcraft held interest for quite a long time but after so many "stuff explodes, ur ded lawl" worlds they lost interest again.
I feel cubic chunks would not only make a quality experience more accessible to players, but also introduce a higher capicity for entertainment in terms of unleashing building limits, eliminating the feeling of vertical enclosure entirely, and opening the door for new kinds of mods to be made or adapted. I'm already thinking of all the ways I could create a more interesting and self-sustaining server with the possibilities this would allow for.
Perhaps some of your followers who have YouTube channels and some extra time could take the working versions of Robinton's cubic chunks and make more videos to spread around talking about the benefits or maybe even have a Let's Play using cubic chunks. (I think I saw someone suggest a Let's Play earlier.) That would definitely keep the idea of cubic chunks fresh and in the spotlight. (Moreso than what being the top suggestion thread will get you.) I understand, however, it could be difficult getting people interested in something using old content and no promise of an up-to-date model.
I wish you all the best in convincing Mojang to implement this superior method for chunk loading. I know it's a long way off from seeing any potential fruits of your labor, and even longer off from considering mod support or all the cool things to do in the game but you've shown incredible attitude and optimism this far so keep at it! Someone's bound to throw y'all a nice bone sooner or later.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI think its funny how some people here think that packet corruption can occurr in a game which uses TCP as underlying Networking-Layer. TCP eliminates all corruption of packets, at the cost of higher latency and bandwidth. If a Packet gets corrupted, it is sent again by TCP.
The 'Packets' that Minecraft uses (and that you think you are talking about) are encoded as byte-fields (think C++ structs) inside a TCP-Stream. It's pretty much the UDP-Protocol implemented on top of the TCP-Protocol.
So, No:
The 'Packets' that Minecraft is handling cannot get corrupted in any way, and if they DO get corrupted (cances are near zero), the entire TCP-Stream crashes either because the Java Networking-Layer crashes, the stream-encryption encounters a invalid sequence of information, or Minecraft's Packet-Reader encounters invalid information (which causes a 'Bad Packet' exception).
Sources: Minecraft sourcecode, personal knowledge, programming forums, Stack-Overflow and Wikipedia.
And if you still think that Minecraft 'Packets' can get corrupted, you just don't know how things.
Don't talk about things you don't really know anything about.
- Longor1996
PS: If you think I am wrong, write me a PM, this Thread shall stay on-topic, please!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI don't think you're wrong at all. I was mistaken.
Clearly I have stepped out of line with some of my comments.
To clarify my misunderstanding then, what happens when Clients walk around and discover an unloaded chunk? I thought that was explained by packet loss, but now I have to reconsider. Do chunks disappear from time to time? Is this another queueing issue somewhere else in the code? Will cubic chunks experience this same problem, and if so, can it be fixed? Hopefully you can understand why I thought it was easily explained with packet loss ._.
I guess I'm simply representing the addage that "Simple minds seek simple answers".
Whatever the case (and while still staying on topic of cubic chunk implementation) Other points still should be valid. The current packet system may experience a performance drop, if packets were to only hold one cubit versus 16. This could imply that chunks may simply need to be "reshaped", and not completely removed. If not, then it would need to be restructured in a manner that doesn't incur more network traffic than what's necessary!
That better?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAbout Chunk-Corruption:
Chunk corruption happens when a Chunk get's unloaded and loaded into the system at the same time, as far as I know.
About missing Chunks:
I don't know exactly why it happens, but its probably the same reason as with the chunk-corruption,but in between the server/client model. Having implemented my own voxel-engine, I know that keeping track which (-cubical-) chunks are in the clients memory and which are not. A possible optimization would be to temporary store chunks on the clients hardrive, but that sadly opens the door to a hell of a lot of cheating possibilities.
About the sending of chunks:
Sending multiple cubical chunks in batches is (mostly) a very good idea. The less individual Minecarft-'Packets' you send trough the network, the better. Ignoring that, the most important thing is to compress the chunks as good as possible. One good way to compress the chunks is to compress the block-data in separate fields, so you got 'Block-Data', 'Block-DataExt', 'Block-Light' and 'Block-SkyLight' as separate fields which can then get compressed much better.
Overall:
- The less data we send, the better.
- The smaller the data we send, the better.
- The better we can predict whats important to be sent, the better.
- The better we can do occlusion-culling for the chunks which are going to get sent from the server to the client, the better. (Right now there is only 'distance-culling')
I got the feeling I explained something wrong, so please take everything I wrote in this post with a grain of salt.
Have a nice day!
- Longor1996
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThere we go, that makes a lot more sense!
So, I think the ideal solution here would be not only to write packets based on a different chunk shape, but maybe it'd be possible to write 3x3x3 "reshaped chunk" packets. each packet would contain 27 cubits of information, and then we would choose to send 1 packet for 'Block-Data', one for 'Block-DataExt', one for 'Block-Light' and one for 'Block-SkyLight'.
I'm not sure if you'd need one for skylight though... wouldn't that just be the heightmap? Technically, the clients don't need to reference a heightmap in 3 dimensions. If sunlight is coming straight down, then the heightmap will simply represent where that sunlight was able to land. In that case, we might be able to fit some of that packet info somewhere else.
If we make the "chunks" smaller, (as opposed to 16 cubits from earlier) We can support a larger size in our packet (I'm hoping we could fit in 27 after compression) Then, we suffer from the fact that a client would need all 3 or 4 packets to each chunk before they could build it/display it on screen ......... but it sounds efficient, and easily integrates into a 3d cubic chunk environment.
What are the thoughts about breaking up the 16 cubit chunk and packet system into larger area chunks that'd be comprised of 2 or 3 packets? Working with 3x3x3 cubes of 16x16x16 cubits would address most of these issues, as long as we don't shoot ourselves in the foot with network chatter, and reliance on all of those subpackets to build a chunk our side.
also you should check out Tall Worlds
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe single 'Block-XXX'-fields have to be sent all at once, or you will have to deal with 'incomplete chunk handling' in the engine, which complicates lots of things.
Sending multiple chunks at once is (simplefied) a good idea, but also not.
If the size of a 'Packet' in Minecraft exceeds a certain limit, Minecraft will either crash (if WAY too big), or the connection will start to lag thanks to the way TCP works (Limit varies for all connections).
The best size for a 'Packet' is at ~4096 bytes. Any bigger and you may run into the above given issues sooner or later, mainly lag.
There is no way to estimate how big a Chunk will be after compression, but the most common sizes seem to be in the range of 200 (~smallest) to 3000 (~biggest) bytes, thus forcing us to never send more than ~4 chunks at once, or we will have a little problem (see above).
If you make the chunks themselves smaller, you will run into a much bigger problem:
GPU Memory. Unexpected? Not really, since rendering a region of 24x24x8 chunks ('estimate' for visible chunks at 'Far-View') needs just about 4.608 render-buffers (+- ~200 for translucent rendering), which is already a LOT of stuff. Now make the chunk size smaller, and you will have even more chunks and buffers to handle&render.
Splitting up chunks into regions of 1024 blocks² is already there, and is called regions. Splitting up chunks or combining them is not that good of an idea, because it complicates the handling of chunks.
So much text.
Oh well...
Have a nice day!
- Longor1996
(Sources: Decompiled Minecraft sourcecode, Stack-Overflow, programming experience)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumLeaving chunks in place though.... makes it significantly harder to scale efficiently in all directions. It sounds like you're suggesting just stacking multiple Minecraft world's on top of each other, leaving the old chunk system in place... What about reshaping what's sent back and forth already?
Instead of a chunk that's 1x16x1 cubits, maybe 2x4x2 cubits or something... (Were you already suggesting this?) I think this might help improve the situation. Obviously it would call for some low level changes in most of everything, but it might be worth it when trying to scale a world infinitely upwards and downwards.
Also, this would increase the amount of completely air filled "chunks", which would be another source of optimization to be discussed. Can we structure the system to imply that if a chunk isn't sent, then clients can safely assume that it's air?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWoopsy... little misunderstanding here.
I am not talking about stacking layers of worlds, as that would be just inefficient as hell (and worse).
Rather I am talking about if it would be a good/bad idea to send a bunch of chunks (16³!) together in a larger packet to the client.
There are some bandwidth problems, Networking issues, Minecraft 'Packet' issues, and more to this. It's too much to be explained here fully (/in detail) without breaking the text-limit of a single post (sadly).
As far as I know, there are two ways in Minecraft (I forgot which one is used currently) to send a chunk to the client.
One is 'column by column', in which each and every chunk (NOT the 16³, the 16²x256!) is sent column by column to the client, who then reassembles the columns into a full chunk.
Another is the 'extended-layer' approach, which sends the chunk (again the 16²x256 thing) in pieces of 16³ to the client, who then reassembles it into a full chunk.
I could spend the entire day describing how things work in the Minecraft-Engine... And only a hew hundres people would actually understand what I am talking about.
If anyone is wondering how I got to know so much about the internals of Minecraft, then thats probably because I wrote my own voxel-engine (5 times over because I was bored), a Minecraft-Mod (freezed currently), and I even got so far as to optimize the heck out of Minecraft so it runs on my fathers old computer (which got replaced with a better one last year), so my little brothers could play without lag for a while.
So, yeah.. I know my way around Minecraft and Voxels.
If someone in this thread has a specific (/direct) question about Minecraft internals, I can most certainly give an answer.
But please don't expect me to answer everything. I am just a human, not Google.
Have a nice day!
- Longor1996
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNot that spectacular.
I just changed the rendering pipeline to use the fastest possible ways to render something on a intengrated Intel-GPU, and cut away some things here and there.
That happened last year, and my Backup-Drive had a case of file-corruption, so I don't really know what else I did optimize away.
But I think I copied some things from OptiFine back then, like the optimized chunk-loading.
And I put in a pre-generation thing, that generated every Chunk in a radius of a 1000 blocks (+Loading Screen), so the PC didn't have to generate chunks all the time. Its not much, but it helped a lot.
Other things that I optimized are actually popping up in my head as I am writing this, but I don't think I need to write all of them down.
And all the optimization only brought the FPS from 10 to ~50. Hell... the Mod itself didn't even run on any PC other than my Father's, and on mine in Eclipse/MCP.
Nothing spectacular about it.
Have a nice day.
- Longor1996
Edit:
Just remembered: I put a the Mod AROUND Optifine. Thats what brought most of the FPS back up from 10 to 50. Blame my damn memory. Sorry if I raised hopes for more optimization in Minecraft. But hey! Optimizing the renderer for a certain Graphicscard is fun! (not)
In other news: Mojang is going to do an AMA for the PE devs, and I think this would be a good time to bring up Cubic Chunks and have tommo talk about it. Please help by upvoting my question: http://www.reddit.com/r/MCPE/comments/22lf0s/questions_for_dev_panel_on_monday_april_14/cgoo9ru . There are already 400 comments, so I doubt that my question will ever be seen unless you guys help out!
Man, all you discuss is more about code.
We looking for stuff that don't make brains explode!
You can go technical and derp out all day
But in the end you make us all want to hit the hay.
C++, Python and Java
Evil enough to wear balaclavas,
But please! Keep it chunk related
So many people see your code as hated
Every day they crank the heat
Hating on codes with every beat
But don't take it out on this suggestion,
It'll make one suffer indigestion
To read
Every baloney you wrote!
So come on both of you--don't make us goat.
...I would but that would require me to make a Reddit account...
also you should check out Tall Worlds
You do realize that most people who would have anything to do with this mod's development want to see coding discussed, correct? There are very few people who don't want to see how would work out the few issues remaining with this concept if they are at all devoted to seeing it through. Only transients and passing thread viewers would dislike seeing that they are making headway in discussing the coding of a complete overhaul of the chunk system. It's foolish to assume that the majority shares your opinion when your post is the first one in weeks saying anything remotely similar to your opinion. Mods are code, code is good.