So you know how water kind of moves randomly because of entropy but goes down too because of gravity? Well if you don't, ignore that statement. Physics.
let me be more clear before you yell.
1. I simplified each water flow direction to five possible directions. Water can flow either left, right, forward, backward, or down. So there are five possible directions for flow.
2. the water block checks for free spaces. Okay so there are checks, but only for a non-solid block which would be a binary check. If the block immediately below is free, it just transfers 100 percent there.
3. water automatically gives its neighboring free spaces 1/5 of its supply rounded up no matter what their content.
Examples:
Say you have a single block of water in an open field. That one block of water distributes 1/5 of its supply in the four cardinal directions (not down because there is a solid block). There are now five blocks with the middle one slightly higher and the four outer ones lower. Distribution again. Now the middle block has stayed the same height as the outer blocks have shrunk. Distribution again. The middle block shrinks as the outer blocks continue to shrink. etc. Until you reach some threshold where the round up makes the flow stop.
Say you have an ocean of water and you remove a water block from the middle. The one block recieves 1/5 of a block from each of its four neighbors, filling in the hole.
Say you have an ocean of water and you add a water block to the top. The water block spreads out as per example 1 until disappearing into the white noise of the oceans flow.
Say you have a full ocean with no blocks missing. The substance is constantly transferring to itself and remains at equilibrium.
Say you dig a hole from an empty cave into an ocean. The blocks immediately above the hole fall like sand, and the ocean fills in the new hole in the water. There is a temporary vortex as the cave fills.
The coding seems cleaner than dealing with pressures and checking contents, and it works more like real water does. I'd like thoughts.
Rollback Post to RevisionRollBack
You are totally thinking about this signature right now. Read a book.
So you know how water kind of moves randomly because of entropy but goes down too because of gravity? Well if you don't, ignore that statement. Physics.
let me be more clear before you yell.
1. I simplified each water flow direction to five possible directions. Water can flow either left, right, forward, backward, or down. So there are five possible directions for flow.
2. the water block checks for free spaces. Okay so there are checks, but only for a non-solid block which would be a binary check. If the block immediately below is free, it just transfers 100 percent there.
3. water automatically gives its neighboring free spaces 1/5 of its supply rounded up no matter what their content.
Examples:
Say you have a single block of water in an open field. That one block of water distributes 1/5 of its supply in the four cardinal directions (not down because there is a solid block). There are now five blocks with the middle one slightly higher and the four outer ones lower. Distribution again. Now the middle block has stayed the same height as the outer blocks have shrunk. Distribution again. The middle block shrinks as the outer blocks continue to shrink. etc. Until you reach some threshold where the round up makes the flow stop.
Say you have an ocean of water and you remove a water block from the middle. The one block recieves 1/5 of a block from each of its four neighbors, filling in the hole.
Say you have an ocean of water and you add a water block to the top. The water block spreads out as per example 1 until disappearing into the white noise of the oceans flow.
Say you have a full ocean with no blocks missing. The substance is constantly transferring to itself and remains at equilibrium.
Say you dig a hole from an empty cave into an ocean. The blocks immediately above the hole fall like sand, and the ocean fills in the new hole in the water. There is a temporary vortex as the cave fills.
The coding seems cleaner than dealing with pressures and checking contents, and it works more like real water does. I'd like thoughts.
That is a mathematically simplified version of the original, It rises up some other problems though.
what if the space isn't divisible by 5? where does the extra water go? And it rules out my theory about pushing materials due to high pressure, Unless the sand will always get pushed unless the adjacent water is below 4/5.
So really its to whole divisible by 5 thing, otherwise, I like the idea.
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.
Yeah, you might be right. There are a lot of threads about water though, I didn't want to clog up the works.
It's pretty much a similar idea to the OP anyway, I'm just piggybacking.
Quote from Amanra »
So really its to whole divisible by 5 thing, otherwise, I like the idea.
well pretty much I meant if the block has 100 points of water it would go down by 20
and if it had 87 points, it would go down by 17 (not 17.4) So you could round to whatever decimal place you wanted to, and the higher precision you go with the better the water. This is a cool aspect of the idea though because you can scale it really easily.
As far as pushing sand blocks... :sad.gif: I didn't really think that through. I guess it wouldn't be possible with my system.
edit:
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.
I think you're confusing infinite with procedurally generated.
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.
I think you're confusing infinite with procedurally generated.
Correct me if I'm wrong but doesn't the Minecraft engine make everything that's within 300 blocks of a player function, while everything else remains unaffected?
I've never ever had any of my work stations away from mines enough, nor have I left anything cooking while mining, so I really wouldn't know much about this..
I think you're confusing infinite with procedurally generated.
Correct me if I'm wrong but doesn't the Minecraft engine make everything that's within 300 blocks of a player function, while everything else remains unaffected?
I've never ever had any of my work stations away from mines enough, nor have I left anything cooking while mining, so I really wouldn't know much about this..
I will not correct you because I don't think you're wrong.
I think you're confusing infinite with procedurally generated.
Correct me if I'm wrong but doesn't the Minecraft engine make everything that's within 300 blocks of a player function, while everything else remains unaffected?
I've never ever had any of my work stations away from mines enough, nor have I left anything cooking while mining, so I really wouldn't know much about this..
I will not correct you because I don't think you're wrong.
Hmm... then how valid is his argument about CPU and Ram constraints then? Sometimes I wish there was multiple Notches so stuff like this would not go unanswered
If you are sitting in an island in the middle of the ocean, that is a lot of processing for a stable body of water. Making stable water non-processor intensive is an important part of a good water system. If somebody opens a mine into the bottom of the ocean, either on purpose or accidentally, you don't want the entire system to grind to halt while pressure is recalculated over the entire ocean.
Hmm... then how valid is his argument about CPU and Ram constraints then? Sometimes I wish there was multiple Notches so stuff like this would not go unanswered
That's my point, his argument isn't valid because the world isn't actually 'infinite,' it just extends its boundaries every-time you reach them.
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.
Hey guys, I did a mockup of my water idea in 2D with a program called game maker. The program is really inefficient, but it's the best I could do.
Left click: delete water
right click: make water watertest.exe
Runs well on my machine, but of course I'm only simulating 300 blocks of water. You'll notice that water flows slowly into and out of the 'caves', but fills small areas quickly.
Also: It would be pretty easy to make a waterblock deactivate wouldn't it? And then when a block gets destroyed it activates any water blocks next to it? That way an ocean would be inactive until you dug a hole in it, and then only waterblocks that really would drain would be effected, so probably within a 20 block horizontal radius of the hole.
Rollback Post to RevisionRollBack
You are totally thinking about this signature right now. Read a book.
Hmm... then how valid is his argument about CPU and Ram constraints then? Sometimes I wish there was multiple Notches so stuff like this would not go unanswered
Pretty valid unfortuantely, consider we could have upward of 32 people in 32 different physics-enabled areas and you'll realise that any extra RAM/CPU usage over what already exists (see Notch's blog for an excellent breakdown) is potentially devastating.
Keep in mind though that water would be calculated in passes, the world won't stop and process ALL the active water until it reaches a stable state, rather it will check all the blocks in active areas and update as neccessary, say each 1/2 second or whatever is appropiate to determine flow speed. Once again I'll reiterate that without knowing how Notch is updating water, I can't be sure which is more efficient, though I get the feeling he would have to do something similar, at least on comparison scale.
Quote from sumguy »
Also: It would be pretty easy to make a waterblock deactivate wouldn't it? And then when a block gets destroyed it activates any water blocks next to it? That way an ocean would be inactive until you dug a hole in it, and then only waterblocks that really would drain would be effected, so probably within a 20 block horizontal radius of the hole.
Not a bad idea, if ocean blocks were "dead water" until an adjacent block was destroyed, it would save a buttload of processing power as they could be skipped in the comparrison phase. Then only "live water" would have a pressure. Live water would be created when a block next to dead water changes (there must be checks for this already to update lighting) and would start with normal (128 under the proposed system) pressure. any blocks holding stable in a certain pressure range for a cycle could then revert to dead water.
The waterblocks deactivating was what I mentioned in the first part of my response to Consolidate. I am fairly certain that this is already implemented with the current water system, based on some of the bugs I have encountered.
However, due to the nature of the proposed system, destroying a hole in the side of the ocean will require you to process everything. If you simplify with the dead/alive system, so a dead block reactivating gets full pressure, you simply dig a trench, wait for it to fill, and then wait for it to stabilize and become dead. You can then repeat, getting infinite water easily. If it doesn't reset, then water would oddly flow out to a certain distance and stop, much like the current water, only worse. The basic premise of this approach mandates simulating everything when changes are introduced.
Water Mechanics?
Hmmm...
How would that work?
So you know how water kind of moves randomly because of entropy but goes down too because of gravity? Well if you don't, ignore that statement. Physics.
let me be more clear before you yell.
1. I simplified each water flow direction to five possible directions. Water can flow either left, right, forward, backward, or down. So there are five possible directions for flow.
2. the water block checks for free spaces. Okay so there are checks, but only for a non-solid block which would be a binary check. If the block immediately below is free, it just transfers 100 percent there.
3. water automatically gives its neighboring free spaces 1/5 of its supply rounded up no matter what their content.
Examples:
Say you have a single block of water in an open field. That one block of water distributes 1/5 of its supply in the four cardinal directions (not down because there is a solid block). There are now five blocks with the middle one slightly higher and the four outer ones lower. Distribution again. Now the middle block has stayed the same height as the outer blocks have shrunk. Distribution again. The middle block shrinks as the outer blocks continue to shrink. etc. Until you reach some threshold where the round up makes the flow stop.
Say you have an ocean of water and you remove a water block from the middle. The one block recieves 1/5 of a block from each of its four neighbors, filling in the hole.
Say you have an ocean of water and you add a water block to the top. The water block spreads out as per example 1 until disappearing into the white noise of the oceans flow.
Say you have a full ocean with no blocks missing. The substance is constantly transferring to itself and remains at equilibrium.
Say you dig a hole from an empty cave into an ocean. The blocks immediately above the hole fall like sand, and the ocean fills in the new hole in the water. There is a temporary vortex as the cave fills.
The coding seems cleaner than dealing with pressures and checking contents, and it works more like real water does. I'd like thoughts.
Dude make a new thread.
In his defense water threads are really saturating this part of the forum
That is a mathematically simplified version of the original, It rises up some other problems though.
what if the space isn't divisible by 5? where does the extra water go? And it rules out my theory about pushing materials due to high pressure, Unless the sand will always get pushed unless the adjacent water is below 4/5.
So really its to whole divisible by 5 thing, otherwise, I like the idea.
Yeah, you might be right. There are a lot of threads about water though, I didn't want to clog up the works.
It's pretty much a similar idea to the OP anyway, I'm just piggybacking.
well pretty much I meant if the block has 100 points of water it would go down by 20
and if it had 87 points, it would go down by 17 (not 17.4) So you could round to whatever decimal place you wanted to, and the higher precision you go with the better the water. This is a cool aspect of the idea though because you can scale it really easily.
As far as pushing sand blocks... :sad.gif: I didn't really think that through. I guess it wouldn't be possible with my system.
edit:
I think that's how it would flow. Of course water disappears because I don't care to show the whole grid here.
I think you're confusing infinite with procedurally generated.
That's the problem we're trying to avoid. We need to find a water systems doesn't require checks or calculations during a stable state.
Correct me if I'm wrong but doesn't the Minecraft engine make everything that's within 300 blocks of a player function, while everything else remains unaffected?
I've never ever had any of my work stations away from mines enough, nor have I left anything cooking while mining, so I really wouldn't know much about this..
I will not correct you because I don't think you're wrong.
Hmm... then how valid is his argument about CPU and Ram constraints then? Sometimes I wish there was multiple Notches so stuff like this would not go unanswered
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat's my point, his argument isn't valid because the world isn't actually 'infinite,' it just extends its boundaries every-time you reach them.
I used to be years ago in Highschool when I was studying Computer Science....maybe I should've continued
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNormally, 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.
Left click: delete water
right click: make water
watertest.exe
Runs well on my machine, but of course I'm only simulating 300 blocks of water. You'll notice that water flows slowly into and out of the 'caves', but fills small areas quickly.
Also: It would be pretty easy to make a waterblock deactivate wouldn't it? And then when a block gets destroyed it activates any water blocks next to it? That way an ocean would be inactive until you dug a hole in it, and then only waterblocks that really would drain would be effected, so probably within a 20 block horizontal radius of the hole.
Pretty valid unfortuantely, consider we could have upward of 32 people in 32 different physics-enabled areas and you'll realise that any extra RAM/CPU usage over what already exists (see Notch's blog for an excellent breakdown) is potentially devastating.
Keep in mind though that water would be calculated in passes, the world won't stop and process ALL the active water until it reaches a stable state, rather it will check all the blocks in active areas and update as neccessary, say each 1/2 second or whatever is appropiate to determine flow speed. Once again I'll reiterate that without knowing how Notch is updating water, I can't be sure which is more efficient, though I get the feeling he would have to do something similar, at least on comparison scale.
Not a bad idea, if ocean blocks were "dead water" until an adjacent block was destroyed, it would save a buttload of processing power as they could be skipped in the comparrison phase. Then only "live water" would have a pressure. Live water would be created when a block next to dead water changes (there must be checks for this already to update lighting) and would start with normal (128 under the proposed system) pressure. any blocks holding stable in a certain pressure range for a cycle could then revert to dead water.
Or would it still be fruitless?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHowever, due to the nature of the proposed system, destroying a hole in the side of the ocean will require you to process everything. If you simplify with the dead/alive system, so a dead block reactivating gets full pressure, you simply dig a trench, wait for it to fill, and then wait for it to stabilize and become dead. You can then repeat, getting infinite water easily. If it doesn't reset, then water would oddly flow out to a certain distance and stop, much like the current water, only worse. The basic premise of this approach mandates simulating everything when changes are introduced.