How feasible would be establishing a 'boundary' state for water blocks that designates blocks of water that are not surrounded by water on all sides. These boundary blocks would contain pre-calculated values of pressure based on the the internal water blocks. That that the internal water blocks would have preemptively transferred all it's 'pressure' at it's resting state to the boundary blocks so and change is the shape or size of the entire body of water wouldn't need to be concerned with shifting the pressure values of the internal blocks but only with the calculations (and new designations) of the boundary blocks.
Normally, which a system like this, you keep a list of blocks that are actively changing pressure, and don't do any processing on the others. This is slightly more prone to bugs, but much, much more efficient.
However, while it is possible to define which blocks are boundary blocks, defining what blocks a body of water consists of is non-trivial, and pre-shifting the pressure to the outside doesn't work becuase you don't know where the pressure will be needed. If you simply distribute it to every boundary block evenly, when it flows you still have to re-distribute pressure to where it is flowing. If you build up any more meta-structures to manage the water you will not only be bypassing this entire idea, but creating an entirely different water system.
So in short, no, its not very feasible.
This method is trying to reduce the number of blocks with actively changing pressures. The idea is that the pressure redistribution will only be occurring between the boundary blocks and not between every block. Surface area vs volume.
I'm not talking about an even distribution between the boundary blocks. I imagine something where each boundary block contains the pre-calculated value of how much water would flow if one of its 'boundaries' were broken (i.e. boundary blocks at the bottom of the lake will have a higher value than those at the top.) Once there is an actual breach, the subsequent actual would spread to the predetermined number of blocks or less and only after then would the new boundary blocks be defined and the new pressure values be calculated. The actual water movement would not be CPU intensive because there are no intermediary calculations.
Although determining boundary block is non-trivial, how can it be more than 6 times slower than sand or gravel 'fall' checks?
Absolutely mystify you would, what I was thinking was that if a block of water changes or a solid block is removed it would active any dead water next to it if that block woul flow in the next cycle. This would of course trigger a chain reaction of activations across a body of water but it would save a lot of processing once a stable state is reached.
Absolutely mystify you would, what I was thinking was that if a block of water changes or a solid block is removed it would active any dead water next to it if that block woul flow in the next cycle. This would of course trigger a chain reaction of activations across a body of water but it would save a lot of processing once a stable state is reached.
I think I misunderstood what you were saying then. A system to keep track of stable blocks and not process them would be crucial. It is the propagating the entire ocean that is the problem.
Quote from Consolidate »
This method is trying to reduce the number of blocks with actively changing pressures. The idea is that the pressure redistribution will only be occurring between the boundary blocks and not between every block. Surface area vs volume. I'm not talking about an even distribution between the boundary blocks. I imagine something where each boundary block contains the pre-calculated value of how much water would flow if one of its 'boundaries' were broken (i.e. boundary blocks at the bottom of the lake will have a higher value than those at the top.) Once there is an actual breach, the subsequent actual would spread to the predetermined number of blocks or less and only after then would the new boundary blocks be defined and the new pressure values be calculated. The actual water movement would not be CPU intensive because there are no intermediary calculations. Although determining boundary block is non-trivial, how can it be more than 6 times slower than sand or gravel 'fall' checks?
I see what you mean. Since every block of water connected to a boundary block has the potential to flow into it, you essentially need to keep track of every body of water, know how much pressure is in it, and be able to relate this to changes in the landscape. This brings in the complexity of tracking when a body water is changed, figuring out how the change impacts the pressure, if water needs to flow and how, detecting if a pool of water is split into two, and consequently how much pressure belongs in each pool, detecting when two pools merge, etc. Now you aren't even dealing with anything on a singular block basis beyond water flowing into gaps, and you have to keep track of these bodies of water, including the map-spanning oceans. In fact, at this point it becomes a completely different water suggestion, which I had examined in utmost, algorithmic detail. Possible? Theoretically. Practical to code? Vaugely, but it would be semi-nightmarish. Proccessor-lite? On occasion, at other times a complete terror.
I said defining the blocks of water in a body of water is non-trivial. Figuring out its a boundary block is easy.
The basic problem with a pressure-based water system is that it is volume-based; the entire volume of water is involved, not just the surface layer and actively spreading blocks. Other water systems can achieve area-based complexity by allowing all the interior water to be ignored, so only the top and leading edge have any processing.
The other problem with a system like this is you lose the ability to have waterfalls and rivers; dynamically flowing water doesn't work unless you have active forces creating and/or destroying water to keep a flow going. While this may be realistic, it is difficult to handle in-game. Even if you did, it causes dynamically flowing water to each up processor time, so water-falls and rivers could become very lag-inducing.
I think I misunderstood what you were saying then. A system to keep track of stable blocks and not process them would be crucial. It is the propagating the entire ocean that is the problem.
I'm really not sure how much processing it would cause, in operations per block it is not that many, then how many blocks are loaded per player at a given time? if all of them were water and needed to be updated, what would that cost in system time? I really don't know the answers to these questions.
What I do know is that I think the current water system feels clunky and that this is the best replacement I can think of.
I think I misunderstood what you were saying then. A system to keep track of stable blocks and not process them would be crucial. It is the propagating the entire ocean that is the problem.
I'm really not sure how much processing it would cause, in operations per block it is not that many, then how many blocks are loaded per player at a given time? if all of them were water and needed to be updated, what would that cost in system time? I really don't know the answers to these questions.
What I do know is that I think the current water system feels clunky and that this is the best replacement I can think of.
Again, the problem with a system like this is that you are dealing with volumes of blocks, and hence this could easily become problematic.
It keeps the changes to water related to the surface, instead of the volume, which cuts down on the processing alot. It also keeps the flowing water in use, so we don't lose waterfalls. Its not trying to simulate real water, but rather create water that behaves in a useful manner. It also prevents the issues of large bodies of water draining, so punching a hole into the bottom of the ocean isn't lag-inducing.
comparing it to the posted list of pros and cons:
Good
The system is completely predictable if a bit unintuitive at times. - check, but it should be more intuitive
There is little chance of an infinite scale flood. -check
Water can mostly be treated just like any other block for file storage purposes-check
It works!-theoretically, hasn't been tested
Bad
Water does not obey gravity - Sure, water flows down hill, but it follows it own rule, not gravity. -water does obey gravity
It's nearly impossible to fill a large hole with water - Try it, dig a hole and fill it with water, it's not easy. This is somethine water is known for doing. -fixes this
There is no challenge/threat form water - If you mess up and flood your mine, it's easy to fix, just plug the hole and the water drains away. - re-introduces a threat from water, without making it insta-flood your entire mine like the old system
The current water setup is hard to expand - This is just an opinion but it seems things people want like pumps just don't work with the current set up. - allows for pipes and pumps fairly easily.
Actually mystify, your system and mine both seem almost identical except that you propose the addition of flowing water, I'm really having trouble seeing any difference other than that my description included upward flow.
you had a pressure system, I have a water height system. This is a crucial difference. I also integrated it with the current flowing water, which improves some things.
you had a pressure system, I have a water height system. This is a crucial difference. I also integrated it with the current flowing water, which improves some things.
Hmm I'm starting to lean on your water idea, tell me can you make Aquaducts with it? If oyu can't, well then I'll just patiently wait for a solution from Notch
Mystify: I like the idea of your system, but it seems like it's much more centred around very large bodies of water, right? It basically replaces springs with big bodies of water, then reuses the current water flowing system. The biggest problem I see in water is that it doesn't seem to flow properly at all. It's incredibly arbitrary and hard to direct. I think that this more fine tuned system would make flowing water better, and if not, then I think that another system needs to be figured out.
The water flowing tends to work fine, the big problem is it acts like a gel instead of a liquid. Yes, part of the idea is to use large bodies of water as replacements for spring blocks, but the other key part is the flowing water turns into a height-based flow that can fill up pools and follow river channels, aqueducts, and/or trenches.
I don't know if it's been asked before, but what would be the "default" pressure for generated lakes/oceans?
I mentioned it a couple of times, I see the default pressure of a water block spawned by the map generator beeing the maximum without the block flowing up. I chose 128 abritrarily for this though the numbers can be tweaked up or down until the system feels right. An ocean of 128 pressure blocks could flood a very large area.
The water flowing tends to work fine, the big problem is it acts like a gel instead of a liquid. Yes, part of the idea is to use large bodies of water as replacements for spring blocks, but the other key part is the flowing water turns into a height-based flow that can fill up pools and follow river channels, aqueducts, and/or trenches.
Hm, so it's an idea similar to the other one that was up. In that case, this could work.
2 suggestions: Firstly, keep springs! If you ask me, the system would be fine if you took out the ability to move springs, made water flow better, and add pumps.
2nd suggestion: Make some sort of rounder, so that if a block is, say, at 95% *fullness* and not supplying another block, it'll just turn into a "full" block.
The water flowing tends to work fine, the big problem is it acts like a gel instead of a liquid. Yes, part of the idea is to use large bodies of water as replacements for spring blocks, but the other key part is the flowing water turns into a height-based flow that can fill up pools and follow river channels, aqueducts, and/or trenches.
Hm, so it's an idea similar to the other one that was up. In that case, this could work.
2 suggestions: Firstly, keep springs! If you ask me, the system would be fine if you took out the ability to move springs, made water flow better, and add pumps.
2nd suggestion: Make some sort of rounder, so that if a block is, say, at 95% *fullness* and not supplying another block, it'll just turn into a "full" block.
1. You don't think the fact a single water block creates a waterfall to be odd? You can still have waterfalls and such, they just have to be coming from a source of water. I think a cliff with a lake at top with a waterfall flowing to a lake below looks a lot better than random water spurting out the side of a cliff. The non-intuitive nature of springs is also one of the things Notch said was a bad thing about the current system.
2. Why? Is there something special about a full block that makes it magically better than a mostly full block so we need it to round? It is already going to operate at a fairly low resolution.
This method is trying to reduce the number of blocks with actively changing pressures. The idea is that the pressure redistribution will only be occurring between the boundary blocks and not between every block. Surface area vs volume.
I'm not talking about an even distribution between the boundary blocks. I imagine something where each boundary block contains the pre-calculated value of how much water would flow if one of its 'boundaries' were broken (i.e. boundary blocks at the bottom of the lake will have a higher value than those at the top.) Once there is an actual breach, the subsequent actual would spread to the predetermined number of blocks or less and only after then would the new boundary blocks be defined and the new pressure values be calculated. The actual water movement would not be CPU intensive because there are no intermediary calculations.
Although determining boundary block is non-trivial, how can it be more than 6 times slower than sand or gravel 'fall' checks?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI think I misunderstood what you were saying then. A system to keep track of stable blocks and not process them would be crucial. It is the propagating the entire ocean that is the problem.
I see what you mean. Since every block of water connected to a boundary block has the potential to flow into it, you essentially need to keep track of every body of water, know how much pressure is in it, and be able to relate this to changes in the landscape. This brings in the complexity of tracking when a body water is changed, figuring out how the change impacts the pressure, if water needs to flow and how, detecting if a pool of water is split into two, and consequently how much pressure belongs in each pool, detecting when two pools merge, etc. Now you aren't even dealing with anything on a singular block basis beyond water flowing into gaps, and you have to keep track of these bodies of water, including the map-spanning oceans. In fact, at this point it becomes a completely different water suggestion, which I had examined in utmost, algorithmic detail. Possible? Theoretically. Practical to code? Vaugely, but it would be semi-nightmarish. Proccessor-lite? On occasion, at other times a complete terror.
I said defining the blocks of water in a body of water is non-trivial. Figuring out its a boundary block is easy.
The basic problem with a pressure-based water system is that it is volume-based; the entire volume of water is involved, not just the surface layer and actively spreading blocks. Other water systems can achieve area-based complexity by allowing all the interior water to be ignored, so only the top and leading edge have any processing.
The other problem with a system like this is you lose the ability to have waterfalls and rivers; dynamically flowing water doesn't work unless you have active forces creating and/or destroying water to keep a flow going. While this may be realistic, it is difficult to handle in-game. Even if you did, it causes dynamically flowing water to each up processor time, so water-falls and rivers could become very lag-inducing.
I'm really not sure how much processing it would cause, in operations per block it is not that many, then how many blocks are loaded per player at a given time? if all of them were water and needed to be updated, what would that cost in system time? I really don't know the answers to these questions.
What I do know is that I think the current water system feels clunky and that this is the best replacement I can think of.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAgain, the problem with a system like this is that you are dealing with volumes of blocks, and hence this could easily become problematic.
For comparison, look at my proposed alternative:
http://www.minecraftforum.net/viewtopic.php?f=1&t=15523
It keeps the changes to water related to the surface, instead of the volume, which cuts down on the processing alot. It also keeps the flowing water in use, so we don't lose waterfalls. Its not trying to simulate real water, but rather create water that behaves in a useful manner. It also prevents the issues of large bodies of water draining, so punching a hole into the bottom of the ocean isn't lag-inducing.
comparing it to the posted list of pros and cons:
Good
The system is completely predictable if a bit unintuitive at times. - check, but it should be more intuitive
There is little chance of an infinite scale flood. -check
Water can mostly be treated just like any other block for file storage purposes-check
It works!-theoretically, hasn't been tested
Bad
Water does not obey gravity - Sure, water flows down hill, but it follows it own rule, not gravity. -water does obey gravity
It's nearly impossible to fill a large hole with water - Try it, dig a hole and fill it with water, it's not easy. This is somethine water is known for doing. -fixes this
There is no challenge/threat form water - If you mess up and flood your mine, it's easy to fix, just plug the hole and the water drains away. - re-introduces a threat from water, without making it insta-flood your entire mine like the old system
The current water setup is hard to expand - This is just an opinion but it seems things people want like pumps just don't work with the current set up. - allows for pipes and pumps fairly easily.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHmm I'm starting to lean on your water idea, tell me can you make Aquaducts with it? If oyu can't, well then I'll just patiently wait for a solution from Notch
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumGood question. I'm guessing 100, so you get cleaner numbers when you divide it up.
I mentioned it a couple of times, I see the default pressure of a water block spawned by the map generator beeing the maximum without the block flowing up. I chose 128 abritrarily for this though the numbers can be tweaked up or down until the system feels right. An ocean of 128 pressure blocks could flood a very large area.
256; divisible by 2^0, 2^1 ... 2^7. Fast calculation for computers (bitshift) and can be stored in a single byte.
+1
Even better.
2 suggestions: Firstly, keep springs! If you ask me, the system would be fine if you took out the ability to move springs, made water flow better, and add pumps.
2nd suggestion: Make some sort of rounder, so that if a block is, say, at 95% *fullness* and not supplying another block, it'll just turn into a "full" block.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1. You don't think the fact a single water block creates a waterfall to be odd? You can still have waterfalls and such, they just have to be coming from a source of water. I think a cliff with a lake at top with a waterfall flowing to a lake below looks a lot better than random water spurting out the side of a cliff. The non-intuitive nature of springs is also one of the things Notch said was a bad thing about the current system.
2. Why? Is there something special about a full block that makes it magically better than a mostly full block so we need it to round? It is already going to operate at a fairly low resolution.