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
If I'm not mistaken, sunlight does not travel horizontally, only vertically. If that statement is false, go ahead and skip this reply. Since sunlight is vertical, you could store a 2D array of integers representing the height of the highest non-transparent block in each vertical column. For every block placed, the system would first check if the block height was greater than the stored height for that column then, if that is true, it would also check if the block is transparent, and if that was also true, it would update the 2D array to the appropriate height. When a block is broken,
It does, up to 15 blocks, like a regular light source.
Vanilla already does that. I think Cubic chunks' issue is more about when blocks move around far above in unloaded chunks.
Whatever, the editor just doesn't work. The first quote is supposed to say: "If I'm not mistaken, sunlight does not travel horizontally, only vertically."
The first quote is meant to say "If I'm not mistaken, sunlight does not travel horizontally, only vertically.", but apparently the editor here just never works. I even tried to post it again in a new reply and it just discarded my message completely, after first appearing like it posted a duplicate of the previous one. This forum really needs some bugfixes.
Test
What? Does it append to my previous message? Can anyone else see this?
I want the block build height removed, as it is artificially restricting the creativity of players in Minecraft in both survival and creative modes of the game.
Cubic chunks offers that feature, and this should have became a non mod feature a long time ago, but for some reason Mojang have been reluctant to add this in despite the numerous players in the community wanting it to be brought in.
Also some changes to the world generator would be welcome, mountain peaks should be made to extend to about 1024 blocks or a little more, making them more to scale, and clouds ought to be moved up to about 740 Y, but still be rendered/be visible (it wouldn't strain a computer to just render them)
To counter the risks of this in survival, perhaps a newer feather falling enchantment grade could be added in, Feather Falling V.
Ocean depths should be extended
and bedrock layer should be moved to the negative Y coordinates, if it is to exist at all.
as for the lag concerns
Cubic chunks is not the only way to optimize the game, but it is a step in the right direction,
only chunks which are visible to the player need to be rendered.
This is 100% a requirement for a cave update if people really HAVE to have caves determined by biomes. Unfortunately it will complicate things and also wastes time spent on programming in oceans and lava oceans despite not being able to distinguish biomes by material (air, stone, or fluid).
Caves already can be determined by biome; my own mods are proof of this and all you need to do is check the biome before generating caves:
Also, 1.16 internally supports 3D biomes so if that is what you are referring to (underground generation completely decoupled from surface biomes) it is already in the game (and otherwise I could easily add it myself, if not true 3D then just a second biome layer).
Not only that, since 1.13 caves, as well as ores and other features, are all registered per-biome instead of being set globally or per dimension, if the same for nearly all biomes (caves mainly only differ in having water or air; I haven't checked but prior to 1.13 the Nether had its own cave generator with a different altitude/density distribution; prior to 1.13 these were set per-dimension):
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?
Those are all good things to know, thanks!
I'm pretty disappointed there's nothing related to this in the upcoming Cave update. It would have been the perfect opportunity for them to introduce much deeper worlds. Is there any hope for this anymore?
The Ancient Worlds
https://mctaw.net/
I'm pretty sure Mojang has rejected this suggestion in the past. Something to do with weather, especially snow getting messed up by it. Don't know the details though.
I wonder how cave biomes are going to occur without these cubic chunks.
I think the world's deep enough as it is.
There is hope... because they just added a setting for this in the latest snapshot!
https://www.minecraft.net/en-us/article/minecraft-snapshot-20w49a
https://minecraft.gamepedia.com/Java_Edition_20w49a
That would be really nice.
This is not real Cubic Chunks though, simply an extension of the Anvil file format to make full use to the "Sections:Y" tag, which uses a byte to store the y-index of sections; a byte ranges from -128 to +127, and presto, that's why the new height limit is +/- 2048 blocks (minus a section from the top and bottom, apparently for lighting calculations); otherwise, entire chunks are still being loaded and rendered (or at least sections that are not empty, so simply increasing the build limit has little impact on performance but if world generation or player builds do then it will have an impact). This is also discussed in this Reddit thread:
https://www.reddit.com/r/technicalminecraft/comments/j7xz6q/mod_developers_opinion_on_the_performance_of_512/
In particular:
This is also suggested by videos/threads like this:
https://www.reddit.com/r/Minecraft/comments/l1vwv1/dropping_down_from_minecrafts_new_almost_2048/
That said, I didn't have issues playing on a "triple height terrain" world with 3 times the current ground depth on a computer which probably has absolutely no chance of even starting up modern versions (32 bit Windows 7 with 3 GB RAM on an Athlon 64 X2 4200+ and Geforce 7600GS with 256 MB VRAM supporting OpenGL 2.1. 1.17 will certainly not be playable since it requires OpenGL 3.2); of course 1.6.4 was far less resource-hungry than modern versions.
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 do worry about the new hardware demands of this feature, Mojang hasn't specifically stated that they're going to implement this feature in the form of cubic chunks which is a genuine cause for concern in my honest opinion.
Rendering chunks in a format of 768 blocks Y, 16 X and 16 Z or even more if the Y coordinate goes beyond this is going to triple or even quadruple the memory usage, without question if mountain peaks will generate up to 320 Y while the new cave systems will extend down to Y negative 60.
Not everyone has a PC capable of running this smoothly, I do at least on bedrock edition, but what about other people? without cubic chunks this is going to be extremely inefficient.
I am in favour of an increased build height, but not everything on the Y coordinate has to be rendered at once, it only makes sense when you're close to a structure at Y 1024 for example.
There doesn't seem to be any consensus about how the lighting engine will work. What's the most popular one?Hey @Astronut7, Would you mind If I used your ambient light idea in a future game?
The sunlight issue could be solved with Fenwick trees.
The original array would represent a column of blocks, with the first element representing the highest block and the last element representing the lowest block. Each element would contain the opacity of it's corresponding block, ranging from zero (fully transparent) to 15 (fully opaque).
Suppose we want to sum the first 27 elements of the array. With the Fenwick tree, we only have to sum these elements:
The total opacity is 121, so clearly the 28th block isn't getting any direct sunlight.
If we want to change an element of the original array, we can efficiently update the Fenwick tree. If we update the sixth element of the original array for example, these are the elements of the Fenwick tree that need to be updated:
Both these operations have O(log n) time complexity. In other words they should be performant even when the world height is very large.
I am of course oversimplifying the data structure a little, but hopefully you get the idea.