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
This is a great idea, Why hasn't mojang impemented this yet! I demand cubic chunks!
I have nothing here, go look somewhere else.
I think someone from Mojang said once that lighting is the biggest problem.
Yeah, that was MogMiner, two years ago. Admittedly it's a sizable problem, but we have a working prototype here. Now, I'm not saying this is evidence that Mojang needs to drop everything and make this work. Rather, those free-time coders that are interested in this, and/or want to get good volunteer work on their resumes, should continue working on this until it's in a mostly bug-free state, and let Mojang continue with their other plans and implement Cubic Chunks when it's ready.
I support this, this, and this. And this now. Also this.
Did any Mojang developer ever see that? If not, can you give a good summary/explanation of all the concepts, ready to forward it to a developer?
Mojang is already aware of cubic chunks, and has responded on occasion about it when asked:
https://twitter.com/TheMogMiner/status/475034343564652544
- sunperp
Why is this not already a thing? Not a clue.
This is literally the best suggestion on the entire forum. I really wish this was in the game. Rain would have to be revamped so it only came from, like, 128 (where the clouds are).
For the sunlight issue could one use bitmaps for each unloaded chunk? Just 32 Bytes per chunk above the loaded ones, even if the limit is a 100,000 chunks hight that's still only a few megabytes on max render distance, and if you use data saving tricks like making groups of full clear or opaque chunks be shrunk and if the chunks 100 chunks up are full opaque don't bother loading the ones above it until the player goes upwards. I'm a bit unclear but I think you get the jist?
Is this still being developed by anyone? I do a lot of creative building so it pains me that there really doesn't seem to be a solution out there currently. Does anyone know if Microsoft plans to do anything about the height limit, or are they just gonna keep adding bells and whistles?
I'd love this - if you could set vertical sizes at generation and have the terrain and ore gen scale based upon lower, upper, and skyline bounds (skyline is max Y the generator can access - upper is player-utilizeable blocklimit)
Map Project I'm Working On
That's exactly how my mod handles it - oregen is scaled and offset based on max terrain height above sea level.
Iron spawns only below sea level (0%). Coal spawns everywhere. Gold spawns only below 50% below sea level or -infinity to -50% (for vanilla, 32 blocks below). Diamond and redstone - only 75% below sea level or -infinity to -75% (48 blocks below sea level for vanilla). For lapis I still haven't fully figured out a good way to handle it so it temporarily spawns (as I remember) between -100% and -50%. And these percentages are configurable in GUI.
Cubic chunks discord server
Does the terrain have a vertical scale feature?
Map Project I'm Working On
That was the whole point of custimizing the terrain so yes. Sort of. Anyway, this is about the suggestion, and not the mod. My mod has it's own thread.
Cubic chunks discord server
Anyway, those two would be what I'd want. You know, so mountains actually felt BIG for once.
Map Project I'm Working On
If this idea were adapted, then one way of reducing lag even further would be as follows:
First, for chunks that might need to be rendered, but which are really far from any player, could be left in a de-animated state.
Second, when one of these non-animated chunks is viewed by a player, we calculate the angle (in speherical coordinates)
from the player to the center of the chunk, and round that angle to the nearest 5 degrees. We then check if the server already
has a cached image of that chunk from that angle, and if so, send it (possibly scaled down) to the player. Otherwise, we
generate (and cache) a parallel projection of the chunk from that angle. If parts of the chunk are see-through from that angle,
there will be transparent pixels in the generated image.
Third, we would generate and cache composited images of this chunk with any more distant chunks which can be seen
through the transparent pixels. This composite might *still* have transparent pixels, these would be of the sky. Time
stamps would be used to ensure that if one of those very distant blocks is being animated (because a player is in or near it),
the composite would be regenerated.
As the player moves around, these distant images will be repeatedly re-used (but scaled up or down, or moved left or right
relative to one another), and new images of any given distant chunk are only generated as the player moves five degrees
*around* the center of said chunk. Because it is distant, this regeneration is infrequent.
Players who are standing near each other would receive from the server the (mostly) same images of distant chunks -- the
images don't need to be generated once for each of them.
I don't know if that would be good. 5 degrees could look jittery and unexact. And especially: You would need to save up to 5184 images per chunk section.
On the topic of lighting.
Would it be possible to have some sort of file that stores the highest block per block in a chunk. (might not be necessary, I'm not completely sure if there would be a way to do it with out storing it, due to re-logging and all.) That way, it could make the block below the correct light level. It would probably have to be stored in hexadecimal, or possibly hexatrigesimal (because of the virtually infinite height, you would probably want a lot of compression in the file size.) When a block is placed, the game could do a quick check to see if it is the new highest block for that coordinate (x,z). If it is (and it is a opaque block that doesn't let light through), it would change the file to then have the block's y coordinate placed in the file, overwriting the previous number. (if y1 (y value of block placed) > y2 (y value of current highest block) then some code here that would change the value in the file to y1
)When a block's sky lighting is updated, it should update it's neighbors as well (only if they need to be). That way you wouldn't have a situation where a block's sky light level is incorrect.
For example:
The block in the center should have a lower sky light level than the block's around it, by one. So when lighting for a block is updated, it would check the light levels around it. If the highest light level is x, this block's light level would be x-1 (when there is a block higher than itself.)
I don't know how well this would work, though, and unfortunately, I can't test it myself.
If there is something I overlooked, please tell me, so I can (maybe) fix it and make it work.
I'm a cat, you are not my master... I am YOUR master.
sorry about the necropost, but slime chunks arent addressed in the original post. how do slime chunks work in cubic worlds?
In the current implementation of the mod they work on columns, just like in vanilla. But there is no reason to not change it.
Cubic chunks discord server
So with some of the new snapshots they are introducing cubic biomes, do you think this could be a hint that we're getting cubic chunks in the near future? Feeling hopeful.
The Ancient Worlds
https://mctaw.net/