Don't like worlds 256 times as tall as before? Don't build that high!
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
Rollback Post to RevisionRollBack
if the colors in my posts don't make sense don't worry about it
Link Removed
also you should check out Link Removed
I remember that it stood unsolved how to handle sky occlusion by unloaded (possibly ungenerated) chunks. Well, clearly ungenerated chunks cannot be considered unless the terrain generation algorithm can be sampled/integrated by itself faster than fully generating the chunks.
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.
There can't be any shortcuts, this was discussed on the CC thread, a requirement of the new lighting system is that it must work better in every aspect to the old one. No guesses, no shortcuts, etc. We already have a height-map solution in which the top block in each column is used to calculate light from.
I think they're trying to say that if a person had to update Minecraft after using this mod, everything above Y:255 (or was it Y:256? I can't remember) in a world where this mod was used would be gone. That is, if they don't install an update to the mod.
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.
If you got this working it would be amazing! I've been following the development of the Cubic Chunks mod for a while now and it looks promising. Raising the height limit to something within the range of Earth's mountains (up to ~8800m) would be fantastic. 65k+ blocks of build space is even more impressive. Keep up the good work!
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.
Data storage is a GREAT example. You as a mod writer have a couple ways to do this. Modify the current world save, and expand a single player world save file to N dimensions, reformatting the current system. This would "remove" backwards compatibility as the new file format that you create wouldn't be able to interface with the old format. Or, You can try to stack the old format on top of itself (along the y dimension) making save files giant pancakes 256 blocks tall all stacked on top of each other. So 0-256 would put you in pancake 1, but 256-512 would put you in pancake 2! If you do this right, you can leave the OLD save data in tact, and then a vanilla client can still talk to the first pancake just fine! That, and it will make network transfer a bit easier for the first iteration....... Sure, you can start messing around with how stuff is moved and loaded, but it's up to you how to store the data. If you do it well, then it will interface with other systems (including vanilla) because you left the source material looking the same. Now, the big changes have to occur when and how you save and load. But, that's OK! You have to change saving and loading specifically when it comes to chunk data, and no one expects you do it any other way. You can even change how data is represented in memory. as long as you keep the calls to world looking the same. If I call world.getBlockMetadata(arguments), I'd hope to be able to use this on vanilla or cubic systems. It's totally possible, and keeps everything working! This kind of thought process is independent of M3L or Forge. That's all I'm saying. You've been doing a great job! Keep it up!
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.
I remember that it stood unsolved how to handle sky occlusion by unloaded (possibly ungenerated) chunks. Well, clearly ungenerated chunks cannot be considered unless the terrain generation algorithm can be sampled/integrated by itself faster than fully generating the chunks. 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.
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.
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.
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.
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.
In other news, recent internal changes have raised the target height cap to about 16 million blocks. Although, honestly I don't think anyone will ever build that high. 65k would have been plenty of room for anyone, but after some internal reorganization of the code, we can allocate more space to y coordinates now.
In other news, recent internal changes have raised the target height cap to about 16 million blocks. Although, honestly I don't think anyone will ever build that high. 65k would have been plenty of room for anyone, but after some internal reorganization of the code, we can allocate more space to y coordinates now.
16,777,216? IT'S NOT HIGH ENOUGH
Seriously though, nothing is too high as long as it doesn't cause bugs.
Rollback Post to RevisionRollBack
if the colors in my posts don't make sense don't worry about it
Link Removed
also you should check out Link Removed
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.
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)
In other news, recent internal changes have raised the target height cap to about 16 million blocks. Although, honestly I don't think anyone will ever build that high. 65k would have been plenty of room for anyone, but after some internal reorganization of the code, we can allocate more space to y coordinates now.
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...
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.
I've been playing around with the idea of a mod based on the Blame! comic book. For such a mod to be implemented it requires a very tall world. 16 million blocks should be enough
Also I just thought of something. If chunks are cubic then I wonder if there's some way to keep track of which chunks are visible from which chunk. Instead of iterating over the world, you would iterate over a list of chunks visible to the player, and those chunk lists are stored inside world chunks, recomputed whenever.
The problem would be to figure out a way to compute these lists.
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.
Foundation stuff: If a cubic chunk is filled with solid blocks, it gets the "solid" tag. Expanding things, you can work with the 6 faces of each chunk to see whether they are solid. Similarly if a chunk contains only air, it becomes "air" or "empty".
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.
A big problem with MC is block updates. Lots of updates = not lots of fps, and this seriously hampers the size of the world we can actually work with. It also means that things stop happening when we move far away.
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 will bring across some simple ideas I and others posted on the CC suggestion thread
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.
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)?
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.crownandc...ls/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.
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.
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.
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.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat'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.
Click Please!
Viva Argentina!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI 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.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIT'S NOT HIGH ENOUGHSeriously 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)
Click Please!
Viva Argentina!
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!
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYeah, it's more space than anyone needs, but I might as well max out whatever resources we have available for these things.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumComputing 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.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf 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)?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNope, 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
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'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.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumRendering 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.