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
Not sure; they say that it is called one extra time for each vertical chunk, but what I was saying was that the actual cave generation algorithm needs to account for the vertical chunks, or a cave generating at y=100 won't be "seen" by a chunk at y=70.
That is to say, currently, in order to know that a cave cuts through the current chunk, it must go through every single chunk in a given radius, large enough to accommodate the longest caves, and execute the cave algorithm.
Here's a diagram illustrating what I am talking about:
The green square is the chunk currently being generated; the red square is the range of chunks that is being checked for nearby cave systems and the blue square is one such cave system. As you can see, a cave from that system cuts thought the current chunk - and the only way to know this is to go through each of the surrounding chunks and basically generate each cave system that is found (but only actually cut through the current chunk).
Now, this is where cubic chunks poses a problem, as I understand it - not only do you need to call the algorithm additional times for each vertical chunk (as the OP seems to say), you also need to implement a similar range-checking for vertical chunks, increasing the number of chunks that are checked from 17x17 to 17x17x17 chunks, a huge increase, which multiplies with the number of chunks being generated.
FWIW, here is the actual code that I am talking about; what I'm saying is that you need to add an additional loop for the chunk y coordinates:
/** The number of Chunks to gen-check in any given direction. */ protected int range = 8; int var6 = this.range; for (int var11 = par3 - var6; var11 <= par3 + var6; ++var11) { for (int var12 = par4 - var6; var12 <= par4 + var6; ++var12) { long var13 = (long)var11 * var7; long var15 = (long)var12 * var9; this.rand.setSeed(var13 ^ var15 ^ par2World.getSeed()); this.recursiveGenerate(par2World, var11, var12, par3, par4, par5ArrayOfByte); } }Also, this is what happens when I make the range +/- 1 chunk instead of +/- 8, to illustrate how this works:
So, you can see why you need to include a range going along the y-axis as well, unless you are somehow restricting caves to a 1 chunk-high area.
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?
I don't quite understand your fancy math, but I'm pretty sure a cylinder with limited height vs a sphere would have the sphere taking up more areas as the radius increases. http://i.imgur.com/W4A4oh9.png
Regardless, Lag will still probably be reduced at render distance 20 because of air chunks.
I think cave generation just needs an overhaul, one that doesn't involve this massive amount of checking chunks. It could also be set to not check vertically above a certain height level, therefore reducing lag for surface chunks when generating caves. You wouldn't be moving underground fast enough for this to happen usually anyway.
"After the implementation of Cubic Chunks, view distances' radii will apply to the vertical axis too. This reduces handled blocks in the cases of tiny and short render distances, and increases them in the cases of normal and far render distances. This can be optimized by utilizing a spherical render distance instead of a cubic one, which would reduce handled blocks in all distances except Far."
This RIGHT HERE somewhat answers what I said, however, I would like to state that at a distance halfway between normal and far even a sphere would lag more than the current system (ASSUMING there is the max amount of chunks loaded above and below you, on a 256 height limit this may not apply. However, infinite height seems to be a popular feature of this but what I said above may make it impractical in certain ways. At FAR render the cubic system is 33% less efficient. But like I said above, this is assuming the fullest amount of chunks are loaded above and below you. To say that this system has only pure advantages performance wise is ignorant.
I understand. The best way to improve Cubic Chunks is to discuss its problems, and from there we can create solutions.
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.
That would have to be part of a mod, besides they are meant to be different worlds entirely and not one simply below another. The End above would create shadows, and the Nether and End have different lighting systems (They look ok-ish bright at light level 0).
Wait a second... even though the cave checking would have to occur in 3 axis' with Cubic Chunks, wouldn't it not be all that laggy anyway since the chunks will be smaller? I'd bet that this process would only be slightly more laggy, it's just that as it is, it is unoptimized.
You are falling into the same trap everyone else is. IF the world height is 256, then BOTH of those volumes would look like the one on the left, except the spherical one's sides wouldn't be vertical, they'd be slightly rounded. IF the world height is tall enough for the whole sphere to be inside the world, then the one on the left would be that tall too, thereby being WAY more data. Read the conclusion of my post - it sums it all up without the math. You are comparing performance with classic chunks in a 256 tall world, with Cubic Chunks in an infinite world - apples to oranges. Regardless of the world you choose though, Classic will perform worse than Cubic in EVERY CASE in the same world.
See above. You obviously didn't read my whole post. And if you did, you didn't understand what I was explaining. As above, you are comparing performance in a 256 high world on classic chunks, with a Cubic Infinite world - in that case you are correct, however that is apples to oranges
- Classic vs Cubic in a 256 world = winner Cubic (barely on a Far render distance)
- Classic vs Cubic in an infinite world = winner Cubic. Every time.
The first part is correct - 2% more area loaded in Classic Chunks compared to Cubic Chunks at Far distance is a fair estimation.
However, the closer the view distance is to being fully contained within the world, the better performance is.
'Death_Dealer' got it right. Thanks for the handy graphics.
My Favorite Texture Pack is OVO's Rustic Pack:
So, currently, with the anvil format, which came from part of the original CC mod, the game divides chunks up into pseudo-CC, and if one of those is all air, it doesn't bother sending it for calculations, which allowed Mojang to double the build height. However, Anvil still loads those blocks, both above and below, regardless of if they're needed or not. This suggestion will greatly decrease the lag when the player is on the ground, and makes it possible for the player to build up to crazy heights without dramatically increasing the lag as they load new areas, something that RC's can't do.
Wait, if you have a view distance that's considerably greater than 256 (16 chunks) (if there is), and we get CC with the spherical loading and infinite height, wouldn't that make it technically load more blocks?
Here's a poorly made diagram that I did in Paint in about 15 minutes (I know it shouldn't have even taken that long):
The top section is with the current loading system, and the bottom is with CC and infinite height. The blue lines in the top section are the top and bottom of the world, and in both sections, the yellow circle represents the player (I know it's not perfectly centered), and the purple represents the loaded area. I made sure the length of the purple rectangle was the same as the diameter of the purple sphere. The area of the purple rectangle at the top (not including the aesthetic darker border) is 188x78 (see what I mean by poorly done?), or 14664 total pixels. The area of the circle (also not including the border) however, is ~28055 pixels. (The black line is just meant to be a border between the two).
EDIT: I just realized this is my 777th post o.e
also you should check out Tall Worlds
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumRender the height-map if it's out of the player's rendering range. It could just be solid black/dark grey blocks way up there.
That way, the sun won't show up! A little performance hit, but rendering the height-map can't be all that bad!
Thoughts?
You are essentially correct, EXCEPT you are falling for the same problem - comparing a current 256 height world, with an infinite world - these are TWO DIFFERENT SCENARIOS, and you can't compare them directly. Within EACH scenario, the calculations favor Cubic Chunks. If you made either the sphere small enough to fit between the blue lines, OR made the blue lines wide enough to fit around the sphere, THEN you'd have an accurate portrayal of an Anvil vs Cubic chunk rendering comparison. Remember Cubic Chunks DOESN'T automatically = infinite height. It CAN be used in a 256 height world.
Also, remember that a View distance of 16 = 16 up AND 16 down, so actually is double the height of a 256 world. Render distance of 8 would be comparable.
I like this explanation of the height map idea. I think the idea is exactly this, although in my head, maybe not an actual render of it (as in break a block and see something there), but more of a pseudo-render - it's enough to know it's there, and can calculate based upon it, is it sunlight, is it a shadow, but yes, calculate its position in the world for sure and use it. Maybe I'm off.
One question about the whole height map idea, maybe someone can explain to me, or figure out. If you are in a cave, sealed against the sky, it would create a dark cave. What happens if there is a small opening way up high, maybe with a block 2 or 3 blocks just below the opening - a height map wouldn't account for this scenario, and render it all dark, even though it would feel in real life like a light source.
My Favorite Texture Pack is OVO's Rustic Pack:
This is what I get for posting a quick thing while rushing off to class.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt's never been mentioned before... but it would make the world's look a little better in my opinion. The front pages claims that a constantly maintained height-map is the most probable solution, with the issue being that you have to maintain it well.... and it could result in some really funky scenarios (where things start lit up, but then later, get covered by an island that no one knew was there)
If a height-map is used, and you're back in THIS scenario again:
Except, this time, the sunlight won't be rendered, nor will you even SEE the sun!
-
View User Profile
-
View Posts
-
Send Message
Curse Premiummy idea.
Half support
Why? That would Being bad for the minecraft saved worlds. The new unactivated, activated and still activated spawn chunks system Will make lag your world (like If you uninstall a mod when you used it into your save).
But the idea is INCREDIBLE!!! I'd like it on minecraft! ^^
If there's a small opening, it's not a sealed off cave. Care to draw a diagram of what you mean?
Also, I would suggest, perhaps, make sea-level, which is currently defaulted to Y64, be Y0? That way, negatives go underground, and positives go up the sides of mountains into the air.