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
Pretty sure you mean 100,000 blocks on that last one, and 90% of the atmosphere is below 16,000m.
"Love as a principle and order as the basis; progress as the goal"
I introduced an idea to solve this problem a few pages back in this thread. Maybe I'll make some graphics to explain it eventually.
The Opacity Map
The opacity map seeks to provide a way not just to get a SL value for the topmost block in the current loaded chunks, but to render the sky in such a way that isn't completely broken.
The opacity map divides the entire minecraft world into 12x12x12 sections of chunks. Each chunk is given a 0-15 value representing the amount of sunlight that it will block. A value of 0 means that the chunk is completely transparent. A value of 15 means that it completely blocks sunlight. Each 12x12x12 section is then grouped into a 4x4x4 section, which is recursively grouped into larger 4x4x4 sections.
Sunlight
The amount of sunlight that reaches each column of each top-level loaded chunk is determined by starting with 15 and subtracting the opacity level of each section (or chunks, for the bottom section) above it. A single opacity 15 section or chunk will completely block sunlight. This will have the additional effect of "realisitcally" modeling light bending around small object high in the air, as well as diffuse lighting. This is not the main reason to use this idea (rendering the sky is); it's simply a bonus.
Number of Levels
We can have as many levels as we like, but for the purposes of analyzing performance we can set an upper bound:
The "farlands distance" start at about x or z = +/-12,000,000. After this point, performance is no longer a concern, since the game already begins having severe performance problems. This means that we need to cover a range of 32,000,000 blocks with our opacity map. 32,000,000 blocks means 2,000,000 chunks. Since 12x4^9 = 3,145,728, we can consider 9 levels of recursion as our max. As we will see later, all 9 levels of recursion combined require less memory than our bottom 12x12x12 sections of chunks, so adding higher levels of recursion (quadrupling our range each time) won't change much anyway.
The Opacity of a Chunk or Section
The opacity of a single chunk would be the average of the opacity of every column in that chunk. The opacity of every column would be sum of the opacity of every block in that column, capping at 15. Similarly, the opacity of a single section would be the average of each column in that section. Each column would be the sum of each section in that column.
Since the player isn't going to sit still in the middle of a single section, multiple ones will need to be loaded at once. The section size will dictate how many we must load in a worst-case scenario. Since the maximum radius of loaded chunks is 15, we'll use that as a basis.In order to ensure that no more than 8 sections would be loaded at once, we would need 31x31x31 size sections. At that size, a player in the exact middle would only need one section, and at a corner would only need 8.
If we go any lower than that, a player standing in the exact middle of a section would need a section loaded on either side of the section he's currently in, forming a 3x3x3 grid of sections, or 27 sections. The lowest we can go without need multiple sections on either side is 11, but 11 is a bit of an oddball number to be using, so we'll go with 12 instead.
31x31x31x8 = 238,328
12x12x12x27 = 46,656
This makes 12 the best number for our sections size from an optimization standpoint. Depending on how the rest of the chunk loading system is designed, 16 may be a more convenient number to use.
16x16x16x27 = 110,592
While less optimal than 12, it's still only using 55kb, which may easily make going for less programing complexity more ideal.
A value of 2 would require less memory and CPU power, but would give us poor resolution when it comes time to render the sky. At a section size of 4, the 12x12x12 chunk bottom levels still dominate the memory usage.
Since it's easier to see when using a section size of two, I've made the first diagram showing the principle with that size. Each section has an opacity value. A bottom-level section needs to be loaded if it contains a corresponding loaded chunk, since any loaded chunk may be chaning its value (even if the player isn't in that chunk). Each heigher level section containing one of those sections is loaded, and so on, until the top level is reached.
Here's the sections with a size of four.
This demonstrates how the sky will be rendered. Each red line represents a polygon that will be rendered as a black quad with a transparency depending on the opacity level of the section.
Performance
The opacity map would require very little memory and CPU use, and use a reasonable number of polygons.
Memory:
Each 0-15 number will require 4 bits to store, or half of a byte. The amount of memory needed to store the opacity map would be:
(12x12x12x27 + 4x4x4x8x9)/2 = 25,632 bytes.
CPU:
Updating the opacity map, in a worst-case scenario, would mean having to calculate the bottom-section opacity value, then update the values all the way up to the top level. The least efficient way to do this could be approximated by counting the number of values we have to add together. For the bottom level, it would be 12x12x12 values. For each higher level, it would be 4x4x4 values.
12x12x12 + 4x4x4x9 = 2,304 additions.
For a worst-case scenario that would occur very rarely (There are a ton of optimizations that would let you stop counting much earlier), this is quite good. The most important point is that nothing that is not currently loaded into memory needs to be checked during the update.
GPU:
How many polygons do we need? Since we won't be rendering sections that are level with the one that we're in, the usual number will be 4x4x3 (the number of subsections in each section) times four (the number of sections loaded if we're at a corner) times 2 (the number of polygons for each quad) times the number of levels we're rendering.
4x4x3x4x9 = 3456. For reference, the surface of a single flat chunk would be 512 polygons. Master Chief in the first Halo game was about 2,000 polygons. I'd say that this is a non-negligible, but reasonable, number of polys to be rendering. In addition, since most of these will not change unless the player teleports a great distance away, most of them could be complied into a single image to rendered onto the sky.
Conclusion:
This method is marginally more complicated than the height map (You're basically using three dimensional arrays instead of one dimensional ones), but would still be very straightforward to implement and has a low to negligible performance cost, even unoptimized.
Meanwhile, it solves several problems that the height map doesn't, including the show-stopping problem of rendering the sky correctly.
No, but it does create a problem that needs to be solved.
That definition is way too inclusive. There's no air out that far. The ISS orbits at about 350km, and low earth orbit is about half that. If we go with 10,000km, then the only time we've ever escaped the Earth's atmosphere is when we went to the moon.
It creates a problem with current sunlight calculation, which I've spent a very large portion of the main post detailing a system that results in sunlight that almost perfectly mimics the way sunlight works now(In result, not process). There is absolutely no reason that the system needs to be complicated so much further just so you can have a small visual effect.
If it's really so much of an issue that the effect is not there, someone will make a mod for it. Just like the BetterGrass/BetterSnow mod, just like the Dynamic Shadows shader, and so much more in terms of mods that accomplish minimal effects.
If this is what you want your Minecraft to be,
Then mod for it.
But this is a suggestion dealing with, and only with, Cubic Chunks. I will restate that the only reason the portion dealing with lighting is there, is that without the new system, a way of telling if something is exposed to the sky is impossible.
Occluding the sky is NOT an issue because it does not impact gameplay.
No, there's a real issue here:
How do you render the sky? What happens when the player mouses up to look at the sky? What do they see? Do you just render it all as blue sky, even if there's a dome overhead just out of loaded chunk range? Do you just render the heightmap, even though it would give the players the impression that there are objects much closer to the ground than there really are? Giving the players an actual idea what is overhead is a legitimate gameplay concern. It doesn't need to be fancy, but we do need a functional way to represent the world.
Right now, this isn't a problem, because there can't be anything in the sky that isn't part of a loaded chunk. With cubic chunks, it will be a problem.
What if there is something above you? What if there's one block in an otherwise clear sky 10,000 blocks up? Do you render it as if it was just out of loaded chunk range? Do you just have random, unmoving black squares covering the sky, making it look like there's a large object high up in the sky when it's really just a few blocks? What about the parts of the sky that aren't part of the loaded height map? Think about how much of the sky you're actually seeing; it's more than what has chunks loaded underneath it.
Do you really need to see something above you that is that far away? I'm sure I wouldn't. If you were up on the surface, and there was a giant platform above you that was unloaded, just don't see it. You don't need to. If you needed to know that it was up there, you probably would know where it was, just go check. If whoever built it there didn't want you to know it was there, then that problem is solved for them. It doesn't really harm that much not to see something above you that's far enough away not to be seen by this chunk system.
'Tavi be beautiful...
So you want there to be clear blue sky overhead when you're deep underground because a cavern is tall enough so that the ceiling isn't park of a loaded chunk?
Maybe with the help of tutorials you could make a mod.
Or e-mail notch at his email
E-Mail: [email protected]
Just an idea!
First of all, the sky color changes according to depth.
Second of all, this problem already exists with giant walls, because the sky is a dome. It's not an issue at all with the system to have black sky visible underground in gigantic caverns too big to see the top, it's a "problem" with the sky rendering in general.
We don't need extra, unneeded processes associated with this suggestion because we want no lag increase, and it's close enough as is. If this gets implemented, by all means, go ahead and suggest the sky rendering be revamped, but stop trying to add it to this.
Notch doesn't work with Minecraft anymore. I don't need to be told how to contact Mojang, just possibly need help in the venue I choose.
Why are you even bothering with the height map then? Just assume that you've always got sky above y=64, no sky below that, and call it a day.
You've got a system that only works with the current 128-0 paradigm of terrain generation. While changing terrain generation might not be part of this suggestion, creating a system that still works when you change terrain generation is important. We need a system that actually lets deep valleys be possible, not one that gives them a black sky because the lighting system wasn't thought through.
If you're looking to prevent people from having reasons to object to adding cubic chunks, having solutions for as many problems as possible is important.
Also, fun fact: my system could actually also render large walls in the distance as well.
When will Minecraft stop updating? When pigs fly over the frozen plains of hell, twice in a blue moon, while Taylor Swift sings a song called, "Maybe I'm the Problem".