No, this is still too early version. While it is more stable then beta version of TWM for M3L, I want to release something that actually works and is playable. My terrain generation optimization hack seems to break lighting, the vanilla terrain generator sometimes crashes (to avoid actual crash I ignore the error, which causes empty chunks). There are many features that don't work outside of 0-255 height range. And world format is still very likely to change in way that it's incompatible with old worlds and I would like to avoid making a converter.
Have a suggestion or rather would we say a challenge ifyour up for it itd change the modding community forever if your into changing you should try to make a mod that changes the entity limits not how many are spawned but how manythe game can contain if you didnt know its impossible to play two large mods together such as orespawn and divinerpg or adventof acension making a mod to increase this limit would basically make you able to have endless amounts of mods and being able to change ids in configs is the only issue left ... msg me and lemme know what you think -lorddarkus
1. Don't post the same thing twice, you already got reply
2. This is something that Forge should do, not mods
3. As far as I know there is no limit on the amount of entities mods can add. And if there is limit - it's very likely to be gone in future MC versions because Mojang it trying to move away from any kind of numeric IDs.
firstly, I am really hyped seeing you make progress on this once more. The height limit is the most annoying aspect of Minecraft for me and I'd love being able to explore new caverns and building on top of larger mountains.
Did you fix the lighting issue by now? I put some brain matter into this a few months back when work on this mod started slowing down and somewhat forgot about it. The general problem of lighting with unlimited height is simple: By default it is impossible to determine if a block is occluded, because theoretically overhangs might appear higher up and cast a shadow on blocks below. Without restricting the terrain generators' freedom, this problem is impossible to overcome. I think I have a somewhat elegant solution based on having the terrain generators provide additional information for lighting calculation.
I refer to this additional information as the so called "noon-" and "midnight-function"s. Whilst generators are in theory allowed to do anything they want, in practice the vast majority of them follow some set of rules limiting how high up they are going to generate blocks. The proposed functions formalize these restrictions such that lighting calculations can be sped up.
noon-function: For any given column (x,z), returns the highest possible y coordinate that may contain a block.
midnight-function: For any given column (x,z), returns the lowest possible y coordinate that may not contain a block.
Without any sort of structure or overgrowth generation, during lighting calculation, only those blocks in between the function's values need to be considered. To allow for structures and trees, all that needs to be done is to extend the definition of these functions to the respective generators. A necessary addition would be the concept of "decal-reach". The decal-reach of a given decal-generator (i.e. the algorithms responsible for creating strongholds), is the largest possible distance a decal may extend on the (x,z) plane and therefor the furthest distance from its center where it might end up occluding blocks further down.
Whilst generating chunks, the terrain generator would always generate as many chunks extra as required by the largest decal-reach of all of its decal-generators. This enables the decal-generators to determine if they are going to place a decal in a given location. During lighting, it could poll all of its decal-generators to determine if any of them generate decals that may occlude (or in the case of caves, open up) blocks in a given column.
As far as I am aware, this method should work with every terrain generator that is capable of providing the given functions. Other generators (i.e. vertically unrestricted floating island generators), simply lack the required restraints and will break lighting unless we generate 8mio blocks in every column.
The vanilla terrain generator could simply use y+128 as its noon- and y-128 as its midnight-function. The cubes in between would end up being generated all the time, but the sky above is guaranteed to be open (unless decals are being generated).
That was something very close to what I planned for worldgen lighting, except that I was going to call this "predicted min heightmap" and "predicted max heightmap". Except that for most terrain generators it's not really needed (ie. lighting is almost always accurate given that all cube neighbors are generated), so it would be opt-in.
Doing something like this causes an issue I still have to solve in my vanilla worldgen code - it needs loading cubes that aren't kept loaded by any player. So the question is - when they should be unloaded? (I have some idea for it but not implemented yet)
You could use a counting flag. On creation, a chunk increments the flag on every chunk above itself (up to the noon height). Once its lighting has been completed, it decrements the flags. A chunk is treated the usual way, if and only if, its own flag equals zero. Thus chunks that are needed for lighting do not get unloaded until lighting is done.
This wouldn't really work that well. Once you get further down, say, 1600 blocks, it's gotta load up 100 chunks every time you go down another 16 blocks, which would cause a massive lag spike. What you could do instead, is have the lighting information stored in the chunk above it, and then it only checks that chunk for its own lighting.
Afaik, that is already being done on a block-column basis. For each block column the lowest block for which skylighting has been finished is stored including its light value. My midnight- function would improve upon this further.
Do you mean in the vanilla game, or in the current build that Barteks has of his TWM fork?
If you mean in vanilla:
You're correct, that absolutely does already happen. However, in vanilla, you only have to load up 256 different light values, max. In TWM, you have to load up to 33,554,432 blocks. Believe it or not, this puts a MASSIVE strain on computers, and is unbelievably infeasible.
If you meant in the current fork: I have no reply.
P.S: sorry for the late reply, I've been studying for exams recently, and forgot to check the thread
Right. I'm not sure how to respond now. I have no response. I don't know anything about how they're doing it now, so I'm gonna stay out of the argument now
Right. I'm not sure how to respond now. I have no response. I don't know anything about how they're doing it now, so I'm gonna stay out of the argument now
My OpacityIndex is based on Cuchaz's OpacityIndex class. But instead of full opacity values it stores opaque/transparent flag. It simplifies a few things (ie. searching for next top block below given Y position, opacity segments cal only alternate between opaque/transparent) and full opacity value isn't really needed. All that is needed is height value.
And I'm actually going to simplify it even further, as in vast majority of cases all I need is to know the Cube (cubic chunk) that contains the top block (let's call it topBlockCube). To explain why I will refer to this piece os information (#1): To update any kind of light value anywhere all blocks withing radius of 17 blocks (not 16 blocks as people may think) need to be loaded.
And now there can be a few cases:
1. The block is above the topBlockCube - the bloc is fully lit anyway.
2. The block is below or in the the topBlockCube - if the block is more than 16 blocks below topBlockCube it doesn't matter where exactly in that cube the top block is, it won't change light value anyway. And if it's less than 16 block below, then by (#1) the cube with that block has to be loaded, to it's possible to figure out which block it actually is.
So the OpacityIndex needs to know only if a given 1x16x1 block segment contains opaque block, or not.
As for generating skylight for terrain generation - I am actually try to implement I3iohazard's idea (as I also thought about doing it). And no, it won't cause generating tens of thousands of cubes, at least not with the way I'm going to implement it. For example when generating cube that is definitely below the minPoossibleTopBlock (midnight-function) - there is no need to generate anything. When generating cube that is definitely above maxPossibleTopBlock (noon-function) - there is also no need to generate anything. For everything between - there would be an option to actually force generating all of these cubes (but then terrain generator needs to know relatively accurately where the top block is), or do something that it definitely not correcyt but shouldn't look too bad - assume that light values change smoothly between maxPossibleTopBlock and minPossibleTopBlock.
And then there are a few big issues I still have (and Cuchaz's TWM also had them) - updating lighting when loading cubes and synchronizing lighting between client and server (the easy solutions makes everything very laggy. And by "very laggy" I mean that terrain generation would cause worse FPS drops than in any previous vanilla Minecraft version).
Cuchaz kind of solved the first problem by generating a hash of OpacityIndex and recalculating lighting on cube load if the hash changed - but it worked only because his FirstLightProcessor didn't really work correctly in case of worldgen, and it was very inefficient. My current FirstLightProcessor works correctly for worldgen, but there are certain assumptions that make it unsuitable for recalculating lighting later.
And I changed one more thing - client uses a dummy implementation of OpacityIndex that has only heightmap received from server. In current code certain methods are completely unimplemented in it. I decided to do it after I saw one problem - forge limits packet size to 1MB. And the OpacityIndex can grow really really big. Possibly even above 1MB and it's nearly uncompressible (it did happen one for me when testing, because of the way Razaekel's lava generation deep underground worked).
This causes an obvious problem (well... obvious when you are implementing Chunk.setBlock method) - client doesn't know new heightmap value when setting block until it receives new height value from the server. It eventually will receive heightmap update, and lighting will be updated, but it would cause weird looking lag. So I made it try to guess the new heighmap by searching max 64 blocks down when setting block to something transparent (I assumed that client will need to wait for rendering update for anything deeper than that anyway).
Also, I hope that the whole discussion isn't too off topic in this thread (this thread is about Cuchaz's TWM, not my fork of it).
Oh dang, I stopped following this thread because I thought it was put on hold... now I see were in beta? I may actually be able to finish my nakheel tower someday!
For the sake of completeness I'd like to expand on this. The concept of the midnight- and noon-functions (I'll reuse these terms until they've ended up becoming a standard :P), if there exists some sort of feature/structure generation, this is only a partial solution. If caves and ravines are not included in the midnight-function, they might end up extending further down, thereby opening up areas to skylight. Similarly, trees or buildings might extend further into the sky and therefor cause additional occlusion.
These problems can be solved by determining the upper bound of the impact all features might have and extending the noon- and midnight-limits accordingly. But depending on the feature, this might end up being a very expensive extension. In vanilla, as far as i know, there is no limit on how far vertical cave-segments might reach. Additionally mod developers might want to generate huge artificial mining-sites, large buildings or flying islands and thereby ruin the simplicity of the proposed system.
I was writing a long answer to this but for some reason chrome crashed and I lost it and don't want to rewrite it. So I will write shorter version.
1. I know about these issues, but the most important thing to get right is vanilla generator. And it's good enough for it. If other modders want to generate extreme terrain - let them handle lighting.
2. As for flying islands - there will need to be special case in lighting for them to ignore abything above certain height completely (or ignore their biomes)
3. I like names you proposed (midnight function and noon function) butthey aren't descri[tive enough. Names in code are for people to underdtand what is going on. And redefining words doesn't help with that.
Vanilla caves and ravines can both go all the way down to the overworld lava lake at 11.
Floating islands ... Vanilla worldgen can go above Y=200 in the two extreme biomes, and Savanna Plateau M can have an overhang at 200 above ground at 70. That's as close to a floating island as any mod I've seen.
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
Vanilla caves and ravines can both go all the way down to the overworld lava lake at 11.
Floating islands ... Vanilla worldgen can go above Y=200 in the two extreme biomes, and Savanna Plateau M can have an overhang at 200 above ground at 70. That's as close to a floating island as any mod I've seen.
There are just "standard biomes" with floating pieces of terrain. And as far as I know the actual vanilla height range is no more than 64-256 which is about 192 blocks. It's a lot but it's not that much actually.
1. I do agree that getting the vanilla generator up and running has the highest priority right now and from what I've seen in my testing thus far, you seem to be very close. But I do think that CC/TWM must be as permissive for future terrain generators as possible, including a fully functional lighting engine or a t least a proper framework of terrain generators to supply the necessary information.
3. I agree, more descriptive names would certainly be a lot better. But everything else I've managed to come up with thus far doesn't really work either. "totalOcclusionHeightMap" or "zeroOcclusionHeightMap" are just clunky. ^^
1. This is unfortunately inherent limitation of cubic chunks, another oddity that people would need to accept. Someone can always make terrain generator so complex and unpredictable that no lighting system can compensate for it. If someone wants it to work - terrain generator and lighting code need to cooperate in one way or another.
Are you referring to my work? All I've done so far is refactoring and modifying Barteks' code to make world generator pipelines customizable. This is back-end work without any changes to the user experience. I might do a pull-request to Barteks' repository, because these changes (as far as I am aware) remove unnecessary restrictions without introducing functional drawbacks.
Wait, so you actually did these changes to the code?
I was going to do some major refactoring/rewrite of the GeneratorPipeline because after profiling it turns out that it takes most of the tick time when idle. The idea is to use chunk load/unload events instead of checking each chunk each tick. But for last 2 weeks it was getting more and more delayed. It's time to finally get it done.
Its really not difficult. If you'd like I'll send you a short step-by-step guide later today.
Some of them, but it is not yet event/thread based. I've merely changed the GeneratorPipeline such that it does not use an enum. My next step would've been some planing with respect to threading. If you'd like I can try pushing the changes to your repository once I am home (~5 hours from now).
Well... not using an enum is also what I planned for new generation pipeline. I already partially implemented it and it should technically allow to properly deal with population states (256 possible states for a cube).
It would be great is you pushed these changes so that I see what and how you actually did.
And I wouldn't even try with threading. even if you are going to make "TERRAIN" stage multithreaded, maybe even "BIOMES" and "STRUCTURES" if you know what you are doing, and possibly "LIGHTING" if you make OpacityIndex thread safe, the slowest part (unimplemented/disabled for CustomCubic world type) is "POPULATION". And this required access to world class. And there is no way in hell you can make it thread safe without making single-threaded access slower, breaking a lot of things, and then hacking it around with ASM/Mixins. Also note that CustomCubic generator is very inefficient.
And I have some idea that would allow to merge TERRAIN, BIOMES and STRUCTURES into one stage by using density map to generate dirt/grass. It would basically look like this:
Get density value at X/Y/Z, and calculate gradient at X/Y/Z. If density is less than a specified value and greater than zero, and the gradient has negative Y value (density increases downwards) - then it would be set to dirt, and then based on density value above it could decide if grass block should be set.
My enum replacement is complete and permits for 255 possible generator states (+ LIVE). There are some places I'd like to beautify, but everything works as it should. How would you like me to manage the code? I use my own git server and have yet to upload stuff to github. My username on there is "Cyclonit" (like pretty much everywhere else).
I think you should fork it on github, then add it as a remote in your local repository, push and submit a pull request.
Also, there would be just 256 possible population stage states. And they don't need to change linearly. And a cube can exsist in state like "LIGHTING isn't done yet but it's in 137th population state" (it's not state that should exist, but there needs to be a way to represent it).
Why not map them linearly? With regards to my dependency work, having them linearly makes the most sense. But I don't think changing it to non-linear transitions is difficult. All that needs to be done is define the possible successor stages in each stage and adjust the transitions in the code accordingly.
There is a problem with population states. They are a messy thing, and even vanilla does it wrong, but because it deals with it in 2d it can get away with it. With Cubic Chunks things get much worse.
First I need to explain how population works (I hope you already have some idea about how it works). In vanilla populating ChunkPos(X, Z) means that the following block range is populated BlockPos(X*16 + 8, 0, Z*16 + 8) to BlockPos(X*16 + 8 + 15, 255, Z*16 + 8 + 15) (inclusive). Technically Minecraft could populate just this one chunk, but then some structures would go out of that chunk in each direction. So instead of requiring 3 neighbor chunks, population would require all 8 neighbor chunks.
But it also means that isPopulated state isn't really a single flag. To be sure that a chunk is populated you need to know if chunks at ChunkPos(X - 1, Z), ChunkPos(X - 1, Z - 1) and ChunkPos(X, Z - 1). And they don't have to be always loaded, but to send the Chunk to client it needs to be fully generated. Vanilla simply ignores that problem and pretends that chunks are populated the way everyone would expect.
With CubicChunks it's essentially the same, just more typing because there are 7 neighbors (so 8 flags in total, which adds up to 256 states).
But with Cubic Chunks + Generation Pipeline ignoring it causes some issues - for example worldgen block updates are sent to client after the chunk has been sent to has been sent to client. And in some cases it can be up to 80% of all blocks set during population.It essentially means that suring terrain generation many chunks are sent to client twice. And this also causes issues with lighting because then client has to recalculate light updates for these newly added blocks.
Now I can choose to ignore this issue (because it's not a major issue, but it gets woorse with cubic chunks) and wait until Mojang fixes it, or actually fix it while I'm fixing generation pipeline.
My approach would've been not to send cubes to the client until they have been fully generated to begin with (which I guess is what you'd like to prevent too). But I don't see why you'd need to use non-linear staging for this. Going back to my idea of formulating dependencies, for cube A to reach the stage LIVE, all cubes in its vicinity must have finished their last stage affecting cube A. Assuming the stage TREES generates trees with up to 18 blocks in diameter, a cube cannot be live until all of its neighbors have exited the stage TREES.
That seems all fine and nice until you realize that you are generating cubes in radius 7 with view distance set to 3, and you need to keep them loaded just to know if you can send these in view radius 3 to client. That's why I think it would be better to track the whole stage of a cube within that cube.
No, this is still too early version. While it is more stable then beta version of TWM for M3L, I want to release something that actually works and is playable. My terrain generation optimization hack seems to break lighting, the vanilla terrain generator sometimes crashes (to avoid actual crash I ignore the error, which causes empty chunks). There are many features that don't work outside of 0-255 height range. And world format is still very likely to change in way that it's incompatible with old worlds and I would like to avoid making a converter.
1. Don't post the same thing twice, you already got reply
2. This is something that Forge should do, not mods
3. As far as I know there is no limit on the amount of entities mods can add. And if there is limit - it's very likely to be gone in future MC versions because Mojang it trying to move away from any kind of numeric IDs.
Cubic chunks discord server
That was something very close to what I planned for worldgen lighting, except that I was going to call this "predicted min heightmap" and "predicted max heightmap". Except that for most terrain generators it's not really needed (ie. lighting is almost always accurate given that all cube neighbors are generated), so it would be opt-in.
Doing something like this causes an issue I still have to solve in my vanilla worldgen code - it needs loading cubes that aren't kept loaded by any player. So the question is - when they should be unloaded? (I have some idea for it but not implemented yet)
Cubic chunks discord server
This wouldn't really work that well. Once you get further down, say, 1600 blocks, it's gotta load up 100 chunks every time you go down another 16 blocks, which would cause a massive lag spike. What you could do instead, is have the lighting information stored in the chunk above it, and then it only checks that chunk for its own lighting.
Do you mean in the vanilla game, or in the current build that Barteks has of his TWM fork?
If you mean in vanilla:
You're correct, that absolutely does already happen. However, in vanilla, you only have to load up 256 different light values, max. In TWM, you have to load up to 33,554,432 blocks. Believe it or not, this puts a MASSIVE strain on computers, and is unbelievably infeasible.
If you meant in the current fork: I have no reply.
P.S: sorry for the late reply, I've been studying for exams recently, and forgot to check the thread
Right. I'm not sure how to respond now. I have no response. I don't know anything about how they're doing it now, so I'm gonna stay out of the argument now
My OpacityIndex is based on Cuchaz's OpacityIndex class. But instead of full opacity values it stores opaque/transparent flag. It simplifies a few things (ie. searching for next top block below given Y position, opacity segments cal only alternate between opaque/transparent) and full opacity value isn't really needed. All that is needed is height value.
And I'm actually going to simplify it even further, as in vast majority of cases all I need is to know the Cube (cubic chunk) that contains the top block (let's call it topBlockCube). To explain why I will refer to this piece os information (#1): To update any kind of light value anywhere all blocks withing radius of 17 blocks (not 16 blocks as people may think) need to be loaded.
And now there can be a few cases:
1. The block is above the topBlockCube - the bloc is fully lit anyway.
2. The block is below or in the the topBlockCube - if the block is more than 16 blocks below topBlockCube it doesn't matter where exactly in that cube the top block is, it won't change light value anyway. And if it's less than 16 block below, then by (#1) the cube with that block has to be loaded, to it's possible to figure out which block it actually is.
So the OpacityIndex needs to know only if a given 1x16x1 block segment contains opaque block, or not.
As for generating skylight for terrain generation - I am actually try to implement I3iohazard's idea (as I also thought about doing it). And no, it won't cause generating tens of thousands of cubes, at least not with the way I'm going to implement it. For example when generating cube that is definitely below the minPoossibleTopBlock (midnight-function) - there is no need to generate anything. When generating cube that is definitely above maxPossibleTopBlock (noon-function) - there is also no need to generate anything. For everything between - there would be an option to actually force generating all of these cubes (but then terrain generator needs to know relatively accurately where the top block is), or do something that it definitely not correcyt but shouldn't look too bad - assume that light values change smoothly between maxPossibleTopBlock and minPossibleTopBlock.
And then there are a few big issues I still have (and Cuchaz's TWM also had them) - updating lighting when loading cubes and synchronizing lighting between client and server (the easy solutions makes everything very laggy. And by "very laggy" I mean that terrain generation would cause worse FPS drops than in any previous vanilla Minecraft version).
Cuchaz kind of solved the first problem by generating a hash of OpacityIndex and recalculating lighting on cube load if the hash changed - but it worked only because his FirstLightProcessor didn't really work correctly in case of worldgen, and it was very inefficient. My current FirstLightProcessor works correctly for worldgen, but there are certain assumptions that make it unsuitable for recalculating lighting later.
And I changed one more thing - client uses a dummy implementation of OpacityIndex that has only heightmap received from server. In current code certain methods are completely unimplemented in it. I decided to do it after I saw one problem - forge limits packet size to 1MB. And the OpacityIndex can grow really really big. Possibly even above 1MB and it's nearly uncompressible (it did happen one for me when testing, because of the way Razaekel's lava generation deep underground worked).
This causes an obvious problem (well... obvious when you are implementing Chunk.setBlock method) - client doesn't know new heightmap value when setting block until it receives new height value from the server. It eventually will receive heightmap update, and lighting will be updated, but it would cause weird looking lag. So I made it try to guess the new heighmap by searching max 64 blocks down when setting block to something transparent (I assumed that client will need to wait for rendering update for anything deeper than that anyway).
Also, I hope that the whole discussion isn't too off topic in this thread (this thread is about Cuchaz's TWM, not my fork of it).
Cubic chunks discord server
Meh. Feel free to take over the thread. This is where the interested people are, after all.
Oh dang, I stopped following this thread because I thought it was put on hold... now I see were in beta? I may actually be able to finish my nakheel tower someday!
Planetminecraft Site Moderator.
https://www.planetminecraft.com/member/ryer/
I was writing a long answer to this but for some reason chrome crashed and I lost it and don't want to rewrite it. So I will write shorter version.
1. I know about these issues, but the most important thing to get right is vanilla generator. And it's good enough for it. If other modders want to generate extreme terrain - let them handle lighting.
2. As for flying islands - there will need to be special case in lighting for them to ignore abything above certain height completely (or ignore their biomes)
3. I like names you proposed (midnight function and noon function) butthey aren't descri[tive enough. Names in code are for people to underdtand what is going on. And redefining words doesn't help with that.
Cubic chunks discord server
Vanilla caves and ravines can both go all the way down to the overworld lava lake at 11.
Floating islands ... Vanilla worldgen can go above Y=200 in the two extreme biomes, and Savanna Plateau M can have an overhang at 200 above ground at 70. That's as close to a floating island as any mod I've seen.
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
There are just "standard biomes" with floating pieces of terrain. And as far as I know the actual vanilla height range is no more than 64-256 which is about 192 blocks. It's a lot but it's not that much actually.
1. This is unfortunately inherent limitation of cubic chunks, another oddity that people would need to accept. Someone can always make terrain generator so complex and unpredictable that no lighting system can compensate for it. If someone wants it to work - terrain generator and lighting code need to cooperate in one way or another.
3. What about minHeightMap and maxHeightMap?
Cubic chunks discord server
Wish I could test what you've done so far. I've heard I'm pretty good at making things break.
referring to the mod itself
Wait, so you actually did these changes to the code?
I was going to do some major refactoring/rewrite of the GeneratorPipeline because after profiling it turns out that it takes most of the tick time when idle. The idea is to use chunk load/unload events instead of checking each chunk each tick. But for last 2 weeks it was getting more and more delayed. It's time to finally get it done.
Cubic chunks discord server
I both have no idea what git is, or how to set up a running environment
Also, hype for that barteks
Sure, I'd be down
Well... not using an enum is also what I planned for new generation pipeline. I already partially implemented it and it should technically allow to properly deal with population states (256 possible states for a cube).
It would be great is you pushed these changes so that I see what and how you actually did.
And I wouldn't even try with threading. even if you are going to make "TERRAIN" stage multithreaded, maybe even "BIOMES" and "STRUCTURES" if you know what you are doing, and possibly "LIGHTING" if you make OpacityIndex thread safe, the slowest part (unimplemented/disabled for CustomCubic world type) is "POPULATION". And this required access to world class. And there is no way in hell you can make it thread safe without making single-threaded access slower, breaking a lot of things, and then hacking it around with ASM/Mixins. Also note that CustomCubic generator is very inefficient.
And I have some idea that would allow to merge TERRAIN, BIOMES and STRUCTURES into one stage by using density map to generate dirt/grass. It would basically look like this:
Get density value at X/Y/Z, and calculate gradient at X/Y/Z. If density is less than a specified value and greater than zero, and the gradient has negative Y value (density increases downwards) - then it would be set to dirt, and then based on density value above it could decide if grass block should be set.
I will actually try to get something done today.
Cubic chunks discord server
I think you should fork it on github, then add it as a remote in your local repository, push and submit a pull request.
Also, there would be just 256 possible population stage states. And they don't need to change linearly. And a cube can exsist in state like "LIGHTING isn't done yet but it's in 137th population state" (it's not state that should exist, but there needs to be a way to represent it).
Cubic chunks discord server
There is a problem with population states. They are a messy thing, and even vanilla does it wrong, but because it deals with it in 2d it can get away with it. With Cubic Chunks things get much worse.
First I need to explain how population works (I hope you already have some idea about how it works). In vanilla populating ChunkPos(X, Z) means that the following block range is populated BlockPos(X*16 + 8, 0, Z*16 + 8) to BlockPos(X*16 + 8 + 15, 255, Z*16 + 8 + 15) (inclusive). Technically Minecraft could populate just this one chunk, but then some structures would go out of that chunk in each direction. So instead of requiring 3 neighbor chunks, population would require all 8 neighbor chunks.
But it also means that isPopulated state isn't really a single flag. To be sure that a chunk is populated you need to know if chunks at ChunkPos(X - 1, Z), ChunkPos(X - 1, Z - 1) and ChunkPos(X, Z - 1). And they don't have to be always loaded, but to send the Chunk to client it needs to be fully generated. Vanilla simply ignores that problem and pretends that chunks are populated the way everyone would expect.
With CubicChunks it's essentially the same, just more typing because there are 7 neighbors (so 8 flags in total, which adds up to 256 states).
But with Cubic Chunks + Generation Pipeline ignoring it causes some issues - for example worldgen block updates are sent to client after the chunk has been sent to has been sent to client. And in some cases it can be up to 80% of all blocks set during population.It essentially means that suring terrain generation many chunks are sent to client twice. And this also causes issues with lighting because then client has to recalculate light updates for these newly added blocks.
Now I can choose to ignore this issue (because it's not a major issue, but it gets woorse with cubic chunks) and wait until Mojang fixes it, or actually fix it while I'm fixing generation pipeline.
Cubic chunks discord server
That seems all fine and nice until you realize that you are generating cubes in radius 7 with view distance set to 3, and you need to keep them loaded just to know if you can send these in view radius 3 to client. That's why I think it would be better to track the whole stage of a cube within that cube.
Cubic chunks discord server