Well all that takes is accidentally flooding one of the HUGE pre-generated cave systems with water from a large body. It seems like your computer would be processing volumes and pressures for over 9000 blocks as the water spread out through the caves.
Wouldn't your computer have to keep track of every single new water block if a block was removed adjacent to one of the block's outer edges? Say, for example, I flood a cave and seal off the entrance. Then I dig out a block at the bottom of the cave. All the water in between the bottom and the top would have to be re-calculated because of a single action.
Rollback Post to RevisionRollBack
You are totally thinking about this signature right now. Read a book.
Well all that takes is accidentally flooding one of the HUGE pre-generated cave systems with water from a large body. It seems like your computer would be processing volumes and pressures for over 9000 blocks as the water spread out through the caves.
Wouldn't your computer have to keep track of every single new water block if a block was removed adjacent to one of the block's outer edges? Say, for example, I flood a cave and seal off the entrance. Then I dig out a block at the bottom of the cave. All the water in between the bottom and the top would have to be re-calculated because of a single action.
Well, I hope your computer can do division. Sorry that was immature.
It's really not all that much work, Notch could even make it so that if a block of water has settled it "turns off" which makes it just a block of water, So it would only need to distribute a larger number into many smaller numbers when there is a movement in water.
People should really have good enough computers to run this, its not a big deal. If they dont, they should probably upgrade like i did a couple weeks ago.
Rollback Post to RevisionRollBack
Quote from boxturtle »
The hole the Creeper left in the earth is nothing compared to the hole it left in my heart.
I really like this idea, but I'm also concerned that this puts too much of a load on the CPU to do all these calculations. The calculations are simple (basic addition and subtraction), but the sheer number that would be required is a little daunting.
I really like this idea, but I'm also concerned that this puts too much of a load on the CPU to do all these calculations. The calculations are simple (basic addition and subtraction), but the sheer number that would be required is a little daunting.
You could simplify the system. Like dividing the total pressure in the water across all adjacent blocks+itself and then spreading the water based off of that calculation, no?
Barring possible issues with processor power, this is a fantastic idea.
One question, though: In the case of geysers, how would water spread (in the air)? When it's being shot up into the air, I can't see how it would spread in a natural fashion.
Rollback Post to RevisionRollBack
Quote from Travesty »
Quote from Paddy352 »
Are you always so pessimistic?
Yes, yes I am. A pessimist is always either right, or pleasantly surprised.
Quote from ChargerIIC »
Egads..this is World of Warcraft meets Battlefield 1942 in a dark alley with way too much to drink and no discarded mattress nearby.
Well, I'm afraid to compare this to Dwarf Fortress because Notch said he didn't want to be the clone, but still. I have tried to play DF, and the gameplay just isn't for me. I love the pressure, the biomes, the AI, the physics, I just don't enjoy the gameplay. I don't want MC to turn into DF, I just think that a physics system similar to its would be amazing. Liquid pressure would be a perfect addition to this game.
First, I will say this water system looks almost identical to the water system used in Dwarf Fortress. Although Dwarf Fortress used a random spread of excess water to cut down on CPU cycles, I'm sure the original model was the same. If you are unaware of Dwarf Fortress and the water mechanics - DF also had infinite water sources, and although it was difficult to flood the world, you could easily flood a large canyon. The water physics very quickly became laggy and caused a massive drop in framerate even on the beefiest of computers. Don't be so quick to blame bad programming, either.
Let me explain...
Quote from sumguy720 »
wouldn't this be really processor intensive?
It absolutely would, whether the block of water is "full" or not it would still need to run calculations constantly to determine if it should fill adjacent squares. Since it's 3d, water would have to calculate each square nearby. Since water doesn't flow up, you can take off the higher squares. You are left with a 3x3x2 grid, minus one for the block of water being calculated.
Each block of water would run 17 calculations when it is first discovered. This would include checking if the adjacent squares are also water blocks, meaning that a large ocean would be a vastly overwhelming amount of calculations.
Once the calculation is done, the water shouldn't need to check nearby full sources of water anymore, right? What if you pick up the water source with a bucket then? It would indeed need to constantly check nearby squares - or be written into many different "square was modified, run nearby square calculations" which I believe notch was developing (See "Tile to tile interaction").
Quote from virulentRant »
I think, because of this, the water in larger lakes should be infinite, but otherwise this is a great idea.
This is a good idea, take the following example and think of all of these calculations, plus needing to go into the ocean and taking water from there... soooo many more calculations if they were not infinite. This does not solve the problem completely though.
What if you tunnel under an ocean into a huge cavern system? Those "permanent water blocks" that the ocean is made of would mean that as the water flows into the cavern, every square must be checked. If the water pressure really is 128, depending on how the code is written and how quickly water should flow, this would take that initial 17 calculations and multiply it based on the flow.
This is your flow, imagine the calculations involved with a 1x1x5 pipe digging straight into the ocean, leading into a 2x3x30 cavern system. Your current model would need to make an incredibly large amount of calculations, becoming exponentially larger as the water spreads. Sure, it wouldn't be 200,000 instantaneously. But it may very well be that many calculations over the time period required to fill the cave. Also, it would become increasingly more intensive until the water reaches the sides -AND- fills to the top level.
You may want to consider cutting down on the calculations, by taking half of the water source at a time and spreading it to empty adjacent squares. Visually, this would look more realistic. Imagine your current water flow model in game. The first frame, a square of water sitting in the middle of a 5x5x1 pool. The next frame, that block of water sheds off 4% of the water, and puts it in the top/left/right/bottom square? That would look silly, and take awhile.
This would probably be better visually and cut down on CPU cycles. The idea is to cut the initial block in half and distribute an equal division to any eligible adjacent squares. You would then need to do this for the newly created squares. There would be a wasted CPU cycle for the original square, and then for the top/left/right/bottom square once distributing the corners (because the squares being distributed to contain more water than the source, meaning nothing would happen.)
Using 80 instead of 99 for more clean numbers. 90 probably would have been more appropriate because it would end with each square having 10.
The water distributed from the origin:
0 0 0 / 0 10 0
0 80 0 = 10 40 10
0 0 0 \ 0 10 0
The newly formed pools distribute:
0 10 0 / 5 5 5
10 40 10 = 5 * 5
0 10 0 \ 5 5 5
** The corners would get 2.5 from the two connecting
pieces each, and each of those pieces would distribute
twice, to both of the touching corners **
The origin's turn to distribute:
5 5 5 / * 10 *
5 40 5 == 10 20 10
5 5 5 \ * 10 *
This would continue, until each square reaches 8.88
Keep in mind, this is a 3x3x1 pool of water. Relatively small to what you would expect to see in Minecraft.
My biggest problem with water right now is it's quirky tendency not to follow the laws of gravity. I could have a stream of water flowing down hill and then suddenly stop when there is obviously room for it to flow. This might make sense for small streams of water that eventually peter out but a stream flowing downhill from the ocean shouldn't peter out at all.
First, I will say this water system looks almost identical to the water system used in Dwarf Fortress. Although Dwarf Fortress used a random spread of excess water to cut down on CPU cycles, I'm sure the original model was the same. If you are unaware of Dwarf Fortress and the water mechanics - DF also had infinite water sources, and although it was difficult to flood the world, you could easily flood a large canyon. The water physics very quickly became laggy and caused a massive drop in framerate even on the beefiest of computers. Don't be so quick to blame bad programming, either.
Let me explain...
Quote from sumguy720 »
wouldn't this be really processor intensive?
It absolutely would, whether the block of water is "full" or not it would still need to run calculations constantly to determine if it should fill adjacent squares. Since it's 3d, water would have to calculate each square nearby. Since water doesn't flow up, you can take off the higher squares. You are left with a 3x3x2 grid, minus one for the block of water being calculated.
Each block of water would run 17 calculations when it is first discovered. This would include checking if the adjacent squares are also water blocks, meaning that a large ocean would be a vastly overwhelming amount of calculations.
Once the calculation is done, the water shouldn't need to check nearby full sources of water anymore, right? What if you pick up the water source with a bucket then? It would indeed need to constantly check nearby squares - or be written into many different "square was modified, run nearby square calculations" which I believe notch was developing (See "Tile to tile interaction").
Quote from virulentRant »
I think, because of this, the water in larger lakes should be infinite, but otherwise this is a great idea.
This is a good idea, take the following example and think of all of these calculations, plus needing to go into the ocean and taking water from there... soooo many more calculations if they were not infinite. This does not solve the problem completely though.
What if you tunnel under an ocean into a huge cavern system? Those "permanent water blocks" that the ocean is made of would mean that as the water flows into the cavern, every square must be checked. If the water pressure really is 128, depending on how the code is written and how quickly water should flow, this would take that initial 17 calculations and multiply it based on the flow.
This is your flow, imagine the calculations involved with a 1x1x5 pipe digging straight into the ocean, leading into a 2x3x30 cavern system. Your current model would need to make an incredibly large amount of calculations, becoming exponentially larger as the water spreads. Sure, it wouldn't be 200,000 instantaneously. But it may very well be that many calculations over the time period required to fill the cave. Also, it would become increasingly more intensive until the water reaches the sides -AND- fills to the top level.
You may want to consider cutting down on the calculations, by taking half of the water source at a time and spreading it to empty adjacent squares. Visually, this would look more realistic. Imagine your current water flow model in game. The first frame, a square of water sitting in the middle of a 5x5x1 pool. The next frame, that block of water sheds off 4% of the water, and puts it in the top/left/right/bottom square? That would look silly, and take awhile.
This would probably be better visually and cut down on CPU cycles. The idea is to cut the initial block in half and distribute an equal division to any eligible adjacent squares. You would then need to do this for the newly created squares. There would be a wasted CPU cycle for the original square, and then for the top/left/right/bottom square once distributing the corners (because the squares being distributed to contain more water than the source, meaning nothing would happen.)
Using 80 instead of 99 for more clean numbers. 90 probably would have been more appropriate because it would end with each square having 10.
The water distributed from the origin:
0 0 0 / 0 10 0
0 80 0 = 10 40 10
0 0 0 \ 0 10 0
The newly formed pools distribute:
0 10 0 / 5 5 5
10 40 10 = 5 * 5
0 10 0 \ 5 5 5
** The corners would get 2.5 from the two connecting
pieces each, and each of those pieces would distribute
twice, to both of the touching corners **
The origin's turn to distribute:
5 5 5 / * 10 *
5 40 5 == 10 20 10
5 5 5 \ * 10 *
This would continue, until each square reaches 8.88
Keep in mind, this is a 3x3x1 pool of water. Relatively small to what you would expect to see in Minecraft.
The actual distribution calculations are fairly trivial and that I assumed that the method you illustrated would actually be taking place as the in-between step in the OP's model.
What I'm concerned are the litany of status checks involved given particularly large bodies bodies of water as you mentioned. The exponential problem arises from pressure calculations of the 'internal' water blocks within a ocean or large lake.
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.
Is there any merit to this idea? You seem to be someone whose opinion I value.
I deliberately didn't mention the processing load since frankly I'm not sure how notch is doing the water processing at the moment and whether this way will be any better. It is very likely that this method could be significantly more processor intensive but there are ways to reduce it such as average pressure each cycle rather than moving 1. Really only Notch can tell that. What I am more worried about is how loading a seperate "pressure map" for each chunk will effect RAM, I can't see any outcome other than a doubling of the memory needed to store the current map. Not a huge issue when stored on the HDD, but in RAM it might be a problem.
For the record I have never seen Dwarf Fortress.
I'm not too sure about the sand thing either, I thinnk teh interactions tehre would be far too complicated even if it is VERY cool. Let's just focus on moving water from one place to another.
How many calculations do you think that will take in an infinite world? The pressure will change, then all the blocks next to it, their pressure will change, and so on and so forth. You tap into the ocean and BOOM no more ram, no more server.
Rollback Post to RevisionRollBack
Playing Minecraft since [Friday, March 19, 2010, 9:20:21 PM] (First indev world save)
To make it simpler, maybe make it so if you change the flow of one block, it won't recalculate for the entire set? As in, if there is enough pressure pushing towards a single block, quarantine calculations to a 3 or 4 block wide ring around the affected block, and the rest of the pressure changes are just lost in division? Similar to (but more reliable than) how removing a block of water in the middle a lake will just reform the block into a new spring.
'
Do want!
Why? I don't see it really becoming a problem unless you drain a large area.
I think, because of this, the water in larger lakes should be infinite, but otherwise this is a great idea.
Well all that takes is accidentally flooding one of the HUGE pre-generated cave systems with water from a large body. It seems like your computer would be processing volumes and pressures for over 9000 blocks as the water spread out through the caves.
Wouldn't your computer have to keep track of every single new water block if a block was removed adjacent to one of the block's outer edges? Say, for example, I flood a cave and seal off the entrance. Then I dig out a block at the bottom of the cave. All the water in between the bottom and the top would have to be re-calculated because of a single action.
Well, I hope your computer can do division. Sorry that was immature.
It's really not all that much work, Notch could even make it so that if a block of water has settled it "turns off" which makes it just a block of water, So it would only need to distribute a larger number into many smaller numbers when there is a movement in water.
People should really have good enough computers to run this, its not a big deal. If they dont, they should probably upgrade like i did a couple weeks ago.
I see what you did there (I think).
On-Topic:
Barring possible issues with processor power, this is a fantastic idea.
One question, though: In the case of geysers, how would water spread (in the air)? When it's being shot up into the air, I can't see how it would spread in a natural fashion.
-
View User Profile
-
View Posts
-
Send Message
Retired Staff♣♦♠♥
Former King of Alesgan
Let me explain...
It absolutely would, whether the block of water is "full" or not it would still need to run calculations constantly to determine if it should fill adjacent squares. Since it's 3d, water would have to calculate each square nearby. Since water doesn't flow up, you can take off the higher squares. You are left with a 3x3x2 grid, minus one for the block of water being calculated.
Each block of water would run 17 calculations when it is first discovered. This would include checking if the adjacent squares are also water blocks, meaning that a large ocean would be a vastly overwhelming amount of calculations.
Once the calculation is done, the water shouldn't need to check nearby full sources of water anymore, right? What if you pick up the water source with a bucket then? It would indeed need to constantly check nearby squares - or be written into many different "square was modified, run nearby square calculations" which I believe notch was developing (See "Tile to tile interaction").
This is a good idea, take the following example and think of all of these calculations, plus needing to go into the ocean and taking water from there... soooo many more calculations if they were not infinite. This does not solve the problem completely though.
What if you tunnel under an ocean into a huge cavern system? Those "permanent water blocks" that the ocean is made of would mean that as the water flows into the cavern, every square must be checked. If the water pressure really is 128, depending on how the code is written and how quickly water should flow, this would take that initial 17 calculations and multiply it based on the flow.
Picotrial:
This is your flow, imagine the calculations involved with a 1x1x5 pipe digging straight into the ocean, leading into a 2x3x30 cavern system. Your current model would need to make an incredibly large amount of calculations, becoming exponentially larger as the water spreads. Sure, it wouldn't be 200,000 instantaneously. But it may very well be that many calculations over the time period required to fill the cave. Also, it would become increasingly more intensive until the water reaches the sides -AND- fills to the top level.
You may want to consider cutting down on the calculations, by taking half of the water source at a time and spreading it to empty adjacent squares. Visually, this would look more realistic. Imagine your current water flow model in game. The first frame, a square of water sitting in the middle of a 5x5x1 pool. The next frame, that block of water sheds off 4% of the water, and puts it in the top/left/right/bottom square? That would look silly, and take awhile.
This would probably be better visually and cut down on CPU cycles. The idea is to cut the initial block in half and distribute an equal division to any eligible adjacent squares. You would then need to do this for the newly created squares. There would be a wasted CPU cycle for the original square, and then for the top/left/right/bottom square once distributing the corners (because the squares being distributed to contain more water than the source, meaning nothing would happen.)
Using 80 instead of 99 for more clean numbers. 90 probably would have been more appropriate because it would end with each square having 10.
Keep in mind, this is a 3x3x1 pool of water. Relatively small to what you would expect to see in Minecraft.
I just wish he would give more feedback, There are some great ideas out there and it's a shame he doesn't see a lot of them.
The actual distribution calculations are fairly trivial and that I assumed that the method you illustrated would actually be taking place as the in-between step in the OP's model.
What I'm concerned are the litany of status checks involved given particularly large bodies bodies of water as you mentioned. The exponential problem arises from pressure calculations of the 'internal' water blocks within a ocean or large lake.
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.
Is there any merit to this idea? You seem to be someone whose opinion I value.
For the record I have never seen Dwarf Fortress.
I'm not too sure about the sand thing either, I thinnk teh interactions tehre would be far too complicated even if it is VERY cool. Let's just focus on moving water from one place to another.
How many calculations do you think that will take in an infinite world? The pressure will change, then all the blocks next to it, their pressure will change, and so on and so forth. You tap into the ocean and BOOM no more ram, no more server.
Playing Minecraft since [Friday, March 19, 2010, 9:20:21 PM] (First indev world save)
I say we should compare these two water systems.