I can see some problems where someone goes caving, walks into unexplored chunks, and a ravine has sunlight in it for a second before the roof loads. On lower render distances, the roof may never load.
That problem has nothing to do with render distance. Even if the roof of a huge cave is out of view (but has still been generated on the server) the cave will light correctly.
That problem has nothing to do with render distance. Even if the roof of a huge cave is out of view (but has still been generated on the server) the cave will light correctly.
What if the chunks above have not been generated? How will it tell what the lighting should be?
Rollback Post to RevisionRollBack
I'm not active on these forums, so forgive me if I don't respond!
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
I would suggest that the server have a load distance separate from that of the client, much like what was present in 1.6 and earlier. This way, the server can calculate lighting and still send lighting information accurately to clients with small render distances. This server distance would be a small number, probably along the lines of four to five chunks, only so that larger caves initially loaded will not overstress on lighting. The scenario I'm seeing is where a player is going mining, stumbles across a ravine that happens to be in unexplored chunks. The ravine being deep, and the player having a tiny render distance, the bottom of the ravine is lit despite being underground. This would also apply to reasonably-sized mountain overhangs, especially on slower CPUs.
This is assuming that the lighting is calculated by the server and sent to the client.
Now, hopefully, this system will place less stress on the server so that it can quickly call new chunks and calculate light effectively and without error in reasonable situations.
I don't think you guys are understanding what I'm saying. Let me try again.
For any given point in time, let's say "the world" is the set of all chunks that have been generated and does not include any chunks that have not been generated yet. That means, everything you have currently explored is "the world." Bits that you have not explored yet are not in "the world."
The way I wrote the lighting engine, "the world" will always be lit correctly regardless of which chunks are currently loaded in memory on the client or the server. I do some fancy tricks to make this happen, and it's not obvious that I can do this correctly if you only consider naive solutions to the lighting problem in a cubicly chunked world.
This means that if you're in a huge cave, it will always be lit correctly as long as the server knew at any point in time the roof of the cave existed. Even if you can't see the roof of the cave right now (even if the roof is not loaded on the server OR the client), it will still be lit correctly as long as the server generated the roof as some point in time before now. The correctness of the lighting engine has nothing to do with which chunks are currently loaded in memory. It only depends on which parts of the world the server has ever known about.
I don't think you guys are understanding what I'm saying. Let me try again.
For any given point in time, let's say "the world" is the set of all chunks that have been generated and does not include any chunks that have not been generated yet. That means, everything you have currently explored is "the world." Bits that you have not explored yet are not in "the world."
The way I wrote the lighting engine, "the world" will always be lit correctly regardless of which chunks are currently loaded in memory on the client or the server. I do some fancy tricks to make this happen, and it's not obvious that I can do this correctly if you only consider naive solutions to the lighting problem in a cubicly chunked world.
This means that if you're in a huge cave, it will always be lit correctly as long as the server knew at any point in time the roof of the cave existed. Even if you can't see the roof of the cave right now (even if the roof is not loaded on the server OR the client), it will still be lit correctly as long as the server generated the roof as some point in time before now. The correctness of the lighting engine has nothing to do with which chunks are currently loaded in memory. It only depends on which parts of the world the server has ever known about.
I believe what Pixel robot was saying is say you dig down to y: -200 (y: 0 is sea) then start tunneling North til u reach ungenerated chunks if you entered a cavern where the roof was to high in comparison to your render distance, hence would not generate
would the area you are in be dark or light?
Considering what was said about floating island, "if they aren't generated they don't cast a shadow" the answer would be yes the cavern was lit, because Minecraft doesn't know the roof existed.
So to resolve this Pixel_Robot was Proposing that you apply the rules,
I believe what Pixel robot was saying is say you dig down to y: -200 (y: 0 is sea) then start tunneling North til u reach ungenerated chunks if you entered a cavern where the roof was to high in comparison to your render distance, hence would not generate
would the area you are in be dark or light?
Considering what was said about floating island, "if they aren't generated they don't cast a shadow" the answer would be yes the cavern was lit, because Minecraft doesn't know the roof existed.
So to resolve this Pixel_Robot was Proposing that you apply the rules,
All areas above Y:0 Lit until proven otherwise
All areas below Y:0 dark until proven otherwise
wow you really explained it better than me thanks
Rollback Post to RevisionRollBack
sorry if my English have mistakes it's not my main language
there's a very simple solution to the current issue being discussed, because the sea level is Y=64, then the blocks of Y=64 will always be occupied, and therefore no (or little) light can get through, and so, you simply make it dark by default at Y=64 and below. Simple, also, did noone else see that he said that the chances of huge caves are near impossible?
there's a very simple solution to the current issue being discussed,
1: because the sea level is Y=64,
2: then the blocks of Y=64 will always be occupied, and therefore no (or little) light can get through, and so, you simply make it dark by default at Y=64 and below.
3: Simple, also, did noone else see that he said that the chances of huge caves are near impossible?
That annoying dude. i gotta laugh when reading that name, Edit: i'm not insulting you its just you challenged my view points hence annoying
1: In Vanilla Y:64 may be sea level and i was well aware of that but, in cuchaz tall worlds Y: 0 is sea level.
2: Nope not true caves go down through sea level and often open onto the surface.
3: I believe we were discussing this in terms of larger terrain gen, as a large amount of people my self included would love to see some fancier terrain generators added and it would simply be better if Tall worlds was coded to allow that from the start.
Also nobody wants it to be completely dark below sea level that would be silly, rather it needs to be dark until proven otherwise
see image below if you still think its a good idea to have it constantly dark below sea level
I really like the Y>=0 = Sunlight and Y<0 = NO Sunlight [UNTIL PROVEN otherwise] rule, or at least a selectable option to activate it. I think it could work hand-in-hand with and make a great addition to the heightmap lighting persistence of memory Cuchaz has built in to Tall Worlds already.
Aside from that it would be Incredible if the following tool/service could be added to Tall World's functionality:
Terrain Pre-Generation (with selectable x,y,z ranges) = Able to use even after the world has been started, so long as it is currently offline.
This would be especially useful for servers as it would smooth out server performance during playtime, especially since many servers set outer boundary limits too. This could also, with selectable y range, insure that even with large terrain=on the lighting would always be as accurate as anyone could hope for.
I would love to have the feature for single-player use too.
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.
That annoying dude. i gotta laugh when reading that name, Edit: i'm not insulting you its just you challenged my view points hence annoying
1: In Vanilla Y:64 may be sea level and i was well aware of that but, in cuchaz tall worlds Y: 0 is sea level.
2: Nope not true caves go down through sea level and often open onto the surface.
3: I believe we were discussing this in terms of larger terrain gen, as a large amount of people my self included would love to see some fancier terrain generators added and it would simply be better if Tall worlds was coded to allow that from the start.
Also nobody wants it to be completely dark below sea level that would be silly, rather it needs to be dark until proven otherwise
see image below if you still think its a good idea to have it constantly dark below sea level
my name was the result of a bad choice of a nine-year-old... also,
1) the sea level I said as 64, was not that it should be there, but just as an example.
2) I meant that they would all be blocks, except for where the caves generate through, and the caves generating through wouldn't affect it, because when you can see the cave, it will have been updated by the light of the chunk above it
3) it wouldn't be permanently dark there, just dark when the world generates, also, that picture is entirely irrelevant, due to the fact that caves are by default, dark, whereas the surface should be by default, light.
The Meaning of Life, the Universe, and Everything.
Location:
Wumpis
Join Date:
12/25/2010
Posts:
226
Location:
Grumpis
Minecraft:
teknonick
Xbox:
No.
Member Details
I believe ThatReallyAnnoyingDude has come up with the solution. By default, the world is always bright... until proven otherwise. Just do that, but under x number(64, 0, whatever...) under the Y axis, it is always dark UNLESS proven otherwise. So, you enter into a cavern... and it's pitch black instantly. If the roof above it generates later... say... and it turns out said roof goes up to the surface, so sunlight comes down, THEN the cave would light up after that has generated.
Rollback Post to RevisionRollBack
"Jesus Christ now I realize how messed up I've made my characters....." -booksmusicanime, after writing a "Thought Experiment" post.
"Code Lyoko was such a badass show." - Morgan Elliott from Twitter, after agreeing with me that they should add Odd's hair into TUG!
Your approach wouldn't solve the problem, it would merely catch some cases. Imagine digging straight down to level -1000, then digging horizontally for 1000 blocks and you hit a cavern. In this instance, your algorithm would decide not to illuminate the cave, because you're below level 1000. But what if the cave is in fact a huge hole reaching up to the surface? There are no constraints giving the world generator any clues about whether a newly generated chunk is lit or not and while introducing your rule would solve lots and lots of cases, there would still be loads in which it wouldn't work out.
I haven't been weighing in on the lighting discussion much anymore, because I think the discussion is largely theoretical right now, but basically this. ^^
Your
approach wouldn't solve the problem, it would merely catch some cases.
Imagine digging straight down to level -1000, then digging horizontally
for 1000 blocks and you hit a cavern. In this instance, your algorithm
would decide not to illuminate the cave, because you're below level
1000. But what if the cave is in fact a huge hole reaching up to the
surface? There are no constraints giving the world generator any clues
about whether a newly generated chunk is lit or not and while
introducing your rule would solve lots and lots of cases, there would
still be loads in which it wouldn't work out.
if you want to dig out 4000 blocks just to prove a point, go for it, I ain't stopping ya, also, the more cases it solves, the better, right?
It would be really cool if this mod would work with Biomes O' Plenty; does anyone think that Tall worlds mod could work with a whole different terrain generator with differents blocks/entities?
(however it would probably be best if Cuchaz just gets a working release for vanilla minecraft for now and work on mod incompatibilities later) but still, It would be really cool if TWM could work with external terrain generators in the future...
It would be really cool if this mod would work with Biomes O' Plenty; does anyone think that Tall worlds mod could work with a whole different terrain generator with differents blocks/entities?
(however it would probably be best if Cuchaz just gets a working release for vanilla minecraft for now and work on mod incompatibilities later) but still, It would be really cool if TWM could work with external terrain generators in the future...
The first release will be incompatible with all other mods.
If/when other mods are be compatible with m3l - new biomes would probably work, but without new trees, plants and some other features (at least without modifying Biomes O'Plenty). Mods that add new blocks to terrain generation will most likely not work (But that's not impossible - blocks from other mods worked in Robinton's CubicChunks, a long time ago I tested it with Minecraft 1.0 and some "more ores" mod).
I'm almost sure that it will be possible to write new terrain generators for Tall Worlds (but not for the initial release)
It would be really cool if this mod would work with Biomes O' Plenty; does anyone think that Tall worlds mod could work with a whole different terrain generator with differents blocks/entities?
(however it would probably be best if Cuchaz just gets a working release for vanilla minecraft for now and work on mod incompatibilities later) but still, It would be really cool if TWM could work with external terrain generators in the future...
There is currently a working release out for alpha testing available to all $10+ donors
https://www.patreon.com/cuchaz is the link if you wanna donate, i donated pretty much for that solely, although the other stuff is cool i am a fan of early access.
PS: I said about 5 days ago that it would be out in a week or two even though they hadn't set a date so i totally called that.
Whenever you write an algorithm to solve a problem you should always write it as general as possible. Whenever you start adding special clauses to catch some remote artifacts, you increase the complexity, which will harm your project in the long run. Ideally, you want an algorithm that is capable of handling every possible case without doing any case differentiation.
Edit: Additionally, implementing this into the chunk system would impose a restriction onto alternative world generators. A generator creating floating island worlds without a usual over world would end up being restricted to using coordinates 0+ because islands generated further down would end up being dark. The only way of implementing your idea at all would therefor be adding it as part of the world generator, not the chunk system.
it isn't that complex, it's just:
on generate{
if y < 0 then {
sunlight = 0
}
}
or something like that. that's basically ineffectual on how quickly it runs
From what I know the Tall Wolrds lightening system dosn't determine if a block is lit by daylight or not on generation but loading. When generating a block in a chunk there is simply something like this:
if (celing(x,z)<=y or celing(x,z)==null) and isBlock(x,y,z) then
{
celing(x,z)=y
}
Something similar is also invoked when modifying blocks, just a bit more code to check and update the celing if the celing gets removed.
where celing is a two dimensional array containging the highes known block for each X-Z-coordinate.
loading then only invokes something like this
if celing(x,z)<=y or celing(x,z)==null then
{
renderSunlight()
}
what some suggested would affect only the loading part:
if celing(x,z)<=y or (celing(x,z)==null and y>=0) then
{
renderSunlight()
}
The idea is quite nice and has my support, thought with normal cave generation it problably won't make any difference. Even on the smallest render distance this shouldn't happen that often (32 block high caves are definitly not common, atleast in vanilla generation). The only way to further improve it would be to fully generate all chunks above to check for a celing, that howerver is far more complex and needs far too much resources to be practiable. The game simply has no way to know if there will be a block above the current position or not without first generating those chunks, this gets even worse when other mods come into play.
That last part is something else I have been saying the entire time, it's not really that relevant in the first place to have the coding for that in place, even if my way is feasible, it was simply provided as a way to rectify the situation if people thought it was too much of an issue (which it clearly isn't, considering it's near impossible).
That problem has nothing to do with render distance. Even if the roof of a huge cave is out of view (but has still been generated on the server) the cave will light correctly.
What if the chunks above have not been generated? How will it tell what the lighting should be?
If you want to contact me, try going through Discord or you can find me on GitHub where I am still updating the below mods (and more):
PRESENCE FOOTSTEPS - (github)
VOID FOG - (github)
The lighting will be determined by the chunks that have already been generated. Chunks that have not been generated can never be used for lighting.
I would suggest that the server have a load distance separate from that of the client, much like what was present in 1.6 and earlier. This way, the server can calculate lighting and still send lighting information accurately to clients with small render distances. This server distance would be a small number, probably along the lines of four to five chunks, only so that larger caves initially loaded will not overstress on lighting. The scenario I'm seeing is where a player is going mining, stumbles across a ravine that happens to be in unexplored chunks. The ravine being deep, and the player having a tiny render distance, the bottom of the ravine is lit despite being underground. This would also apply to reasonably-sized mountain overhangs, especially on slower CPUs.
This is assuming that the lighting is calculated by the server and sent to the client.
Now, hopefully, this system will place less stress on the server so that it can quickly call new chunks and calculate light effectively and without error in reasonable situations.
Putting the CENDENT back in transcendent!
just an idea i had what if you set the sunlight to 0 under a certain y
i mean what's the chances that there is sunlight under y100 or 1000
it only happens if someone digs straight down for too long and in my opinion sunlight in minecraft shouldn't travel that far underground
that way the problems your discussing will be mostly gone
i think it'll be best if you do that at y 200 or 150 but after all it's your choice
sorry if my English have mistakes it's not my main language
I don't think you guys are understanding what I'm saying. Let me try again.
For any given point in time, let's say "the world" is the set of all chunks that have been generated and does not include any chunks that have not been generated yet. That means, everything you have currently explored is "the world." Bits that you have not explored yet are not in "the world."
The way I wrote the lighting engine, "the world" will always be lit correctly regardless of which chunks are currently loaded in memory on the client or the server. I do some fancy tricks to make this happen, and it's not obvious that I can do this correctly if you only consider naive solutions to the lighting problem in a cubicly chunked world.
This means that if you're in a huge cave, it will always be lit correctly as long as the server knew at any point in time the roof of the cave existed. Even if you can't see the roof of the cave right now (even if the roof is not loaded on the server OR the client), it will still be lit correctly as long as the server generated the roof as some point in time before now. The correctness of the lighting engine has nothing to do with which chunks are currently loaded in memory. It only depends on which parts of the world the server has ever known about.
I believe what Pixel robot was saying is say you dig down to y: -200 (y: 0 is sea) then start tunneling North til u reach ungenerated chunks if you entered a cavern where the roof was to high in comparison to your render distance, hence would not generate
would the area you are in be dark or light?
Considering what was said about floating island, "if they aren't generated they don't cast a shadow" the answer would be yes the cavern was lit, because Minecraft doesn't know the roof existed.
So to resolve this Pixel_Robot was Proposing that you apply the rules,
Be involved in the Survival of Modding in the Post-Notch Era. Enigma + M3L + LiteLoader/API + BlazeLoader {ALL Open-Source!}
wow you really explained it better than me thanks
sorry if my English have mistakes it's not my main language
there's a very simple solution to the current issue being discussed, because the sea level is Y=64, then the blocks of Y=64 will always be occupied, and therefore no (or little) light can get through, and so, you simply make it dark by default at Y=64 and below. Simple, also, did noone else see that he said that the chances of huge caves are near impossible?
That annoying dude. i gotta laugh when reading that name, Edit: i'm not insulting you its just you challenged my view points hence annoying
1: In Vanilla Y:64 may be sea level and i was well aware of that but, in cuchaz tall worlds Y: 0 is sea level.
2: Nope not true caves go down through sea level and often open onto the surface.
3: I believe we were discussing this in terms of larger terrain gen, as a large amount of people my self included would love to see some fancier terrain generators added and it would simply be better if Tall worlds was coded to allow that from the start.
Also nobody wants it to be completely dark below sea level that would be silly, rather it needs to be dark until proven otherwise
see image below if you still think its a good idea to have it constantly dark below sea level
Be involved in the Survival of Modding in the Post-Notch Era. Enigma + M3L + LiteLoader/API + BlazeLoader {ALL Open-Source!}
I really like the Y>=0 = Sunlight and Y<0 = NO Sunlight [UNTIL PROVEN otherwise] rule, or at least a selectable option to activate it. I think it could work hand-in-hand with and make a great addition to the heightmap lighting persistence of memory Cuchaz has built in to Tall Worlds already.
Aside from that it would be Incredible if the following tool/service could be added to Tall World's functionality:
Terrain Pre-Generation (with selectable x,y,z ranges) = Able to use even after the world has been started, so long as it is currently offline.
This would be especially useful for servers as it would smooth out server performance during playtime, especially since many servers set outer boundary limits too. This could also, with selectable y range, insure that even with large terrain=on the lighting would always be as accurate as anyone could hope for.
I would love to have the feature for single-player use too.
- 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
my name was the result of a bad choice of a nine-year-old... also,
1) the sea level I said as 64, was not that it should be there, but just as an example.
2) I meant that they would all be blocks, except for where the caves generate through, and the caves generating through wouldn't affect it, because when you can see the cave, it will have been updated by the light of the chunk above it
3) it wouldn't be permanently dark there, just dark when the world generates, also, that picture is entirely irrelevant, due to the fact that caves are by default, dark, whereas the surface should be by default, light.
I believe That
ReallyAnnoyingDude has come up with the solution. By default, the world is always bright... until proven otherwise. Just do that, but under x number(64, 0, whatever...) under the Y axis, it is always dark UNLESS proven otherwise. So, you enter into a cavern... and it's pitch black instantly. If the roof above it generates later... say... and it turns out said roof goes up to the surface, so sunlight comes down, THEN the cave would light up after that has generated."Jesus Christ now I realize how messed up I've made my characters....." -booksmusicanime, after writing a "Thought Experiment" post.
"Code Lyoko was such a badass show." - Morgan Elliott from Twitter, after agreeing with me that they should add Odd's hair into TUG!
I haven't been weighing in on the lighting discussion much anymore, because I think the discussion is largely theoretical right now, but basically this. ^^
if you want to dig out 4000 blocks just to prove a point, go for it, I ain't stopping ya, also, the more cases it solves, the better, right?
It would be really cool if this mod would work with Biomes O' Plenty; does anyone think that Tall worlds mod could work with a whole different terrain generator with differents blocks/entities?
(however it would probably be best if Cuchaz just gets a working release for vanilla minecraft for now and work on mod incompatibilities later) but still, It would be really cool if TWM could work with external terrain generators in the future...
The first release will be incompatible with all other mods.
If/when other mods are be compatible with m3l - new biomes would probably work, but without new trees, plants and some other features (at least without modifying Biomes O'Plenty). Mods that add new blocks to terrain generation will most likely not work (But that's not impossible - blocks from other mods worked in Robinton's CubicChunks, a long time ago I tested it with Minecraft 1.0 and some "more ores" mod).
I'm almost sure that it will be possible to write new terrain generators for Tall Worlds (but not for the initial release)
Cubic chunks discord server
There is currently a working release out for alpha testing available to all $10+ donors
https://www.patreon.com/cuchaz is the link if you wanna donate, i donated pretty much for that solely, although the other stuff is cool i am a fan of early access.
PS: I said about 5 days ago that it would be out in a week or two even though they hadn't set a date so i totally called that.
Be involved in the Survival of Modding in the Post-Notch Era. Enigma + M3L + LiteLoader/API + BlazeLoader {ALL Open-Source!}
it isn't that complex, it's just:
on generate{
if y < 0 then {
sunlight = 0
}
}
or something like that. that's basically ineffectual on how quickly it runs
That last part is something else I have been saying the entire time, it's not really that relevant in the first place to have the coding for that in place, even if my way is feasible, it was simply provided as a way to rectify the situation if people thought it was too much of an issue (which it clearly isn't, considering it's near impossible).