Tall Worlds Mod - Raising the world height cap without causing lag
Poll: TWM needs money to continue. Would you donate to a Patreon?
TWM needs money to continue. Would you donate to a Patreon? - Single Choice
- Nope. I don't want to spend money on mods. I'd rather the mod didn't exist than pay to support development. 6.9%
- Nope. I'd be happy to donate, but I don't have any money. 52.8%
- Sure, I guess I could spare $1-$5 a month to help finish the mod. 23.6%
- Yes! I'm really excited about the mod AND I have lots of money! I could donate more than $5 a month. 13.9%
- I'm incredibly wealthy, or a potential business sponsor. I could give $100+ a month. 2.8%
Ended Feb 11, 2016
Alternatively, this mod will most likely give you the ability to lower the max build height (vanilla Minecraft already allows you to do this), so either way it shouldn't be a problem. lol
also you should check out Link Removed
Whether generating or guessing at the chunks' contents, I wanted to propose that a skyward chunk's occlusion might be something that can be approximated in a way sort of similar to mipmapping. Because a good portion of nearby chunks will be loaded anyway, and because Minecraft already smooths out skylight shadowing with distance, the lighting occlusion of distant overhead chunks could be averaged and simplified in a set of 2D data values at reduced resolution - perhaps 4x4, 2x2, and then a single value - representing the percent occlusion of that square-profiled column "pixel" from a top-down perspective*. The resolution accessed would decrease with distance, as with mipmapping, because the precision needed decreases naturally with the more heavily blurred contribution of that occlusion. By storing averaged values as with mipmapping, it's sort of pre-blurred. I imagine these value lookups would be much less computationally costly than actually having to load all chunks above.
*Minecraft allows light to go "around corners", right? eg. A serpentine, mostly vertical cave may have no direct view of the sky yet still have sky light because light is allowed to spread sideways a little, right? Then, the value of these occlusion tables might be good to compute from the block light levels at the lowest block plane of that chunk. This represents the amount of light that has passed through to the bottom of that chunk.
Also, I wouldn't propose that a chunk's occlusion table be the cumulative occlusion of it and all skyward chunks. Although it might seem like a performance benefit to only need to look up one table from the chunk immediately above the load distance, it requires more data be altered if a chunk is modified, from that chunk all the way down. Taking them one-by-one retains chunk data independence.
As with empty chunks, a shortcut can also be taken in the case of fully opaque chunks.
As for rain, well, default Minecraft rain and snow truly is a single block column's openness to the sky. There's no averaging shortcut to be found...unless rain and snow is rewritten to also be smoothed out and able to go "around corners" some. This is more realistic anyway, as rain and snow never exist in a vacuum and may be blown or drift off of a perfectly vertical descent. The question remains how to decide whether a specific block displays rain or not, but it might be easier (and more pleasing to boot) if there is implemented varying intensities of the weather FX appropriate to the amount of sky exposure.
That's what I thought they were asking. In the case of Tall Worlds Mod, vanilla Minecraft has no ability to read/write/edit the cubic chunk save files, so they would be perfectly preserved after a Minecraft update. If you tried to load a tall world in vanilla Minecraft, Minecraft wouldn't find any chunk data, so it would try to generate a completely new world and save it to a different place. But the tall world will still be there, waiting for you to install the new Tall Worlds Mod.
Yes, I think I can allow up to 65k+ of block space in the y dimension. Actually, that limitation is pretty arbitrary and I could raise it if I wanted to, but I think 65k blocks is high enough for now. Moving at minecart speed, I think it would take somewhere around 2 hours to travel that far. That's probably enough space for most maps.
Here's how I handle data storage. I use 0% of Minecraft's existing chunk storage systems. I wrote a completely new chunk storage system that uses a small database engine to get fast performance. The chunks are saved in completely different files and exist completely independently of Minecraft's region files. That means there is no chance of crosstalk between the two world formats so the chance of an accidental world deletion/override should be pretty much zero.
Of course, this means there's no backwards compatibility, but I don't really see that as a reasonable design constraint right now. I don't think there's any reason to expect that vanilla Minecraft should know what to do with a tall world.
Ah, someone finally asked about the lighting system. Here's how I handle it.
As far as I know at the moment, Minecraft needs a few pieces of information to do lighting calculations for each block. It needs the opacity and light emission of all the nearby blocks. In the case of sky light, "nearby" actually means all the blocks in the y-column. Therefore, if the height of the world is n blocks, a light update could potentially affect something on the order of n blocks.
That seems bad until you realize that all n blocks in that column are probably not going to be loaded at the same time. Really, it's just some much smaller number of blocks, say m blocks that actually need lighting updates. Only the m blocks that are near players actually need to have their lighting updated. The trick is, you still need information from all n blocks to compute the lighting update for the fewer m blocks.
How I handle this problem is to take the lighting information from the n blocks (just the block opacity seems to be all that's needed for now) and save it into a specialized data structure that is tied to the block column. No matter which cubic chunks are loaded, the supporting column must be loaded and therefore the lighting information is available too. With some simple encoding, the lighting information doesn't take up much space, and it can be queried efficiently. Then, when we want to update lighting for the m blocks, we query the data structure for lighting information about the rest of the n blocks.
I haven't done a huge amount of testing on this system yet, but it works well enough to record that demo video. I'll give it a more thorough testing later. I'm sure there are a couple bugs I need to fix.
Can't you just make a new world type so minecraft can't touch your worlds, instead of trying to go around it with a different data system?
I mean, the world gen is going to be different after the new height is applied... (Or not, that's your decision to make Cuchaz)
EDIT: I realized how stpd I've just sounded with the "Different data system" thing. Of course you have to change it... I meant that you are not forced to work with the vanilla world as a start for loading the world.
I don't think I understand your comment. If it helps clarify, we're writing new world gen code as well. There are lots of systems we have to completely replace to get tall worlds to work.
IT'S NOT HIGH ENOUGH
Seriously though, nothing is too high as long as it doesn't cause bugs.
also you should check out Link Removed
What I mean is that, you can make a new world type like biomes o' plenty and other mods do (ie: BIOMESOP World type, AMPLIFIED)
This is just an idea because you want to change world gen, and it would be easier to go between versions if you just saved it in a different format (So minecraft doesn't try to load it without mods), like amplified saves with the double height, you can't load it as a 256 world. (Or can you? I don't know really)
What.... 16 million??? 65 thousand is already to space in the real world! I couldn't imagine anyone even flying up to the 50k mark. Well, certainly no more block limit worries...
Keep on coding Cuchaz!
Yeah, it's more space than anyone needs, but I might as well max out whatever resources we have available for these things.
Computing cube visibility would be really cool. I don't think Minecraft does this at all yet. If we did get some kind of visibility system working, it would effectively raise the draw distance for players without adding extra lag. I might be interested in doing something like that, but I need to get the basic system working first. That's still a work in progress. =)
I will bring across some simple ideas I and others posted on the CC suggestion thread [timestamp and "solid/empty" chunk ideas are mostly from others, ideas about occluded chunks are mine]
Solid chunks, empty chunks, rendering and loading optimization.
This opens up a couple of nice optimizations.
For each chunk, we check the adjacent chunks. If all 6 faces are touching solid chunks (or solid faces), then the chunk is "completely invisible". You cannot see it no matter where you look from. However, observe that no more than three faces of a cube can be seen at once, and it is very easy to determine ~which~ faces from the perspective alone. This means that, in practice, even if only the relevant three faces of a chunk are adjacent to solid chunks/faces, then we can safely assume that everything in that chunk is invisible to the player.
We can expand this "obscured face" logic even further, however the complexity increases exponentially. For example, if the player is surrounded by solid chunks/faces, then they can't see ANYTHING around them (aka if they are underground in a mine). This means that we can adjust view distances dynamically using rough estimates of how much the player can actually see.
I don't need to explain how this is useful. If chunks are air, we can send (and process) them as a giant single block (vs 4096 blocks). We can do a similar thing if the chunks are solid. If the chunks are far away and obscured, well... we hardly even have to bother with them until they aren't far away anymore.
Block updates in loaded and unloaded regions of the world.
Using a Cubic system, however, all the chunks are tiny. While it takes the same CPU load to process all of them, the size of the chunks allows us to not only ignore and neglect some parts of the world, but also perform calculations on a few very distant chunks (since you can load 16 cubic chunks at the same cost of loading one vanilla chunk)
This can be taken one step further using a delayed update system. Essentially: why update a furnace every tick when the player is 150 blocks away? All that matters is that when the player comes back in 4 hours time, their stuff has been smelted. Given this, can't we just compact the updates? Why not just update the furnace by 10 seconds, once every 10 seconds? Why not just measure how long the player was gone for, and then just do the updates all at once when the player comes back?
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
If I start working on a visibility system for cubes, it will probably work something like that. Except I'd also try to compute visibility even when cubes aren't completely solid or completely air.
As for the block ticking when cubes are unloaded, I'm not planning to implement anything like that. I think it's outside of the scope of this mod. Someone could make another mod that does it though. Perhaps an easier solution though is to make a special block that you can place next to your smelters that keeps that cube from unloading. That's something a mod could definitely do pretty easily.
Have you tried implementing advanced performance techniques, like; frustum culling, geometry instancing, occlusion queries, level of detail (LOD)?
Nope, not yet. Those would be cool to have some day though.
Yeah, notch needs to make add those, and make his occlusion queries better.. anyway is you wan't here is frustum culling tutorial, very easy to follow: http://www.crownandcutlass.com/features/technicaldetails/frustum.html
I'm pretty sure Minecraft already does frustum culling for terrain rendering. You wouldn't want frustum culling in the chunk loader itself anyway. It's only useful as a rendering optimization.
Thats why it happens in minecraft rendering engine. Does minecraft use glCullFace(GL_BACK); already? Also, since you already created a custom chunk system, have you thought of taking minecraft's tesselator and making it use the more efficient VBO's and IBO's, this would also allow for easy implementation of geometry instancing.
Rendering optimizations are well beyond the scope of what I'm trying to do with this mod. I certainly don't want to rewrite the tesselator. I'm just focusing on chunk management to raise the world height.