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
-> Added banner to signature to let the world know.
As long as your view-distance is set below far, lag and RAM usage will decrease. Those who play on Extreme render might want to lower their settings a bit, or get a better computer. Here's some model size numbers from 13 pages ago:
http://www.minecraftforum.net/topic/1707097-cubic-chunks-infinite-height-reduced-lag-and-more-nearly-eight-hundred-supportersupdate-june-5th-new-faq/page__st__660#entry22389297
Pics of the models for the believers that thought it would always reduce lag:
http://www.minecraftforum.net/topic/1707097-cubic-chunks-infinite-height-reduced-lag-and-more-nearly-eight-hundred-supportersupdate-june-5th-new-faq/page__st__680#entry22405463
Um, I thought they were cubes...
As it will be in the future, it was at the birth of Man
There are only four things certain since Social Progress began.
That the Dog returns to his Vomit and the Sow returns to her Mire,
And the burnt Fool's bandaged finger goes wabbling back to the Fire;
And that after this is accomplished, and the brave new world begins
When all men are paid for existing and no man must pay for his sins,
As surely as Water will wet us, as surely as Fire will burn,
The Gods of the Copybook Headings with terror and slaughter return!
-The Gods Of The Copybook Headings, by Rudyard Kipling.
They were cubes forming a spherical block. Look at Aaron's second link.
OcD Simple Add-On!
the code that makes the bedrock is like two or three lines, its actually super easy to move/remove. and for servers the total amount of data that needs to be sent is reduced, since the total volume loaded is reduced.
I hitted the button, but the faqs did not answer my second question; why did the developers (as far as you know or researched) decide for bidimentional chunks if tridimentional ones work better? did they have a good reason for it?
And i have a third question that is not really related to this topic: Are the supports for something formal? like if you are going to show the number of supporters to the developers or something?
Due to the game running on Java, the height limit would increase, causing the limitation bugs to increase.
A.K.A, Java's maximum exceptionary is 10 trillion, and since Minecraft uses chunks, the maximum build height without any lag is probably 1000 or more.
They had this issue before. In Minecraft 1.2.3, where they were testing a huge build limit, it ended up glitching the blocks, due to the limitation doubles. That is one problem with JavaScript, due to the number doubles.
If you have no idea what I am talking about, think as it this way.
JavaScript only supports 10 trillion. If more is added the number would pretty much look this: Here are some examples:
Let's say I want to put in 20 trillion, here is what it would think you programmed:
10 trillion (10) trillion = java_lung=10=doJava
In JavaScript, infinite is pretty much impossible, unless you use a calculation method, which increases limitation doubles. Basically you would get an endless amount of trillions in the file base, and you would have to actually delete the whole entire script.
According to his blog, Notch once pondered on doing this in Infdev, but for some reason decided against it, and the decision stayed up to now.
First, Java and JavaScript are different languages. Second, this already happens with the X- and Z-axes with the "Far Land" effects (named after the quirky terrain generation occurring before Beta 1.8).
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis is going to sound mean but: Please slap yourself!
Java is not Javascript!
There is a huge difference between these two.
And the height-limit problems you are talking about (the one with number overflow) will start after ((2^31)-1) Blocks (positive/negative).
The problems the guys of mojang had with height increase was a memory problem which was caused by the chunk structure.
And the chunk structure they used was as simple as: Each chunk is 16x16 blocks horizontally, and N blocks vertically.
With cubic-chunk's, this problem won't ever happen, except someone is stupid enough to try to visit the farlands on top/bottom of the world.
So, have a nice day!
- Longor1996
PS: And don't slap yourself please, that was just a joke!
We don't know why they didn't add it in the beginning. And I think the basic idea of this thread and the reputation button is to get enough peoples attention to get Mojang's attention. It has over 800 supporters right now, when it gets to 1,000 they shouldn't be able to ignore it anymore.
As it will be in the future, it was at the birth of Man
There are only four things certain since Social Progress began.
That the Dog returns to his Vomit and the Sow returns to her Mire,
And the burnt Fool's bandaged finger goes wabbling back to the Fire;
And that after this is accomplished, and the brave new world begins
When all men are paid for existing and no man must pay for his sins,
As surely as Water will wet us, as surely as Fire will burn,
The Gods of the Copybook Headings with terror and slaughter return!
-The Gods Of The Copybook Headings, by Rudyard Kipling.
well thanks! i can see you are constantly working on answering questions so the project is not abandoned. As soon as i have more time i will download the mod and if it works then there is no reason for not having 3D chunks. I think the reason they made it 2D chunks is the simplicity of it when it comes to biomes, so the attributes of a biome can be applied to all the underground (like emeralds).
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWith cubic chunks, it's easy too.
You just have to package all cubic chunks in columns (or WorldPillar's as I like to call them).
And each of these columns contains a heightMap and a biomeMap.
It's the most effective way to store cubic-chunks. At least that's what I think.
class WorldPillar { List<Chunk> chunks; // The chunk buffer for this column int[] heightMap; // The heightMap for this column byte[] biomeMap; // The biome Map int xChunk; // The chunk coordinate X component int zChunk;// The chunk coordinate Z component int xTotal; // The total coordinate X component int zTotal;// The total coordinate Z component }That could work.
- Longor1996
Why do it per 'WorldPillar' and not just per chunk? That'd give mod authors a lot more options for biomes that could go underground/up in the sky. Just define a biome per chunk (or per part of a chunk, if that level of detail is required). It just needs to be one number (between 0-255 or, preferably, between 0-4095, I've run out of room for additional biomes in current versions of Minecraft with 100+ mods installed) for the entire chunk (with something to smooth the edges)
Thank you. I do check this thread several times a day. I don't really care about the mod, because I don't think it should just be a mod. I want it to be a official part of Minecraft.
As it will be in the future, it was at the birth of Man
There are only four things certain since Social Progress began.
That the Dog returns to his Vomit and the Sow returns to her Mire,
And the burnt Fool's bandaged finger goes wabbling back to the Fire;
And that after this is accomplished, and the brave new world begins
When all men are paid for existing and no man must pay for his sins,
As surely as Water will wet us, as surely as Fire will burn,
The Gods of the Copybook Headings with terror and slaughter return!
-The Gods Of The Copybook Headings, by Rudyard Kipling.
Chunks are packaged in 3DRegion files. Read the Data Storage section of the main post.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIve read the data storage section again.
So, how about this?
class WorldPillar { List<Region3D> regions; // The chunk buffer for this column int[] heightMap; // The heightMap for this column int xRegion; // The region coordinate X component int zRegion;// The region coordinate Z component int xChunk; // The chunk coordinate X component int zChunk;// The chunk coordinate Z component int xTotal; // The total coordinate X component int zTotal;// The total coordinate Z component } class Region3D { SomeContainer<Chunk> chunks; int xRegion; // The region coordinate X component int zRegion;// The region coordinate Z component int xChunk; // The chunk coordinate X component int zChunk;// The chunk coordinate Z component int xTotal; // The total coordinate X component int zTotal;// The total coordinate Z component }16³ chunks are stored in 3D-regions, and 3D-regions are stored inside a region-column.
The region column is just there to create less memory usage (heightMap) and faster accessing of block-data (like a infinite octree).
The regions can be stored like this:
This is just another idea on how to structure the whole thing in code.
The good thing would be, that this principle allows for either 2D- or 3D-Biomes.
You can just use whatever you think is the best.
The only thing the storage of 3D-regions as region-columns is for, is to store the heightMap only once per region-column.
It is a giant waste of memory to store the heightMap with every single region, or even worse: with every single chunk.
In the end it's just a idea on how-to-implement the whole thing!
- Longor1996