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
When you enter a new chunk-column, it would generate a chunk layer at y=128 and then generate downward until all sunlight columns have found an end at a block (the layer at which initial chunks are generated at can be changed by world generators that generate stuff higher up). The Y-value of each block-column is recorded in a "heightmap" stored per 3DRegion-column. Sunlight is then calculated normally with every block above this terrain level calculation as a full light source. When players break or place blocks exposed to the heightmap (like on the surface), the column's height value is moved and calculated up/down depending if a block is placed or broken, which does in-fact means light above initial chunk generation height is able to be calculated properly. This could lag for extreme heights, which is why a speed limit could be set for light calculation (10 chunks/tick max?).
For your example, when you walk into that cave the chunks above you at the surface are generated. The game does the heightmap calculations and realizes you are below the surface "heightmap", therefore there cannot be any sunlight coming from above your loaded area in the cave, and local lights are the only light sources.
As for the sun rendering, this issue happens in Minecraft currently as it is and is therefore not an issue with this suggestion. You can be at y=65 with a layer of stone at the height limit at y=256, if the stone is outside your draw distance it is not rendered and you can see the sky.
We don't really even have a (fully) working version out yet, underground biomes come second.
Because it does not fulfill the requirement of working no matter what situation occurs and not relying on arbitrary y-positions as sunlight start.
Not necessarily. If enough people are asking for this, they should add it. We know it works, we just don't have the proof-of-concept mod ready yet. The good people at Mojang write code for Minecraft for a living, if they would apply their considerable skills to implementing this, I'm sure it would be done in under a month.
Due to the developer for the Pocket Edition expressing his interest in this, I expect we could possibly see this on mobile devices before we see it on the PC Edition.
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.
Edit: Sorry my post is mixed with 2nd posted person
http://www.minecraftforum.net/forums/mapping-and-modding/maps/2340039-city-map-merriston-v1-airport-pc-map-mcpe-map-in
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNope... you aren't paying for it, so consumers can't demand content.
Modders can only add content when they have time, and it makes sense to...
In this case, implementing biomes will be ridden with new bugs introduced from using the system from the first time... Why try and implement biomes when you have known issues that need to be solved first.
Mojang won't move to new content, like 3-d chunks, or in my experience colored glass and light, unless they can fix all of the bugs that it will introduce up front (That they know about at least)
Mojang wants to release a beautiful and complete product, and they do their best to release content that won't expose existing bugs, or make them seem worse. Releasing content that has known issues and makes Minecraft look worse will cause them to lose business. In this case, 3-d chunks will have some severe aestethic issues, and they are always going to remain reluctant until they start looking a whole lot better.
That's why Biomes won't be worked on. There are bugs
Those need to be fixed and implemented.
Then biomes
Everyone demands content, and when a suggestion makes sense and fits into the overall style of the game, they occasionally implement it. Witch Huts, completely layered Skins, Colored Glass, Ender Chests, and Horses are only a few examples. I'm not saying they must add it to the game. I'm saying they try to add things people who play the game actually want.
I'm saying the community has a strong influence on the future features of the game. And many people in the community want this added to Minecraft. It doesn't have to influence the style of the game. It can be implemented without affecting the terrain generation or build height limit. It could be added to only change the Chunks, (Which I'm sure we agree is ridiculous,) so it wouldn't have any noticeable effect on the game, other than the increased performance. It's also irrefutably beneficial because it increases performance. So there is no reason to not implement it, except perhaps there are more important things to put in the game. (Perhaps colored light.
I have to disagree with that. They release a snapshot every week for several weeks before a major update. These snapshots are filled with game-crashing bugs and glitches. It doesn't make the game look worse, it increases their popularity because they actively use the community to help solve problems. After they determine that a major update will be 99% bug-free, they publish it.
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.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAhh, yes! The snapshots are a great point! While, I understand the enthusiasm behind chunks... the big deal is the scale of the change.
Think about the big amount of rendering bugs that came about when Minecraft released the colored glass fix. I'd argue that the AO fix was quite small compared to a change as monumental as cubic chunks. It's something that Mojang is going to be quite hesitant to adopt, simply because of the size of the change.
This also ties into the fact that it still has this unsolved sunlight issue... I'd argue that the currently listed "work-arounds" aren't Mojang quality yet. Maybe there's something out there I haven't heard of yet, but I think Mojang want to have a definite plan before they just implement and hope they can fix the bugs later.
This is why the dev's have been working hard on the implementation, not the biomes. They need to work on the different ideas and get the large unsolved bugs out. As eager as we are for the cool stuff, we have to let everything sort itself out :3
I think that Mojang could solve all the issues facing Cubic Chunks fairly quickly. They are "professionals," after all. Like I said, they write code for Minecraft for a living. I believe everyone we've had working on a proof-of-concept mod (Barteks2x, and possibly Kovu,) have been hampered by other things outside the modding process. Mojang would not have nearly as much distraction.
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.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumDistractions, yes. Mojang won't have many of those. But I think the issue here is that noone knows HOW to fix this sunlight issue. If someone told Kovu, or Barteks2x how to solve it, then they probably could implement the change rather quickly. Mojang could probably add the change even faster. There are a lot of talented developers around, but the issue isn't writing code, it's designing the solution. The problem has yet to be solved elegantly, which needs to happen before someone can code it in! The two solutions thusfar, are to 1. Brute force load and check chunks above the player, or 2.) Start the sunlight at about 128, and let it fall like gravity until it hits stuff.... (another kind of brute force attempt)
I think I speak for most of the developers when I say that "we're looking for a better solution" Something new, and outside of the box. And this is where discussion is most helpful. Think about ideas, suggestions, and crazy ways you could try and keep track of the sunlight! The moment we find something that works, or sounds reasonable, It'll be released soon enough!
We do have a solution, and it hasnt been explained to the thread yet. From what I know, it involves range trees, and those are the only words I remember.
But it was an idea bartesx2x created, so it was never in the comments.
Actually, it was in the comments, but just a bit buried.
Here you go:
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumScenario 1: You create a new world and are sitting at y = 70. The seed you have generated spawned a HUGE floating island at y = 275,214,315 blocks above you, that is large enough to block out the sunlight.
Is this implying that a binary search up could somehow detect this issue? It would require generating all of the chunks above the player... which doesn't sound like an easy thing to do...
Instead, it sounds like it solves this scenario
Scenario 2: You create and explore a huge new world. At the start, the spawn is lit up from the sun, because your game doesn't know about the island above you! Upon exploring near y = 275,214,315, you notice a HUGE floating island, and the game now knows to render anything below that as "blocked from the sun". Later, on, you unload the chunks, and walk back underneath the floating island, back to spawn. In that case, your client can figure out that it's supposed to be dark because you can binary search the chunks above you until you find out where the sunlight's supposed to be.
That works... although I don't understand why you wouldn't just hold all of those values directly in the SkyBlock array...
It sounds like, from the limited description I've read, that the calculation will only take place if the chunks above have been generated. If the chunks above are missing, then it goes ahead and loads them?!?
More explanation is necessary.
A member of Mojang has actually given some suggestions for solving the light issue. From page 189:
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.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumA height map makes a decent solution (at the expense of RAM) but leaves the problem with how to compute and fill it in real time, unless you're fine with blocks simply starting lit up, and then having them darken once something loads above them...
Please be aware, I am not attacking the concept, or saying it's doomed to fail or ANYTHING... In fact, I am in complete support of this topic and idea (which is why I'm posting and asking questions)
I'm trying to make the point that this sunlight issue needs to be thought out completely before anything moves forward. From what I've read, there isn't a complete solution yet.
Rather than generate the whole 256 tall chunk and and render it, it loads the Y axis based on your view distance. So if is on 3 chunks, it will load 27 smaller chunks rather than 3 * 256 blocks.
There are other ways it decreases lag, but you do need to read the OP. It explains everything much better than us commenters will.
also you should check out Tall Worlds
By "seriously lag chunk generation", in a mod I made, chunk generation (initial world creation) time is far longer when caves are included (otherwise, only slightly longer despite triple the blocks to generate), albeit I increased the gen-range to +/-12 chunks (25x25, 625 chunks) to accommodate bigger caves and ravines; in particularity cave-dense areas, flying in Creative will actually freeze the server and stop new chunks from loading until it catches up (i.e. you fly off the edge of the world). Even for vanilla cave generation/range, it would probably be even worse with cubic chunks; the OP also mentions this as being an issue.
Of course, changing to a better algorithm, preferably one that doesn't have to check such a big range of chunks, or follow each cave through its entire length, would help a lot (it is possible to reduce the range, but at the expense of short caves and ravines; ravines can also get away with a shorter vertical distance, perhaps +/-3 chunks, possibly also caves as they are mainly horizontal).
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?
It's all about the shape. Cubic Chunks will ALWAYS reduce the number of chunks loaded, but by even more than other people say.
I feel it needs to be said, that the calculations being used by everyone I have seen so far, have 1 fundamental flaw. They aren't comparing apples to apples. Allow me to explain:
1) Using the current chunk rendering system, chunks stretch from floor to ceiling, regardless of what that height is, causing the shape of the chunks to be loaded to be a cylinder.
2) Using the Cubic Chunks rendering system, assuming a sphere shape, will ALWAYS have 2/3 of the volume of the cylinder of the same Radius and a height equal to 2xRadius. This is simple geometry math. http://en.wikipedia.org/wiki/Sphere
Therefore, IF the height of the world, is AT LEAST your full viewing distance Up and Down, you will ALWAYS get minimum of 1/3 fewer chunks to render. If the world height is farther, you will receive ever increasing rewards the larger the world is. With this you should be able to deduce that with classic chunk rendering, theoretical infinite height is not possible as you would have this infinitely tall cylinder, but with cubic chunks, it is still the same sized sphere no matter where you are in the world.
Then why do people keep saying that at FAR/16 render distance, Cubic chunks will render MORE chunks than the current system generates of these 16 block tall mini-chunks?
Assumptions:
- WORLD A has a height of 256 - it is a converted normal vanilla world.
- View distance is set to Far/16
- To be more realistic, I will assume I am standing near the middle of a chunk, so the actual radius is closer to 16.5
Formula using Classic Chunks:
- Area of a circle (pi * r ^ 2) = 855.3 chunks loaded
- Height of a chunk is 16 "mini-chunks" = 13684.8 mini-chunks loaded
Formula using Cubic Chunks:
- Volume of a Sphere (4/3 * pi * r ^ 3) = 18816.6 mini-chunks loaded
Based upon this, it appears that cubic chunks will have more info to load - Most people stop here.
However, Here's where it gets tricky.
remember - the world is only 256 high, or 16 mini-chunks - This means that part of the sphere isn't rendered as it is outside the limits of the world.
Think about taking a 32cm diameter watermelon, and slicing some off both sides to make a slab 16cm thick with rounded sides.
Formula for calculating the volume of a sphere outside a given range limit (called a spherical Cap http://en.wikipedia....i/Spherical_cap):
- (pi * wasted height / 6)*(3 * radius of slice ^ 2 + wasted height ^ 2)
Assumption: We want to minimize this effect, so we stand at y=128
- (If you stand closer to one side, the volume outside rendering is larger up to 50% when you stand at the top or bottom of the world)
Calculations:
- wasted height therefore becomes 8 mini-chunks of height on both sides top and bottom
- radius of slice (r^2 = a^2 + b^2) = 14.4
Therefore:
- Wasted volume on ONE side = 3102.1
- subtract that twice from the volume of the sphere and you get 12612.5 remaining mini-chunks
- a SAVINGS even at FAR/16 distance of a little over 1072 mini-chunks
Conclusion:
No matter your viewing distance, you will ALWAYS experience a FPS savings as fewer chunks are loaded, by using Cubic Chunks. It CAN NEVER BE MORE than with the current chunk loading system.
IF World height is LESS than Diameter of view distance, savings will be between 1072.33 and HALF the volume of the spherical rendering distance, depending on where you stand (assuming 256 world height)
IF World height is EQUAL to the Diameter of view distance, savings will be 1/3 of volume currently rendered in the current chunk system
IF World height is MORE than the Diameter of view distance, savings will be between 1/3 of volume currently rendered and Infinity depending on actual world height.
My Favorite Texture Pack is OVO's Rustic Pack:
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumi see how that would work. ya that would save ALOT of cpu power. they need to bring this back, floating islands blocking the sun out would be a drag: / i wonder how thats going to get delt with.