3D/Cubic Chunks

[JAGIELSKI]

It's a big suggestion that would require rewriting multiple systems, including world generation, but IMO it would be worth it as it would allow the following:

• World infinite in any direction (in the same sense the other cube game or Blockscape is "infinite", i.e. the limit would be maximum value of numeric data structures)
• Better performance as the game would only need to render 32x32x32 chunks around player instead of entire 32x32x256 (or 32x32x512) strips
• More interesting gameplay possibilities (imagine a huge tower that goes high into the sky, seemingly infinitely, and is filled with treasures, but also angry drifters and the challenge is to see how high you can get before it's too much for you, kinda like in a roguelike)
• Better world generation (basically you could put a Mount Everest in 1:1 scale in the game or even use real world geodata)

Again, it would be a huge core change so I don't expect it any time soon (if ever), but it would make the game so much better and further separate it from the other block survival game.

As for storage, the solution is simple: Save to disk only chunks that have been modified (block added/deleted) by the player, everything else is regenerated from the seed as if player seen that thing for the first time.

[Ciarara]

This is a feature I was really hoping for when I switched to this game, and I hope it gets implemented at some point in the future. Only having to load chunks in line of sight (and bordering chunks if close enough to a boundary) would theoretically improve performance a lot over loading the whole column, especially with increased world height. Loading of individual chunks would also be way faster. (edit: I think this is already the case, actually? see https://github.com/tyronx/occlusionculling)

It would also probably save on world size (in terms of data) even without having to regenerate chunks, since most sub-surface chunks would never be loaded. I think only saving modified chunks that contain at least one non-air block is a potentially good idea as well, though, since chunk generation would also be much cheaper if the whole column didn't have to be generated at once.

 

Edit: I read in another post that chunks in VS are already cubes, but terrain generation is still based on chunk columns (I'm unsure why, though). So what I'm actually interested in would be an alternative form of terrain generation to take advantage of the chunks being cubes, and allow for greater verticality

Edited January 28, 2025 by Ciarara

[7embre]

On 12/25/2024 at 3:59 AM, JAGIELSKI said:

As for storage, the solution is simple: Save to disk only chunks that have been modified (block added/deleted) by the player, everything else is regenerated from the seed as if player seen that thing for the first time.

I believe, generating new chunks is more costly than loading it from the storage, just imagine a server, say, with 100 players, constantly running in a different directions and generating new chunks, but it wouldn't stop lol, even if they settle, as they won't modify every chunk in their surroundings.

I think it's a matter of storing and reading data more effectively, as you already know the size of an array needed for the task. Still, even if devs consider changing the way world generates in a way you described it, it wouldn't be possible before the implementation of proper LOD-system and a without further optimizations on the side of storing chunk data.

[JAGIELSKI]

7 hours ago, Ciarara said:

I think only saving modified chunks that contain at least one non-air block is a potentially good idea as well, though, since chunk generation would also be much cheaper if the whole column didn't have to be generated at once.

Either you save all the chunks or only chunks modified in ANY way. Because with what you are suggesting, you'd have regenerating resources (ore, etc) because player decided to do some mining but didn't place anything (i.e. the only modified blocks were air).

 

As for @7embre post, the chunks are only expensive to generate, because the chunk is 32x32x256 (or however high the world is) instead of 32x32x32, always.

 

But again, this would require a major rewrite of the engine so it's a long way off if it will be done at all.

[Ciarara]

Quote

Because with what you are suggesting, you'd have regenerating resources (ore, etc) because player decided to do some mining but didn't place anything (i.e. the only modified blocks were air).

Oh, that's true. What I was thinking when I wrote that was to simply save empty chunks as null chunks, instead of saving data for every individual air block, but I forgot to write it out properly.

[Ciarara]

No matter the size, generating a chunk is going to take more resources than loading one from a file, so at that point it's an issue of whether you want to prioritize keeping file size low or performance high. Personally, for a game like this, I think performance is the top priority, especially on a server. However, a config setting for that could be useful for some people in single player, as long as it isn't to costly to implement. Adding a check for a config flag adds to processing time, even a small amount. I don't think a once-per-chunk check on generation would be noticeable, but as @7embre pointed out, on large servers everything gets magnified. That also includes file sizes, of course, which could get absolutely insane with many people using translocators to explore, so some way to cull unmodified chunks that haven't been loaded in a long time from the save could be needed.

[Thorfinn]

32x32x32 would almost never be sufficient --- only at the tippy top of the world. Everywhere else, you need to generate what you can see in that column, and there are a lot of sky islands, so you can't stop at your first air chunk. At minimum, you need to generate from ground level to worldheight. And you need to generate down until you encounter solid stone because of block gravity. You should also generate whatever you can see from the mouth of caves, some of which are vertical pits, because otherwise they would be obvious to anyone using the map. At any arbitrary spot near sea level, you are already generating 5, maybe 6, of the 8 in the column.

True, almost none of the bottom two chunks will ever be needed,  Could conditionals run fast enough to make that savings worthwhile?  Lava makes a glow in a tunnel even if it's not in line of sight. Would checking for that be faster than just generating the last two chunks? I don't know.

[Zadak]

Hmm interesting thread, I just suggested something similar https://discord.com/channels/302152934249070593/1334274448999710730/1334274448999710730

Not only having a "good enough" approximation of a far away chunk good, but also having them cached locally would save the Server from sending so many updates in Multiplayer.

Especially since you might want to have a big draw distance, but if you spend most of your time in the same area, you can have a bigger draw distance while not affecting the server's performance by simply caching chunks locally.

[THECREATURE1116]

I would love for this to be added. I think the greatest potential in this regard is terrain and mountains that are to scale, it would truly set this game apart imo.

There are some combinations of Minecraft mods you can run that somewhat replicate this at the cost of terrible performance, and even then it's amazing to see and garners thousands of impressions when clips of such generation are posted to social media.

[Katherine K]

On 1/28/2025 at 1:57 AM, 7embre said:

I believe, generating new chunks is more costly than loading it from the storage, just imagine a server, say, with 100 players, constantly running in a different directions and generating new chunks, but it wouldn't stop lol, even if they settle, as they won't modify every chunk in their surroundings.

I think it's a matter of storing and reading data more effectively, as you already know the size of an array needed for the task. Still, even if devs consider changing the way world generates in a way you described it, it wouldn't be possible before the implementation of proper LOD-system and a without further optimizations on the side of storing chunk data.

There are different approaches to proc-gen that one can take, and store/re-generate different amounts of data as needed. It seems like the engineering team on VS is perfectly capable of working with spatial hierarchies and memoization techniques required for this. The high level concept here is to make your proc gen fractal-like. This lets you "warm up" distant chunks without running full generation. E.g., you probably don't need all the cave generation to be done when you're just passing by a chunk within render distance of it. And you can store just what's been generated for future use, so if you have multiple players repeatedly using the same route, the "edge" of the generated region can remain low fidelity until somebody decides to explore the area properly.

It's work, and for all I know, that's what's planned for the future, but the good thing about this is that it can be done incrementally, improving performance and increasing viable world size as you're making it better. I'm optimistic based on what I've seen so far.