Apart from the non-operating decorator, and the render height limit stuff, the only problem I can see is that the swampland screenshot looks more like an (absolutely epic) mountainous desert cave kind of thing (though this could just be because you are on the edge of the biome, a long way underground)
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
The terrain generation is coming along pretty nicely. Here's some more pictures from my adventures. We haven't adjusted the limitations on rendering distance yet, which is why the terrain in this image is cut off at the top.
Apart from the non-operating decorator, and the render height limit stuff, the only problem I can see is that the swampland screenshot looks more like an (absolutely epic) mountainous desert cave kind of thing (though this could just be because you are on the edge of the biome, a long way underground)
It might be that since we're generating larger terrains now, we might need to adjust the scaling on the biome size to compensate.
The terrain generation is coming along pretty nicely. Here's some more pictures from my adventures:We haven't adjusted the limitations on rendering distance yet, which is why the terrain in this image is cut off at the top:
Nice. Proper mountains are proper. All you need to do now is fix that nasty default Minecraft fog that doesn't even blend in to the sky... /petpeeve
Do you just choose to play without soft lighting or has this mod broken that for now?
Even if you are unable to solve the problems that other attempts have come across with shadows, I would love to see this mod have an option to be deeper rather than tall. My vision of a great mod pack would contain Metallurgy 3 where tartarite becomes more and more common the closer you get to the nether which, by the way, would actually be accessible by just digging deeper like the achievement says. So many things you could do with this even with shadows from the sky disabled after y=0.
Then, if/when the shadow calculation limit is breached, we could start making olympusite or something. I fully support this mod and want to contribute in any way I can. Speaking of which, are you planning on making this a community-driven, open-source project?
It is open source though, and the M3L wiki page thing seems to imply that when M3L is functional, the community may be able to make their own hooks etc.
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
The terrain generation is coming along pretty nicely. Here's some more pictures from my adventures:
We haven't adjusted the limitations on rendering distance yet, which is why the terrain in this image is cut off at the top:
A tear of joy ran down my face.
btw: nice fps you were rocking in that one screenshot. How smooth is the initial mega-terrain generation at this point? It's a LOT of computing going on compared to the mostly flat terrains (comparitively speaking) in vanilla. And how is the cave generation issue I was talking with you about in PM?
[EDIT] It would be incredibly advantageous to the uptake of this mod, especially for server use, to include an option that would greatly increase initial playing speed in a new cubic world by pre-building and populating all chunks within a user-defined x.y.z3 area.
It could be in the World Generation options with a default pre-build range that they can select or alter. Then they can set it loose and go watch a movie or whatever. Afterwards when they start playing they will never have that initial terrain build lag every few steps, which can get far worse with huge terrain.
You could even have an option to use quiet background cycles to pre-build other defined ranges while they are playing, up to a max folder size if desired, or only start new background pre-building after a player reaches within a certain distance of the current edge of the initial build-out (in any direction, vertically or horizontally). That way the odds are better that they may never actually experience initial terrain-build lag. This would go a loong ways towards making the game smoother as well as minimizing the lag effects of mega-terrain generation.
Rollback Post to RevisionRollBack
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
It is open source though, and the M3L wiki page thing seems to imply that when M3L is functional, the community may be able to make their own hooks etc.
That's right. Once I do some more work to finish the initial release of M3L, it will be opened up for everyone to use to make mods. It should also be relatively easy to make new hooks and modify the modding API in M3L in response to changes from Mojang, and also modder creativity. =)
How smooth is the initial mega-terrain generation at this point? It's a LOT of computing going on compared to the mostly flat terrains (comparitively speaking) in vanilla. And how is the cave generation issue I was talking with you about in PM? [EDIT] It would be incredibly advantageous to the uptake of this mod, especially for server use, to include an option that would greatly increase initial playing speed in a new cubic world by pre-building and populating all chunks within a user-defined x.y.z3 area. It could be in the World Generation options with a default pre-build range that they can select or alter. Then they can set it loose and go watch a movie or whatever. Afterwards when they start playing they will never have that initial terrain build lag every few steps, which can get far worse with huge terrain. You could even have an option to use quiet background cycles to pre-build other defined ranges while they are playing, up to a max folder size if desired, or only start new background pre-building after a player reaches within a certain distance of the current edge of the initial build-out (in any direction, vertically or horizontally). That way the odds are better that they may never actually experience initial terrain-build lag. This would go a loong ways towards making the game smoother as well as minimizing the lag effects of mega-terrain generation.
Terrain generation is pretty fast. It takes roughly 20 seconds to pre-build the spawn area for a new world on my computer. Also, we've restructured how world generation is executed, so it causes virtually no lag on the server. There shouldn't be any reason to pre-generate large portions of the world, as long as players aren't moving across cubes faster than the terrain generator can generate them.
Apart from the non-operating decorator, and the render height limit stuff, the only problem I can see is that the swampland screenshot looks more like an (absolutely epic) mountainous desert cave kind of thing (though this could just be because you are on the edge of the biome, a long way underground)
It might be that since we're generating larger terrains now, we might need to adjust the scaling on the biome size to compensate.
At the time of the screenshot, the biomes used for terrain generation are not the same as what is displayed, due to the way the lookups for the biome are done in the code. I'll be working on that issue once I can poke Cuchaz's brain a bit.
Even if you are unable to solve the problems that other attempts have come across with shadows, I would love to see this mod have an option to be deeper rather than tall. My vision of a great mod pack would contain Metallurgy 3 where tartarite becomes more and more common the closer you get to the nether which, by the way, would actually be accessible by just digging deeper like the achievement says. So many things you could do with this even with shadows from the sky disabled after y=0.
I leave the question regarding shadows and lighting to Cuchaz, since he wrote the code that handles it, and knows it far better than I do.
However, have a look at the bottom of this post for a screenshot and some explanation.
Regarding digging into the nether:
- Biomes are 2D currently, meaning that regardless of how high or how deep you are in the world, you will be in the same biome since it's only based on X,Z coordinates, and disregards the Y coordinate. A wishlist item for a later release that I'd like to implement is 3D biomes, which would allow for changing biomes based on the Y-coordinate as well. Most of the biome generation code is black magic to me, however, and I haven't committed the time yet to figuring out how it works. I am talking with Timethor of TerrainControl, however, and I intend to pick his brain about it.
- The Nether as a dimension has a different scale in relation to the Surface, the 8:1 ratio. Being able to dig to the nether would invalidate this scale, but you'd still be able to make a portal to the dimension. Hmm, maybe you could use it for a different, special biome?
btw: nice fps you were rocking in that one screenshot. How smooth is the initial mega-terrain generation at this point? It's a LOT of computing going on compared to the mostly flat terrains (comparitively speaking) in vanilla. And how is the cave generation issue I was talking with you about in PM?
Well, looking at the generation process, approximately 20,000 cubes in a sphere (by my guess) around the designated spawn point is generated on the server before any are sent to the client. After that, it's up to the client to render them as quickly as possible. They are rendered in a nearest-cube-first order, with priority being to cubes below the player. It does appear to slow down when rendering cubes that are further away from the player, since it has more surface area of the sphere to cover, and it's also handling cubes that are not actually visible to the player. Cuchaz has mentioned that he wants to look at this, and see if he can get it to skip the cubes that aren't actually visible.
There have already been optimizations in the generation code to speed things up. Let me divert for a second and do a brief explanation on the cube processors:
In vanilla, chunks are generated as an atomic (or roughly so) operation. This means that when the world asks for a chunk that doesn't exist from the chunk provider, then chunk provider has to go and generate the entirety of the chunk in one go, which includes the terrain, the surface block replacement, the caves, ravines, trees, ores, etc., etc. Cuchaz has taken this, and broken it down into separate processors. There is currently a TerrainProcessor, which generates the actual, raw terrain (you can see pictures from when this was the only part working much earlier in the thread. The only blocks being made at this time were Stone and Air.), a BiomeProcessor, which replaces the surface block plus a few blocks underground with the biome's blocks (i.e. Grass and Dirt, or Sand and more Sand, plus Sandstone at the bottom.), a FeatureProcessor, which currently handles the caves and ravines (shout out to Barteks2k for getting this working!), and will also handle villages, strongholds, mineshafts, and additional features (little structures like desert temples or witches huts, although you could put stuff like volcanos or meteorite craters in here as well), a PopulationProcessor (which will handle the trees, grasses, mushrooms, plants, etc.), and then a LightingProcessor, which does the lighting calculations.
These generators make up the generation pipeline, which is broken into 1 second ticks. A cube moves from one stage to the next in the pipeline, and the pipeline processes as much as it can in each in each tick for each stage, in sequence. At initial world generation, after finding the spawn point, approximately 20,000 cubes are loaded into the pipeline, which then proceeds to process as many as it can per tick. This allows for smoother gameplay, as it doesn't cause such big lockups due to handling a entire chunk and all it's generation in one operation before releasing the thread to do something else, but breaks it down into bite-size pieces that the thread can switch into and out of more frequently, enabling it to do something else if it needs to before going back and doing another piece of the queue.
For example, in regards to the terrain generation alone, I imported the vanilla terrain generation system with it's noise generators and all that stuff, and modified it just enough to work with this mod. The number of cubes that the pipeline could process with the vanilla terrain generation was 60-140 per second. With the current terrain generation process, it doesn't drop below 100 cubes per second and can run up over 400 for groups with lots of air cubes.
The lighting averages about 400-500 cubes/sec, but that is very dependent on the terrain. For worlds were the terrain is very convoluted or I messed up on a part of the terrain generation, it could go as slow as 10-20 cubes/sec. It can alternatively run as high as 1500 cubes/sec.
Cave generation is part of the FeatureProcessor, which runs around 300 cubes/sec, so it's not a slowdown. The slowest part of the entire pipeline is the initial terrain generation.
[EDIT] It would be incredibly advantageous to the uptake of this mod, especially for server use, to include an option that would greatly increase initial playing speed in a new cubic world by pre-building and populating all chunks within a user-defined x.y.z3 area.It could be in the World Generation options with a default pre-build range that they can select or alter. Then they can set it loose and go watch a movie or whatever. Afterwards when they start playing they will never have that initial terrain build lag every few steps, which can get far worse with huge terrain.You could even have an option to use quiet background cycles to pre-build other defined ranges while they are playing, up to a max folder size if desired, or only start new background pre-building after a player reaches within a certain distance of the current edge of the initial build-out (in any direction, vertically or horizontally). That way the odds are better that they may never actually experience initial terrain-build lag. This would go a loong ways towards making the game smoother as well as minimizing the lag effects of mega-terrain generation.
From one standpoint, terrain build lag doesn't exist, since the time to generate and populate one cube is virtually instant. However, as mentioned previously, they are generated and rendered in a nearest-cube-first order, so the nearest cube may not actually be visible, which results in more time before the cube you are looking for does become visible. Part of that is on the renderer, which we haven't done anything with yet.
Pre-generating and storing larger areas is possible, but we'll probably leave that for a future version.
Here is a screenshot in regards to Mtyacorn's question:
The cubes at the top of the image haven't been rendered yet, but they have been generated, and used for the lighting calculations before being sent to the client and rendered. From what I can determine from the code, cubes do not have their lighting calculations done unless all cubes surrounding them have already been generated and had their terrain populated. And cubes are not sent to the client unless their lighting calculation is completed. In regards to edge cases, I leave those to Cuchaz to explain if he wants to.
Hey guys! Im just wondering, in the future, how compatible do you think this mod will be with other simple mods such as optifine or too many items? Do you think that compatibility will be one of your future goals?
That you guys have already redone the generation code in a way that speeds it up at a fundamental level is an unexpected and exciting revelation! And that due to that the old cave-problem has essentially been solved is more than I had any hope of, that cave problem was a nasty one..
And thanks for the shout out to and listing of Barteks2k's contributions to the project, I was hoping that he would get a chance to help out after all the work he did on a prior project arc. I know it means a lot to him.
You guys are not only doing an incredible job but you are all true class-acts. Kudos to you Sirs.
Rollback Post to RevisionRollBack
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
Even if you are unable to solve the problems that other attempts have come across with shadows, I would love to see this mod have an option to be deeper rather than tall. My vision of a great mod pack would contain Metallurgy 3 where tartarite becomes more and more common the closer you get to the nether which, by the way, would actually be accessible by just digging deeper like the achievement says. So many things you could do with this even with shadows from the sky disabled after y=0.
In regards to lighting, this mod only affects how it is calculated, not how it is rendered. I leave the question regarding shadows and lighting to Cuchaz, since he wrote the code that handles it, and knows it far better than I do.
As far as I know, the lighting engine in this mod should be able to handle lighting correctly (including sky light) at depths below y=0. I posted some screenshots earlier in this thread to show it.
Let me divert for a second and do a brief explanation on the cube processors: In vanilla, chunks are generated as an atomic (or roughly so) operation. This means that when the world asks for a chunk that doesn't exist from the chunk provider, then chunk provider has to go and generate the entirety of the chunk in one go, which includes the terrain, the surface block replacement, the caves, ravines, trees, ores, etc., etc. Cuchaz has taken this, and broken it down into separate processors. There is currently a TerrainProcessor, which generates the actual, raw terrain (you can see pictures from when this was the only part working much earlier in the thread. The only blocks being made at this time were Stone and Air.), a BiomeProcessor, which replaces the surface block plus a few blocks underground with the biome's blocks (i.e. Grass and Dirt, or Sand and more Sand, plus Sandstone at the bottom.), a FeatureProcessor, which currently handles the caves and ravines (shout out to Barteks2k for getting this working!), and will also handle villages, strongholds, mineshafts, and additional features (little structures like desert temples or witches huts, although you could put stuff like volcanos or meteorite craters in here as well), a PopulationProcessor (which will handle the trees, grasses, mushrooms, plants, etc.), and then a LightingProcessor, which does the lighting calculations. These generators make up the generation pipeline, which is broken into 1 second ticks. A cube moves from one stage to the next in the pipeline, and the pipeline processes as much as it can in each in each tick for each stage, in sequence.
This is basically how our new terrain generator is structured. We re-organized how chunk generation works so that it happens asynchronously instead of synchronously. This lets us distribute the workload of generating cubes over multiple ticks. If we try to do too much work in a single tick, that's what causes the lag spikes on the server. The terrain generation lag spikes are caused by the server trying to do 2s worth of work in a 50ms time slot. Obviously, that's not going to work well. Right now, our new generator pipeline is actually allowed 100ms of time each tick (instead of 1s) to generate cubes, but we should probably lower it to around 40ms. If the server is expected to maintain the usual 20 ticks per second, that only leaves 50ms of processing time per tick.
For example, in regards to the terrain generation alone, I imported the vanilla terrain generation system with it's noise generators and all that stuff, and modified it just enough to work with this mod. The number of cubes that the pipeline could process with the vanilla terrain generation was 60-140 per second. With the current terrain generation process, it doesn't drop below 100 cubes per second and can run up over 400 for groups with lots of air cubes. The lighting averages about 400-500 cubes/sec, but that is very dependent on the terrain. For worlds were the terrain is very convoluted or I messed up on a part of the terrain generation, it could go as slow as 10-20 cubes/sec. It can alternatively run as high as 1500 cubes/sec. Cave generation is part of the FeatureProcessor, which runs around 300 cubes/sec, so it's not a slowdown. The slowest part of the entire pipeline is the initial terrain generation.
That's pretty cool. Are these /sec measurements, or are they actually /tick? If you're reading those numbers from the console spam, then they should be /tick measurements, which means converting them to /sec measurements makes them 20 times faster. =)
Here is a screenshot in regards to Mtyacorn's question: The cubes at the top of the image haven't been rendered yet, but they have been generated, and used for the lighting calculations before being sent to the client and rendered. From what I can determine from the code, cubes do not have their lighting calculations done unless all cubes surrounding them have already been generated and had their terrain populated. And cubes are not sent to the client unless their lighting calculation is completed.
That's right. At first, I thought this screenshot was a bug in the lighting system, but the more I look at it, it actually seems to be working as intended. As long as the unloaded cubes above the shadowed terrain are a shelf which blocks the sunlight, then this lighting is both awesome-looking and correct.
Hey guys! Im just wondering, in the future, how compatible do you think this mod will be with other simple mods such as optifine or too many items? Do you think that compatibility will be one of your future goals?
Inter-mod compatibility is a huge problem with Minecraft mods right now. This is the exact problem my new mod loader, Magic Mojo Mod Loader (or M3L) is trying to solve. Then end goal is to have every mod be compatible with every other mod (to the extent that mods are not mutually exclusive). Making that actually happen requires changes at the mod loader level (ie, M3L) and also requires that modders stop making core mods or otherwise making mod-specific APIs on top of vanilla Minecraft using bytecode transformation tools. Once all the mods are using standard APIs, then we can solve the inter-mod compatibility problems.
That you guys have already redone the generation code in a way that speeds it up at a fundamental level is an unexpected and exciting revelation!
We didn't really make chunk generation any faster. We just re-organized how the workload is distributed over time using asynchronous programming tricks so the server doesn't lag.
That's pretty cool. Are these /sec measurements, or are they actually /tick? If you're reading those numbers from the console spam, then they should be /tick measurements, which means converting them to /sec measurements makes them 20 times faster. =)
You are correct, they're not per 1 sec, they're per 100 ms. So the numbers in my post should be multiplied by 10 for the correct cubes per second count.
You are correct, they're not per 1 sec, they're per 100 ms. So the numbers in my post should be multiplied by 10 for the correct cubes per second count.
Yeah, it's only 10 times faster since our tick budget is too long right now. Actually, I'll go drop it to 40ms now...
@ Biome constraints in regards to digging into the nether
Even without implementing a proper 3D biome system, you could always just store a different biome in a chunk, and then that biome would override the normal biome check. You could even just tweak the get_biome method (or w/e it's called) to return a different biome below a certain coordinate;
public int getBiome(x,y,z){
//some kind of switch statement for dimension?
if (y >= SOME_ARBITRARY_CONSTANT){
//Copy Paste the existing method here
return Same_BiomeID_that_the_vanilla_method_returns;
}else{
return BiomeID_of_Hell;
}
}
That said, I don't actually think that the player should be able to dig into the nether without some massive changes to other things... I find the distance multiplication thing rather convenient.
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
The Meaning of Life, the Universe, and Everything.
Join Date:
9/22/2011
Posts:
108
Minecraft:
keylan118
Member Details
You
Are
Amazing!!! Have a steak bro!
I love this! Too bad you didn't do Forge. Who knows, maybe you could make a forge-compatible version or something. When/If I start modding, I'll be sure to check out your Modding API. Seems really neat with the "all mods compatible" thing.
Rollback Post to RevisionRollBack
Paper is there for words to be written on it. Rules are there to be broken. Laws are there to be followed....to the letter of course! Please help my dragons!
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumLookin' good! =)
It might be that since we're generating larger terrains now, we might need to adjust the scaling on the biome size to compensate.
*envisages a single mountain consisting of 6 different biomes*
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Nice. Proper mountains are proper. All you need to do now is fix that nasty default Minecraft fog that doesn't even blend in to the sky...
Do you just choose to play without soft lighting or has this mod broken that for now?
Then, if/when the shadow calculation limit is breached, we could start making olympusite or something. I fully support this mod and want to contribute in any way I can. Speaking of which, are you planning on making this a community-driven, open-source project?
It is open source though, and the M3L wiki page thing seems to imply that when M3L is functional, the community may be able to make their own hooks etc.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
A tear of joy ran down my face.
btw: nice fps you were rocking in that one screenshot. How smooth is the initial mega-terrain generation at this point? It's a LOT of computing going on compared to the mostly flat terrains (comparitively speaking) in vanilla. And how is the cave generation issue I was talking with you about in PM?
[EDIT] It would be incredibly advantageous to the uptake of this mod, especially for server use, to include an option that would greatly increase initial playing speed in a new cubic world by pre-building and populating all chunks within a user-defined x.y.z3 area.
It could be in the World Generation options with a default pre-build range that they can select or alter. Then they can set it loose and go watch a movie or whatever. Afterwards when they start playing they will never have that initial terrain build lag every few steps, which can get far worse with huge terrain.
You could even have an option to use quiet background cycles to pre-build other defined ranges while they are playing, up to a max folder size if desired, or only start new background pre-building after a player reaches within a certain distance of the current edge of the initial build-out (in any direction, vertically or horizontally). That way the odds are better that they may never actually experience initial terrain-build lag.
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis mod is already an open-source project with multiple developers contributing code.
That's right. Once I do some more work to finish the initial release of M3L, it will be opened up for everyone to use to make mods. It should also be relatively easy to make new hooks and modify the modding API in M3L in response to changes from Mojang, and also modder creativity. =)
Terrain generation is pretty fast. It takes roughly 20 seconds to pre-build the spawn area for a new world on my computer. Also, we've restructured how world generation is executed, so it causes virtually no lag on the server. There shouldn't be any reason to pre-generate large portions of the world, as long as players aren't moving across cubes faster than the terrain generator can generate them.
[EDIT2] Broken formatting
At the time of the screenshot, the biomes used for terrain generation are not the same as what is displayed, due to the way the lookups for the biome are done in the code. I'll be working on that issue once I can poke Cuchaz's brain a bit.
I play without smooth lighting. In regards to lighting, this mod only affects how it is calculated, not how it is rendered.
I leave the question regarding shadows and lighting to Cuchaz, since he wrote the code that handles it, and knows it far better than I do.
However, have a look at the bottom of this post for a screenshot and some explanation.
Regarding digging into the nether:
- Biomes are 2D currently, meaning that regardless of how high or how deep you are in the world, you will be in the same biome since it's only based on X,Z coordinates, and disregards the Y coordinate. A wishlist item for a later release that I'd like to implement is 3D biomes, which would allow for changing biomes based on the Y-coordinate as well. Most of the biome generation code is black magic to me, however, and I haven't committed the time yet to figuring out how it works. I am talking with Timethor of TerrainControl, however, and I intend to pick his brain about it.
- The Nether as a dimension has a different scale in relation to the Surface, the 8:1 ratio. Being able to dig to the nether would invalidate this scale, but you'd still be able to make a portal to the dimension. Hmm, maybe you could use it for a different, special biome?
Well, looking at the generation process, approximately 20,000 cubes in a sphere (by my guess) around the designated spawn point is generated on the server before any are sent to the client. After that, it's up to the client to render them as quickly as possible. They are rendered in a nearest-cube-first order, with priority being to cubes below the player. It does appear to slow down when rendering cubes that are further away from the player, since it has more surface area of the sphere to cover, and it's also handling cubes that are not actually visible to the player. Cuchaz has mentioned that he wants to look at this, and see if he can get it to skip the cubes that aren't actually visible.
There have already been optimizations in the generation code to speed things up. Let me divert for a second and do a brief explanation on the cube processors:
In vanilla, chunks are generated as an atomic (or roughly so) operation. This means that when the world asks for a chunk that doesn't exist from the chunk provider, then chunk provider has to go and generate the entirety of the chunk in one go, which includes the terrain, the surface block replacement, the caves, ravines, trees, ores, etc., etc. Cuchaz has taken this, and broken it down into separate processors. There is currently a TerrainProcessor, which generates the actual, raw terrain (you can see pictures from when this was the only part working much earlier in the thread. The only blocks being made at this time were Stone and Air.), a BiomeProcessor, which replaces the surface block plus a few blocks underground with the biome's blocks (i.e. Grass and Dirt, or Sand and more Sand, plus Sandstone at the bottom.), a FeatureProcessor, which currently handles the caves and ravines (shout out to Barteks2k for getting this working!), and will also handle villages, strongholds, mineshafts, and additional features (little structures like desert temples or witches huts, although you could put stuff like volcanos or meteorite craters in here as well), a PopulationProcessor (which will handle the trees, grasses, mushrooms, plants, etc.), and then a LightingProcessor, which does the lighting calculations.
These generators make up the generation pipeline, which is broken into 1 second ticks. A cube moves from one stage to the next in the pipeline, and the pipeline processes as much as it can in each in each tick for each stage, in sequence. At initial world generation, after finding the spawn point, approximately 20,000 cubes are loaded into the pipeline, which then proceeds to process as many as it can per tick. This allows for smoother gameplay, as it doesn't cause such big lockups due to handling a entire chunk and all it's generation in one operation before releasing the thread to do something else, but breaks it down into bite-size pieces that the thread can switch into and out of more frequently, enabling it to do something else if it needs to before going back and doing another piece of the queue.
For example, in regards to the terrain generation alone, I imported the vanilla terrain generation system with it's noise generators and all that stuff, and modified it just enough to work with this mod. The number of cubes that the pipeline could process with the vanilla terrain generation was 60-140 per second. With the current terrain generation process, it doesn't drop below 100 cubes per second and can run up over 400 for groups with lots of air cubes.
The lighting averages about 400-500 cubes/sec, but that is very dependent on the terrain. For worlds were the terrain is very convoluted or I messed up on a part of the terrain generation, it could go as slow as 10-20 cubes/sec. It can alternatively run as high as 1500 cubes/sec.
Cave generation is part of the FeatureProcessor, which runs around 300 cubes/sec, so it's not a slowdown. The slowest part of the entire pipeline is the initial terrain generation.
From one standpoint, terrain build lag doesn't exist, since the time to generate and populate one cube is virtually instant. However, as mentioned previously, they are generated and rendered in a nearest-cube-first order, so the nearest cube may not actually be visible, which results in more time before the cube you are looking for does become visible. Part of that is on the renderer, which we haven't done anything with yet.
Pre-generating and storing larger areas is possible, but we'll probably leave that for a future version.
Here is a screenshot in regards to Mtyacorn's question:
The cubes at the top of the image haven't been rendered yet, but they have been generated, and used for the lighting calculations before being sent to the client and rendered. From what I can determine from the code, cubes do not have their lighting calculations done unless all cubes surrounding them have already been generated and had their terrain populated. And cubes are not sent to the client unless their lighting calculation is completed. In regards to edge cases, I leave those to Cuchaz to explain if he wants to.
And thanks for the shout out to and listing of Barteks2k's contributions to the project, I was hoping that he would get a chance to help out after all the work he did on a prior project arc. I know it means a lot to him.
You guys are not only doing an incredible job but you are all true class-acts. Kudos to you Sirs.
- The Cubic Chunks Mod is back! Be a part of it's rebirth and Development.
-- Robinton's Mods: [ Mirror ] for some of his Mods incl Cubic Chunks Mod, due to DropBox broken links.
- Dungeon Generator for the Open Cubic Chunks Mod
- QuickSAVE-QuickLOAD for the Open Cubic Chunks Mod
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAs far as I know, the lighting engine in this mod should be able to handle lighting correctly (including sky light) at depths below y=0. I posted some screenshots earlier in this thread to show it.
This is basically how our new terrain generator is structured. We re-organized how chunk generation works so that it happens asynchronously instead of synchronously. This lets us distribute the workload of generating cubes over multiple ticks. If we try to do too much work in a single tick, that's what causes the lag spikes on the server. The terrain generation lag spikes are caused by the server trying to do 2s worth of work in a 50ms time slot. Obviously, that's not going to work well. Right now, our new generator pipeline is actually allowed 100ms of time each tick (instead of 1s) to generate cubes, but we should probably lower it to around 40ms. If the server is expected to maintain the usual 20 ticks per second, that only leaves 50ms of processing time per tick.
That's pretty cool. Are these /sec measurements, or are they actually /tick? If you're reading those numbers from the console spam, then they should be /tick measurements, which means converting them to /sec measurements makes them 20 times faster. =)
That's right. At first, I thought this screenshot was a bug in the lighting system, but the more I look at it, it actually seems to be working as intended. As long as the unloaded cubes above the shadowed terrain are a shelf which blocks the sunlight, then this lighting is both awesome-looking and correct.
Inter-mod compatibility is a huge problem with Minecraft mods right now. This is the exact problem my new mod loader, Magic Mojo Mod Loader (or M3L) is trying to solve. Then end goal is to have every mod be compatible with every other mod (to the extent that mods are not mutually exclusive). Making that actually happen requires changes at the mod loader level (ie, M3L) and also requires that modders stop making core mods or otherwise making mod-specific APIs on top of vanilla Minecraft using bytecode transformation tools. Once all the mods are using standard APIs, then we can solve the inter-mod compatibility problems.
We didn't really make chunk generation any faster. We just re-organized how the workload is distributed over time using asynchronous programming tricks so the server doesn't lag.
You are correct, they're not per 1 sec, they're per 100 ms. So the numbers in my post should be multiplied by 10 for the correct cubes per second count.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYeah, it's only 10 times faster since our tick budget is too long right now. Actually, I'll go drop it to 40ms now...
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumSorry, not going to happen.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEven without implementing a proper 3D biome system, you could always just store a different biome in a chunk, and then that biome would override the normal biome check. You could even just tweak the get_biome method (or w/e it's called) to return a different biome below a certain coordinate;
public int getBiome(x,y,z){ //some kind of switch statement for dimension? if (y >= SOME_ARBITRARY_CONSTANT){ //Copy Paste the existing method here return Same_BiomeID_that_the_vanilla_method_returns; }else{ return BiomeID_of_Hell; } }That said, I don't actually think that the player should be able to dig into the nether without some massive changes to other things... I find the distance multiplication thing rather convenient.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Are
Amazing!!! Have a steak bro!
I love this! Too bad you didn't do Forge. Who knows, maybe you could make a forge-compatible version or something. When/If I start modding, I'll be sure to check out your Modding API. Seems really neat with the "all mods compatible" thing.
Please help my dragons!
this is just amazing.
i can't wait for the release. *rubs hands together in anticipation* *hands catch fire* *is to mesmerised by the awesomeness too notice*