I've also been working on this mod with Cuchaz, but focusing on the terrain and biome generation. The guy is a beast!
Here's a shot from deep underwater. Going much deeper than this will kill you. There are a number of bugs at y < 0, but we'll squash them.
As in, going deeper kills you because of bugs/the void, or going deeper kills you because you programmed in a kind of water pressure that crushes your body so hard that your lungs and eardrums rupture?
Also... I think the used memory percentages are not quite right...
I've also been working on this mod with Cuchaz, but focusing on the terrain and biome generation. The guy is a beast!
Here's a shot from deep underwater. Going much deeper than this will kill you. There are a number of bugs at y < 0, but we'll squash them.
Thank you guys!!
I'm so glad Neg-y is working out, this is truly going to be a top-class mod and now with neg-y I will feel completely at home when playing with it like the good old days with Robintons CC Mod. Plus, it will make it so much easier to convert peoples already existing CC Mod project worlds (lots of cities and buildings etc) over to the new format so that they can live again!
Lol, I was just thinking about how I used to enjoy playing on a friends server a long time ago where he had copied a big section of a far away part of the world surface and used MCEdit to paste it underground under spawn.
This created an awesome "Lost World" feel with minimal effort, sooo dark and dangerous though, heh heh. The only thing that sucked was that there was so little ground between the surface and it, which is something that this mod will totally fix now.
* Another awesome thing these days is that MCEdit is now open source too, it wasn't back in the original CC Mods time. This will make it possible for it to be updated to work with this mods worlds!
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.
YES! Tall Worlds Mod and Ships Mod will be amazing! Airships and submarines will be SOOO much more fun when there are tall mountains and deep oceans!
Oh yes, oh yes it will. Orbital platforms and all of that! It was a rush getting a taste of all this back in the day with the old Zeppelin mod combined with Robintons Cubic Chunks mod. I'm so glad your Ships mod will be carrying on this tradition as the ideas are made for each other.
The old screenshot below was one I took back in the beta 1.7.3 days to demonstrate Robintons CC Mod + Zeppelin Mod + my Cart Mod all working together and how they complemented each other.
* Yes, the y coord is only at +159, but this was back when vanilla only went up to +128 and I wanted the surface to still be visible.
[EDIT]btw: That 20fps was better than I got with vanilla back then with that old computer. The CC Mod increased the fps and smoothness of minecraft for me. [/EDIT]
The second one. =) Also, imagine big regions of underground area that aren't just stone and gravel.
Oh yesss.. Underground domains full of Sleestak and dinosaurs! Mountain pockets full of goblins. All sorts of special and unique things and even ores or items to find. The possibilities are endless once a 3D Biome framework is in place. The ideal of course is to have a plug-in API that will allow other modders to create custom Biome domains that players can plug into their worlds. Robinton had made an initial version of one that was going to be expanded for this same purpose.
We had so many grand ideas for these 3D Biomes and I had also outlined a lot of ideas for a space/orbital add-on that allowed varied gravitiy levels depending on height as well as Mini-moons or sky islands that had their own gravity levels etc (All with "Minecraft Physics" of course, I know real gravitiy doesn't noticably change close to Earth and what orbit really means).
Oh hey; I've just read that Dinnerbone tweeted in response to someone that 1.8 has been pushed back and they might not release it for another couple months.
That will give you guys some more breathing room within which to develop this mods foundation and initial features, this is a good thing.
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.
As in, going deeper kills you because of bugs/the void, or going deeper kills you because you programmed in a kind of water pressure that crushes your body so hard that your lungs and eardrums rupture?
Also... I think the used memory percentages are not quite right...
It's because of the void. We'll get that sorted out, and then we can REALLY go deeper.
The memory percentages are correct, I've just allocated a lot of memory to the JVM.
It's because of the void. We'll get that sorted out, and then we can REALLY go deeper.
The memory percentages are correct, I've just allocated a lot of memory to the JVM.
Ah, I see, I missed the trailing 0 on your allocated RAM... lol... I was expecting something in the range of 1-2GB, which is what most people use, hence when I saw the 1635, I just stored that and moved on. Quite an intriguing psychological phenomenon. In fairness, I only looked at the numbers once. It was an edit because after I had changed the page, I realized that 668 was definitely not 4% of 1635.
Anyway... just how RAM does your system have? (unless it's all pagefile)
32 GB. I normally use 4GB, but I allocated 16GB due to a bug I ran across and I wanted to watch it play out :D. It was continuously generating cubes due to a bad check, and it went up to about 1.7 million Y before I stopped it. The bug is fixed now, but I hadn't brought the memory allocation back down yet.
32 GB. I normally use 4GB, but I allocated 16GB due to a bug I ran across and I wanted to watch it play out :D. It was continuously generating cubes due to a bad check, and it went up to about 1.7 million Y before I stopped it. The bug is fixed now, but I hadn't brought the memory allocation back down yet.
I figured the allocation was for something like that :P. I mean, there are 2 reasons I can think of why you would have 16GB of allocated RAM - loading a hugeass part of the world, or you don't want the garbage collector interfering while trying to gauge performance.
Really 1.7 million y... Actually... that probably didn't even lag aaaaaaalllllll that hard, since all the empty chunks would just get skipped for most calculations.
I figured the allocation was for something like that . I mean, there are 2 reasons I can think of why you would have 16GB of allocated RAM - loading a hugeass part of the world, or you don't want the garbage collector interfering while trying to gauge performance.
Really 1.7 million y... Actually... that probably didn't even lag aaaaaaalllllll that hard, since all the empty chunks would just get skipped for most calculations.
It was pretty much instantaneous generation. The problem was, it wouldn't stop generating.
Hey Cuchaz / Razaekel, great to hear of the progress you've made. I'm very excited for this mod and can't wait for your next status update!
Will there be any problems that will have to be solved pertaining to items / fluids / redstone signals that propagate vertically? Solutions in singleplayer seem like they could be simple, but what about multiplayer situations where for example: a player with a large render distance drops an item to / pours water on another player who has a small render distance? (In other words, the receiver doesn't have the block / entitiy data of the other player loaded.)
Will there be any problems to solve pertaining to consistency in multiplayer? I'm not sure how vanilla Minecraft handles these problems in the horizontal fashion, so this question might just be trivial if the solution is the same, just orthogonal.
Hey Cuchaz / Razaekel, great to hear of the progress you've made. I'm very excited for this mod and can't wait for your next status update!
Will there be any problems that will have to be solved pertaining to items / fluids / redstone signals that propagate vertically? Solutions in singleplayer seem like they could be simple, but what about multiplayer situations where for example: a player with a large render distance drops an item to / pours water on another player who has a small render distance? (In other words, the receiver doesn't have the block / entitiy data of the other player loaded.)
Will there be any problems to solve pertaining to consistency in multiplayer? I'm not sure how vanilla Minecraft handles these problems in the horizontal fashion, so this question might just be trivial if the solution is the same, just orthogonal.
Most probably the server will handle this stuff and send the chunk data to people near the loaded chunks.
1.Server starts
2.Player 1 joins (far distance)
3.Player 2 joins (short distance)
4.Player 1 (Who is 10 chunks above player 2) drops some water flow and some dirt
5.server has the chunks between the players loaded
6.when either the water or the items reach player 2 render distance, the server sends the information to him/her
7.Player 2 receives/sees the items/water that fell
Very promising. I'm not entirely confident in the discussed lighting solutions as far as them making sense. Maybe someone can explain how it's working for me.
My biggest hangup is: are we still going to have sky??? The way I'm reading it we'll just spawn for example at 0 0 0 in a new world, the server will start creating a cube of chunks around us...and then? We're inside a giant infinite cube of 3D biomes?
In other words is it going to be like Minecraft where at some point, everything above the ground = air?
Very promising. I'm not entirely confident in the discussed lighting solutions as far as them making sense. Maybe someone can explain how it's working for me.
My biggest hangup is: are we still going to have sky??? The way I'm reading it we'll just spawn for example at 0 0 0 in a new world, the server will start creating a cube of chunks around us...and then? We're inside a giant infinite cube of 3D biomes?
In other words is it going to be like Minecraft where at some point, everything above the ground = air?
To answer your question; yes. What you get is a world with a ground, and a sky, and oceans, and mountains and plains and whatever else. Cubic Chunks just improves on a lot of the shortcomings in the vanilla engine (and opens up some awesome room for expansion in some areas).
Chunks are how Minecraft organizes data. In the vanilla "linear" system, it can only store data in 16x16x256 regions. While these regions can be placed infinitely beside each other, they cannot be stacked. Cubic Chunks changes this. First we reduce the size of each chunk, to 16x16x16 (a cube), and then we reprogram the game and tell it to stack these chunks up on top of each other. This means that we can keep extending the world up well past the 256 block limit in the Vanilla.
But this is just how Minecraft ORGANIZES data, and how the data is stored on the disc. From the disc, the game loads the blocks into memory, and then performs calculations on the blocks themselves. For this reason, chunks are not very relevant after they have been loaded. Lighting works in the same way - there there are no blocks above, the sunlight can hit the blocks below, lighting them up. If there are blocks above, they block the sunlight, and the view to the sky, and so on.
So here's the catch: in the linear system, we KNOW if there are blocks above, since we know where every block is on the vertical axis. In Cubic Chunks, the chunks above the player might not be loaded, and if they aren't, then the game thinks that there are no blocks there. This means that you could stand 100000 blocks under a giant floating island that ~should~ block all of the sunlight, but because it's not loaded, the game doesn't know that it exists, and the shadow is ignored.
Cuchaz rewrote the lighting system a little bit a few days ago, and now if the chunks above have ~ever~ been loaded; the game will remember if there were blocks in them, and whether it should let light pass down to the blocks below.
In regards to biomes - There is simply an option to store a biome per chunk, meaning that you could for example have a Desert biome on the surface, and then underneath; a cavern biome, or an underwater reservoir biome or something. The top of a mountain might be a "moutain peak" biome. The bottom of an ocean might be an "ocean floor" biome.
Thank you for your detailed explanation, 4HeadTiger. I've read/followed the cubics chunk thread for a long time now so I'm fully aware of how things work regarding the chunks themselves.
I guess I should have been more explicit in my question. As it stands, Minecraft is constrained to 256 blocks in the vertical. This makes world generation ridiculously easy compared to generating infinite blocks in the vertical (yes, yes, it's not technically infinite but 16 million fething blocks is pretty close to infinite in my book.) Minecraft assumes ~62 = water, things above water = land, and you end up with a virtual heightmap everywhere you go because of the 256 block limit. Everything above any given SURFACE block is assumed to be air, lit by the sun.
With Cuchaz's mod what determines that any given block is a SURFACE block? It's almost like you would need an actual heightmap to do so. Sure, you could build a floating island at +7 mil Y, but as far as generation goes what determines the natural landscape(s) that have actual surface blocks where, at any given point everything above it (all the way up to the limit) is assumed to be air?
Considering how much the colored light dude is talking on this, can we expect some kind of compatibility, or maybe even merging your APIs? I mean, by the looks of it you are both rewriting the lighting system, and both mods are too amazing (and previously thought impossible) to not use together. Also, have you done anything on negative height yet, or are you just not doing that? This mod looks more promising than some other CC mods I've seen. I hope it works out.
I'm not planning on doing colored lights. Another mod can do that. I'm working on negative y worlds right now actually. I almost have it, but there are a few pesky issues standing in my way. I just need some more time to debug. I usually max out at 60. I run with vsync on. Anything higher than 60 fps is just wasting resources.
So, I wrote my end with backwards compat being a number one concern.
Our lighting engines are probably far from similar as well, so there really isn't a good way I can replace the vanilla lighting engine if someone else did it first =) So it won't work right out of the box.
That being said, once I get my rendering pipeline sorted out, I don't think it would be that hard to target and locate similar changes to Cuchaz's lighting engine. I'd be able to use my existing framework and apply changes to blocks (which I think Cuchaz mostly left alone) the lighting engine, and saving... Everything else should remain "vanilla enough" for my end to work.
I'm excited to see how this turns out!
Edit: I'll take a look at what it will take to bridge the two. It might not be worth it, but I'm not giving this up yet!
Thank you for your detailed explanation, 4HeadTiger. I've read/followed the cubics chunk thread for a long time now so I'm fully aware of how things work regarding the chunks themselves.
I guess I should have been more explicit in my question. As it stands, Minecraft is constrained to 256 blocks in the vertical. This makes world generation ridiculously easy compared to generating infinite blocks in the vertical (yes, yes, it's not technically infinite but 16 million fething blocks is pretty close to infinite in my book.) Minecraft assumes ~62 = water, things above water = land, and you end up with a virtual heightmap everywhere you go because of the 256 block limit. Everything above any given SURFACE block is assumed to be air, lit by the sun.
With Cuchaz's mod what determines that any given block is a SURFACE block? It's almost like you would need an actual heightmap to do so. Sure, you could build a floating island at +7 mil Y, but as far as generation goes what determines the natural landscape(s) that have actual surface blocks where, at any given point everything above it (all the way up to the limit) is assumed to be air?
I think that better sums up my interrogative!
Thanks in advance for your time.
Surface blocks and lighting; you've almost got it. First, the lighting system takes an x/z coordinate. Now it goes to some x/z coordinate and chooses a block. Are there blocks above? If yes, move to them. Are there blocks above them? If yes, move to them. And so on. Eventually, we will find a block that has no blocks above it, and now we say that this block is the top block.
Top block by definition has no solid blocks above it, and for this reason, we know that it is lit by the sun.
Of course, because of how CC works, there might actually be a block above that is not loaded into the world, and hence invisible to us. Problem? Sometimes.
Just pretend the player builds a really big building... like... a 200 block tall cave inside a mountain, pitch black inside, no sunlight of any kind can get in. Oh, but when they go down to the bottom of the cave, the game unloads the top. No top = nothing stopping the light from getting in, and suddenly their pitch black cavern is all lit up like a supernova. This is a problem.
To solve this, a height-map is pretty much what we use.
Eventually, we will find a block that has no blocks above it, and now we say that this block is the top block.
When this block is found, the game records where that block was. Now even if that block isn't loaded, it doesn't matter, because we know that it is there, and we know where it is. The result? Simple. Even if the roof of our mountain cavern isn't loaded, we know that it's there, and we know to keep the bottom of the cave dark at all times.
While the terrain generator ~can~ indicate to us where the topmost block ~might~ be, there are two problems. The first is that we can't know where the terrain actually is until we actually generate it. The second is that the terrain can change, if say the player plants a tree, or builds a house, or idek... blows up their IC2 nuclear reactor.
As it stands, Minecraft is constrained to 256 blocks in the vertical. This makes world generation ridiculously easy compared to generating infinite blocks in the vertical (yes, yes, it's not technically infinite but 16 million fething blocks is pretty close to infinite in my book.) Minecraft assumes ~62 = water, things above water = land, and you end up with a virtual heightmap everywhere you go because of the 256 block limit. Everything above any given SURFACE block is assumed to be air, lit by the sun. With Cuchaz's mod what determines that any given block is a SURFACE block? It's almost like you would need an actual heightmap to do so. Sure, you could build a floating island at +7 mil Y, but as far as generation goes what determines the natural landscape(s) that have actual surface blocks where, at any given point everything above it (all the way up to the limit) is assumed to be air? I think that better sums up my interrogative! Thanks in advance for your time.
It seems to me your question has little to do with how the lighting system works and more to do with how terrain generation works. The vanilla terrain generation system is partly a black box to me, so I don't completely understand how it works. The "surface" of the world seems to be decided by generating and conditioning a whole crapton of Perlin noise, but trying to understand how those algorithms work by starting at decompiled, obfuscated code is essentially a nightmare. Razaekel is in charge of terrain generation, and I think he's working on writing a completely new cubified terrain generator. Right now, we're just hobbling along with my cubification edits on the vanilla terrain generation system. Eventually, we'll get something better.
So, how do we pick the "surface" of a world? I have no idea. =)
So, I wrote my end with backwards compat being a number one concern. Our lighting engines are probably far from similar as well, so there really isn't a good way I can replace the vanilla lighting engine if someone else did it first =) So it won't work right out of the box. That being said, once I get my rendering pipeline sorted out, I don't think it would be that hard to target and locate similar changes to Cuchaz's lighting engine. I'd be able to use my existing framework and apply changes to blocks (which I think Cuchaz mostly left alone) the lighting engine, and saving... Everything else should remain "vanilla enough" for my end to work. I'm excited to see how this turns out! Edit: I'll take a look at what it will take to bridge the two. It might not be worth it, but I'm not giving this up yet!
If I understand correctly how you made colored lights work the last time, I think you could do the same thing in my lighting system. I didn't really change How lighting works too much for cubic chunks. I mostly just changed When and Where it works.
If I understand correctly how you made colored lights work the last time, I think you could do the same thing in my lighting system. I didn't really change How lighting works too much for cubic chunks. I mostly just changed When and Where it works.
Interesting... I change the "how", only to include other colored channels in the existing routines (excluding sunlight). Cross your fingers because we might closer to working than I thought! I'll let you know what I find when I finally get through some hurdles on my end.
As in, going deeper kills you because of bugs/the void, or going deeper kills you because you programmed in a kind of water pressure that crushes your body so hard that your lungs and eardrums rupture?
Also... I think the used memory percentages are not quite right...
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Thank you guys!!
I'm so glad Neg-y is working out, this is truly going to be a top-class mod and now with neg-y I will feel completely at home when playing with it like the good old days with Robintons CC Mod. Plus, it will make it so much easier to convert peoples already existing CC Mod project worlds (lots of cities and buildings etc) over to the new format so that they can live again!
- 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
This created an awesome "Lost World" feel with minimal effort, sooo dark and dangerous though, heh heh. The only thing that sucked was that there was so little ground between the surface and it, which is something that this mod will totally fix now.
* Another awesome thing these days is that MCEdit is now open source too, it wasn't back in the original CC Mods time. This will make it possible for it to be updated to work with this mods worlds!
- 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
Oh yes, oh yes it will. Orbital platforms and all of that! It was a rush getting a taste of all this back in the day with the old Zeppelin mod combined with Robintons Cubic Chunks mod. I'm so glad your Ships mod will be carrying on this tradition as the ideas are made for each other.
The old screenshot below was one I took back in the beta 1.7.3 days to demonstrate Robintons CC Mod + Zeppelin Mod + my Cart Mod all working together and how they complemented each other.
* Yes, the y coord is only at +159, but this was back when vanilla only went up to +128 and I wanted the surface to still be visible.
[EDIT]btw: That 20fps was better than I got with vanilla back then with that old computer. The CC Mod increased the fps and smoothness of minecraft for me. [/EDIT]
Oh yesss.. Underground domains full of Sleestak and dinosaurs! Mountain pockets full of goblins. All sorts of special and unique things and even ores or items to find. The possibilities are endless once a 3D Biome framework is in place. The ideal of course is to have a plug-in API that will allow other modders to create custom Biome domains that players can plug into their worlds. Robinton had made an initial version of one that was going to be expanded for this same purpose.
We had so many grand ideas for these 3D Biomes and I had also outlined a lot of ideas for a space/orbital add-on that allowed varied gravitiy levels depending on height as well as Mini-moons or sky islands that had their own gravity levels etc (All with "Minecraft Physics" of course, I know real gravitiy doesn't noticably change close to Earth and what orbit really means).
- 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
That will give you guys some more breathing room within which to develop this mods foundation and initial features, this is a good thing.
- 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
It's because of the void. We'll get that sorted out, and then we can REALLY go deeper.
The memory percentages are correct, I've just allocated a lot of memory to the JVM.
Ah, I see, I missed the trailing 0 on your allocated RAM... lol... I was expecting something in the range of 1-2GB, which is what most people use, hence when I saw the 1635, I just stored that and moved on. Quite an intriguing psychological phenomenon. In fairness, I only looked at the numbers once. It was an edit because after I had changed the page, I realized that 668 was definitely not 4% of 1635.
Anyway... just how RAM does your system have? (unless it's all pagefile)
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
I figured the allocation was for something like that :P. I mean, there are 2 reasons I can think of why you would have 16GB of allocated RAM - loading a hugeass part of the world, or you don't want the garbage collector interfering while trying to gauge performance.
Really 1.7 million y... Actually... that probably didn't even lag aaaaaaalllllll that hard, since all the empty chunks would just get skipped for most calculations.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
I won't post a screenshot this time. There are still bugs in the lighting system for negative y cubes. I need to figure out what's going on there...
It was pretty much instantaneous generation. The problem was, it wouldn't stop generating.
Will there be any problems that will have to be solved pertaining to items / fluids / redstone signals that propagate vertically? Solutions in singleplayer seem like they could be simple, but what about multiplayer situations where for example: a player with a large render distance drops an item to / pours water on another player who has a small render distance? (In other words, the receiver doesn't have the block / entitiy data of the other player loaded.)
Will there be any problems to solve pertaining to consistency in multiplayer? I'm not sure how vanilla Minecraft handles these problems in the horizontal fashion, so this question might just be trivial if the solution is the same, just orthogonal.
Most probably the server will handle this stuff and send the chunk data to people near the loaded chunks.
1.Server starts
2.Player 1 joins (far distance)
3.Player 2 joins (short distance)
4.Player 1 (Who is 10 chunks above player 2) drops some water flow and some dirt
5.server has the chunks between the players loaded
6.when either the water or the items reach player 2 render distance, the server sends the information to him/her
7.Player 2 receives/sees the items/water that fell
Click Please!
Viva Argentina!
My biggest hangup is: are we still going to have sky??? The way I'm reading it we'll just spawn for example at 0 0 0 in a new world, the server will start creating a cube of chunks around us...and then? We're inside a giant infinite cube of 3D biomes?
In other words is it going to be like Minecraft where at some point, everything above the ground = air?
To answer your question; yes. What you get is a world with a ground, and a sky, and oceans, and mountains and plains and whatever else. Cubic Chunks just improves on a lot of the shortcomings in the vanilla engine (and opens up some awesome room for expansion in some areas).
But this is just how Minecraft ORGANIZES data, and how the data is stored on the disc. From the disc, the game loads the blocks into memory, and then performs calculations on the blocks themselves. For this reason, chunks are not very relevant after they have been loaded. Lighting works in the same way - there there are no blocks above, the sunlight can hit the blocks below, lighting them up. If there are blocks above, they block the sunlight, and the view to the sky, and so on.
So here's the catch: in the linear system, we KNOW if there are blocks above, since we know where every block is on the vertical axis. In Cubic Chunks, the chunks above the player might not be loaded, and if they aren't, then the game thinks that there are no blocks there. This means that you could stand 100000 blocks under a giant floating island that ~should~ block all of the sunlight, but because it's not loaded, the game doesn't know that it exists, and the shadow is ignored.
Cuchaz rewrote the lighting system a little bit a few days ago, and now if the chunks above have ~ever~ been loaded; the game will remember if there were blocks in them, and whether it should let light pass down to the blocks below.
In regards to biomes - There is simply an option to store a biome per chunk, meaning that you could for example have a Desert biome on the surface, and then underneath; a cavern biome, or an underwater reservoir biome or something. The top of a mountain might be a "moutain peak" biome. The bottom of an ocean might be an "ocean floor" biome.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
I guess I should have been more explicit in my question. As it stands, Minecraft is constrained to 256 blocks in the vertical. This makes world generation ridiculously easy compared to generating infinite blocks in the vertical (yes, yes, it's not technically infinite but 16 million fething blocks is pretty close to infinite in my book.) Minecraft assumes ~62 = water, things above water = land, and you end up with a virtual heightmap everywhere you go because of the 256 block limit. Everything above any given SURFACE block is assumed to be air, lit by the sun.
With Cuchaz's mod what determines that any given block is a SURFACE block? It's almost like you would need an actual heightmap to do so. Sure, you could build a floating island at +7 mil Y, but as far as generation goes what determines the natural landscape(s) that have actual surface blocks where, at any given point everything above it (all the way up to the limit) is assumed to be air?
I think that better sums up my interrogative!
Thanks in advance for your time.
So, I wrote my end with backwards compat being a number one concern.
Our lighting engines are probably far from similar as well, so there really isn't a good way I can replace the vanilla lighting engine if someone else did it first =) So it won't work right out of the box.
That being said, once I get my rendering pipeline sorted out, I don't think it would be that hard to target and locate similar changes to Cuchaz's lighting engine. I'd be able to use my existing framework and apply changes to blocks (which I think Cuchaz mostly left alone) the lighting engine, and saving... Everything else should remain "vanilla enough" for my end to work.
I'm excited to see how this turns out!
Edit: I'll take a look at what it will take to bridge the two. It might not be worth it, but I'm not giving this up yet!
Surface blocks and lighting; you've almost got it. First, the lighting system takes an x/z coordinate. Now it goes to some x/z coordinate and chooses a block. Are there blocks above? If yes, move to them. Are there blocks above them? If yes, move to them. And so on. Eventually, we will find a block that has no blocks above it, and now we say that this block is the top block.
Top block by definition has no solid blocks above it, and for this reason, we know that it is lit by the sun.
Of course, because of how CC works, there might actually be a block above that is not loaded into the world, and hence invisible to us. Problem? Sometimes.
Just pretend the player builds a really big building... like... a 200 block tall cave inside a mountain, pitch black inside, no sunlight of any kind can get in. Oh, but when they go down to the bottom of the cave, the game unloads the top. No top = nothing stopping the light from getting in, and suddenly their pitch black cavern is all lit up like a supernova. This is a problem.
To solve this, a height-map is pretty much what we use.
When this block is found, the game records where that block was. Now even if that block isn't loaded, it doesn't matter, because we know that it is there, and we know where it is. The result? Simple. Even if the roof of our mountain cavern isn't loaded, we know that it's there, and we know to keep the bottom of the cave dark at all times.
While the terrain generator ~can~ indicate to us where the topmost block ~might~ be, there are two problems. The first is that we can't know where the terrain actually is until we actually generate it. The second is that the terrain can change, if say the player plants a tree, or builds a house, or idek... blows up their IC2 nuclear reactor.
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
It seems to me your question has little to do with how the lighting system works and more to do with how terrain generation works. The vanilla terrain generation system is partly a black box to me, so I don't completely understand how it works. The "surface" of the world seems to be decided by generating and conditioning a whole crapton of Perlin noise, but trying to understand how those algorithms work by starting at decompiled, obfuscated code is essentially a nightmare. Razaekel is in charge of terrain generation, and I think he's working on writing a completely new cubified terrain generator. Right now, we're just hobbling along with my cubification edits on the vanilla terrain generation system. Eventually, we'll get something better.
So, how do we pick the "surface" of a world? I have no idea. =)
If I understand correctly how you made colored lights work the last time, I think you could do the same thing in my lighting system. I didn't really change How lighting works too much for cubic chunks. I mostly just changed When and Where it works.
Interesting... I change the "how", only to include other colored channels in the existing routines (excluding sunlight). Cross your fingers because we might closer to working than I thought! I'll let you know what I find when I finally get through some hurdles on my end.