Gameplay
Cubic Chunks: Reduced lag, infinite height, and more [The #1 Suggestion Thread of all time!][Updated! 6/14]
Poll: Which parts of this system do you like?
Ended May 15, 2014
Poll: Which parts of this system do you NOT like?
Ended May 15, 2014
Poll: Do you support this system's implementation overall? (If yes, if
Ended May 15, 2014
Space: noun: "the dimension of height, depth, and width within which all things exist and move"
xp
Me too.
Not exactly true. There are different sizes of infinity when you get into the math. Anyway, not the point.
As I said, by having a fixed maximum height at 0, it allows a shadow map to be saved with each chunk. The shadow map itself just has to be two dimensional reflecting the bottommost light level. When a chunk generates, it only has to look at the shadow map above itself, it doesn't have to calculate any higher than that.
When a shadow map updates, it can poll the neighbor below it to recalculate. If that neighbor's shadow map doesn't change as a result then the update ends, otherwise it continues through any loaded chunks.
When a chunk loads, it checks the shadow map above it and recalculates if necessary. Keeping things always up-to-date.
The updates can be done in columns so that if only say 2 blocks on the shadow map change, the entire chunk doesn't have to recalculate, only the effected columns.
The increase in data size, assuming 16x16 chunk with 16 light levels is only 128bytes per chunk.
not a perfect solution, but certainly one that handles "infinity" quite well as long as you know where the ceiling is (0 depth)
While infinite is thrown around a lot, the world limits are actually +-32,000,000 in all directions with cubic chunks, making the ceiling 32,000,000, that is why offsetting terrain does not make a difference as we already have a clear ceiling and floor for handling shadows from.
The shadow solution does not work in the event of massive overhangs outside of chunk distance that the player has yet to visit(since the chunks don't exist yet.)
If the overhang is that far away it stops being a meaningful shadow source anyway since ambient light would bleed in.
The solution is "close enough". There's no perfect solution to this issue, so the real question is where do you make sacrifices to reach a "close enough" decision.
On a default minecraft server, the load distance around a player is 10 chunks(160 meters). A giant overhang 160 meters above you would make a shadow.
space would be nice. a good thing for mods to build on. this would be cool.
support
also you should check out Tall Worlds
You can't prove this. No lighting system can prove it either. You assume ambient light would bleed in, but you make assumptions on the nature of the overhang, when the reality could very well be that that 'overhang' is the ceiling of a giant cavern and there's cave walls you can't see. Suddenly you think you're above ground until you move around a little and find out that you're in a magical cave that stays completely bright as long as you stay on the floor.
You might want to put the "sunlight calculation" stuff in the OP in red. Just a thought.
Also, magical caves rule! xp
He should also read the part about keeping shadow maps stored as part of the chunk, and acceptable compromises for an inherently imperfect situation.
However those shadow maps only exist for loaded chunks, which if the caves roof has never been loaded would be a giant bug in the lighting system and unacceptable since mojang will only seriously consider this if it is as functional as the current lighting system.
Unless caves (or rather large caverns) were made to be their own biome. Then it could carry a flag to skip sunlight in the lighting system. This could be done for any subterranian biome, unless there remained a chance that a subterranian biome would intersect with the surface of the overworld.
also you should check out Tall Worlds
To clarify, is the problem here any light calculations or only sunlight calculations?
Surely light sources have no problem with infinite height given that they are by default limited in range, and a maximum light level of 16 at that. (Which translates to 16 blocks range at most if I understand it all correctly).
So, working on the assumption that we are referring to a sunlight calculation problem:
The problem.
Unknown (Ungenerated/unloaded) chunks more than X away might affect sunlight calculation for current block that needs to update its sunglight calc.
Current method of sunlight propogation.
Sunlight propogates only straight down. (i.e. Unknown chunks only influence light if they are above the currently calculating position ).
Sunlight is blocked by non-transparent objects.
To determine initial sunlight start conditions sunlight has to be iterated from the top of world down to block/chunk location.
Current Minecraft method for solving the problem.
Limit maximum column height to a value less of 256.
( Avoid lag for really tall world generation )
Generate entire height range of world upon chunk generation.
(I.e. make sure there are no unknown chunks/blocks between the currently calculating position and the top of world )
Calculate initial sunlight condition of all blocks as iterated from top of world.
(Once this is achieved, a chunk system can work perfectly well. The crux lies in getting to an initial sunlight 'map' per chunk.)'
Sunlight is then stored in some fashion per chunk. Eliminating the need to reiterate all the way to top of world for sunlight updates. (At least I think Minecraft does this. Not sure though. It really should, even when not doing infinite height chunks.)
Other methods for solving the problem.
Optimise light update calculation, allowing for greater world height before lag occurs.
Adjust methods of sunlight propogation to eliminate the need to iterate from top of world to current position in order to determine sunlight level.
Adjust method of chunk generation to eliminate need to fully generate a chunk in order to determine its impact upon sunlight level.
Optimising light update calculation.
I cannot say much here, other than it would at best extend the maximum height of the world. Not scale to effective infinity.
Adjusting methods of sunlight propogation.
Allowing sunlight to propogate sideways would to some degree alleviate the problem of having to calculate all the way from top of world down to current position.
What advantages it does provide:
- More natural propogation of light ( an object will not cast a shadow the same size all the way down to inifinity ).
What it will not do:What I would suggest here:
If a block called Dark-y cannot see sunlight, but has at least 3 transparent blocks above it (air counts), and at least one column called Share-y adjacent to it (starting at the same height) that is at least 4 tall and can see sunlight in all its blocks, then Darky is boolean set to 'can see sunlight'.
I.e. Sunlight propogates sideways at a steep angle (4:1 ratio), of verticle to horizontal.
Adjust chunk/world generation (I.e. Pre-generate chunk metadata).
I think this would be the way to go in order to solve the unknown chunk problem.
Essentially, you generate metadata (data describing data) of chunks far further out (or specifically UP) that you actually generate the chunk contents for.
Metadata only really needs to define what biome type the chunk is, and not its contents. So this should be far less processing intensive than fully populating said chunks.
From the biome type (I.e. what biome type will cover 50% or more of this chunk), you can then make a reasonable guess as to if the chunk would prevent sunlight passing or not.
If a chunk is determined as blocking sunlight, you can then mark sunlight map of the chunk(s) below it as having all 0 sunlight levels. From there on, you can calculate the actual sunlight levels (and updates from horizontal sunlight propgation, if allowed) when you do the normal chunk generation and are filling the chunks in with blocks as the user approaches them for the first time.
What advantages it does provide:
- Provide a means for best guessing sunlight levels for far overhead chunks, without adding much memory or processor overhead.
What it will not do:- Prevent all shadow anamolies for exceeding large overhead objects. (I.e. if the object is horizontally larger than the pre-load metadata generation phase range, then expansive shadow anomolies could occur.)
It is still a compromise, but then so is the current Minecraft system, as would be any other system possible.For example:
For Sir Digswell current render distance, the game normally generates a chunk once the he gets within 10 chunks of it. Calculating it all from the ground up to sky, and doing the sunlight calculations.
However, in this system once Sir Digswell gets within 30 chunks of a chunk, the game already rolls the perverbial world seed dice and determines the biome type of the said chunk.
Sir Digswells decides to build a tower of cobble straight up and see what space is like.
He starts ascending.
Particularly, chunk Floaty-Miss-SkyIsland determines it is an sky biome. According to the biome dictionary it is likely to be a sunlight blocker.
Floaty-Miss-SkyIsland is currently 30 chunks above Sir Digswell. Floaty-Miss-SkyIsland then tells then sets her own sunlight map to all 16, and tells all the air-chunks (those silly puffheads) to set their sunlight maps to all 0. Turning them all into goths.
Now, since some of those air chunks are within 10 chunks of Sir Digswell, and thus fully generated, they can run updates to their light levels and determine if the various blocks can see sunlight or not based on nearby adjacent blocks.
Sir Digswells tower of great space escaping +5 reaching higher, bringing him within 10 chunks reach of the first of the gothy air chunks. The air chunk now does its normal chunk generation, filling itself with blocks (if applicable) and doing lighting updates.
Since there are 20 air chunks below Floaty-Miss-SkyIsland, the majority of them at the bottom will resolve themselves into 'can see sunlight' if horizontal propogation is allowed.
Only the last few air chunks would stay dark, and only resolve into their final sunlight values once Floaty-Miss-SkyIsland is chunk generated for the first time and resolved in terms of sunlight calculation.
However, given that the chunks had their sunlight levels pre-resolved to some degree, the change should be minimal, and given that the change gets resolved before the user gets close (especially on larger rendering distances), the change should not be obvious.
It's the flying cutlery that stresses me out.
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
also you should check out Tall Worlds
No, you got it right. Thats what the Anvil system does.