Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ToxicFrog]

Consider a situation like this:

code:

(from above) # = wall, X = floodgate
###############
#~~~~~~~~~~~~~X -> to chasm, cliff, etc
#~~~~~~~~~~~~~X
#~~~~~~########
#~~~~~~#
#~~~~~~#
#~~~~~~#
########

It's been filled with water to a depth of 7/7. Then you open the floodgates. Lots of water rushes out at first. The expected behaviour would be for it to drain down to a level of 1/7, then gradually evaporate. Instead, however, it drains down to a level of 1/7 with lots of rapidly moving 2/7 tiles - it appears that, instead of actually forcing the water off the edge, they're just moving around at random. This means that while it will drain from 7/7 to 2/2 fairly quickly, it drains from 2/7 to 1/7 very, very slowly, while imposing a serious CPU hit - in effect, one of these moving 2/7 tiles will drain only when:
(a) its random movement takes it through the floodgates and off the edge
(b) one of the 1/7 tiles remains that way long enough to evaporate, and then a 2/7 tile moves onto it.

In effect, it seems that once the water reaches a certain shallowness, it goes from moving the water from above to beside, to simply shuffling the water around at random and hoping it drains. Or perhaps it always works like this, and it just isn't really noticeable until once it's already drained most of the way. This results in things taking a very, very long time to drain all the way, with attendant heavy CPU load.

I'm not sure what a good solution to this would be - perhaps prefer creating water in empty ajacent squares (and destroying water in the pool to match this) over moving water from one pool tile to another?

[Nadaka]

The bug you are reporting, is it that a spot of 2/7 water moves to the edge and then back? That would be a bug.

Or is it just that the random walk of 2/7 water rarely takes it to the edge, this would be an artifact of how fluid dynamics are modeled and not really a bug.

[Draco18s]

quote:Originally posted by Nadaka:
<STRONG>The bug you are reporting, is it that a spot of 2/7 water moves to the edge and then back? That would be a bug.</STRONG>

You mean something like...

code:

######_
111111_ <--chasm/open space
112111_
######_
######_
111211_  
111111_
######_
######_
111111_
111211_
######_
######_
111111_
111121_
######_
######_
111111_
111112_ <-- Amost there!
######_
######_
111121_ <-- Awww...
111111_
######_

Because that happens.

[briktal]

Based on what has been said of the water system, this situation is a bit of a flaw/bug in the design.  To prevent puddles from just randomly moving around the map, 1/7 water doesn't go anywhere, so it will never flow through the floodgates.  Then because that 2/7 water will just randomly move around the large shallow body of water, it may take some time for it to go off the edge.  It has the effect, so some degree, of a wall of 1.5/7 on that ledge, with the 2/7 water being a wave.  The water won't go over the wall until the wave comes the right way.

[Derakon]

What we need here is surface tension. If you have a pool of 1/7 water next to a pit:

code:

#####
#111_
#111_
#111_
#####

then the water on the edge "wants" to flow into the pit. But real water would pull its neighbors along for the ride. Let's go ahead and label our water here; it's still 1/7 deep:

code:

#####
#abc_
#def_
#ghi_
#####

When c, f, and i flow into the pit, they pull b, e, and h into their positions (c doesn't have to pull b; it just needs to pull one neighbor to replace the water it's losing). b, e, and h then pull a, d, and g into their original positions. a, d, and g, lacking neighbors that haven't already been pulled, just come along for the ride, and you're left with this:

code:

#####
#.ab_
#.ef_
#.hi_
#####

This doesn't require 1/7 water to move on its own, and you'd have problems if you had the following setup:

code:

#####
#11._
#11._
#11._
#####

(though you could, interestingly enough, fix that problem by adding a unit of water next to the pit). However, it should allow you to realistically drain a reservoir without having to deal with continuous floor heights, which is what you'd normally need.

Because neighbor-pulling can't be ordered, there's still the possibility of failing to pull "all the way" to the wall, e.g. if c pulled e and f pulled h, then i would have no valid neighbors to pull. However, this is only an issue once water is at height 1 (since deeper water will act to even itself out anyway), and at that point, natural evaporation will eventually clean up the puddles for you.

[Pickerel]

I am not at all an expert on the code, but I believe that the current code for water is statistically based.  

As a simple model (I don't know if it's perfect, but this is just an example model, not the actual model the game used, to demonstrate the mechanics), lets assume 2 squares, 1 of 7/7 one of 0/0, next to eachother.  There is perhaps a probability for each unit of water to exist in the next square, say 50%.  So lets roll it up.  0 0 1 0 1 0 0.  So two units of water now occupy the next space, and it is 5/7 and 2/7.  I picked these numbers so that we can demonstrate the next part.  Now, it would be 5 - 2 units having the probability of moving.  So lets roll up those 2.  1 0 1.  So 2 units move over making it 3 and 4,  Now, each round, it will roll the probability that that 4 - 3 = 1 will move to the next square.  So now it is 4 and 3.  Under this model in a 2D rather then 1D setting, your area of 1's with a 2 will have the 2 wantering randomly because it has a probability of transfering to any of the 8 adjacent squares.  Thus when it neared the edge, it did so randomly, and happened to not pick one of the 3 squares that would bring it over the edge once it reached the edge.
Again, I am just hypothesizing at a possible model that fits my observations, so the specifics could very easily be quite wrong.  But I think this is how it works...

[Splime]

If you just have 1's there, surface tension can also keep water from going off the edge, ie, water on a penny. While there's much more water in the example given in the first post, surface tension works both ways.

[ToxicFrog]

IMO, the behaviour of water at 1/7 is sane - a water-filled area won't drain to perfect dryness, there'll be puddles and films of water and whatnot left over which need to evaporate. It's the fact that you get larger puddles moving around at random inside it that's the bug.

[zagibu]

Surface tension only matters in situations where small structures are involved, not in large pools like the one drawn.
Maybe the water model could be modified so that 1-level tiles also move around, but are consumed in the process (evaporation)...

quote:Originally posted by ToxicFrog:
<STRONG>IMO, the behaviour of water at 1/7 is sane - a water-filled area won't drain to perfect dryness, there'll be puddles and films of water and whatnot left over which need to evaporate.</STRONG>

Isn't that what "muddy" means? Maybe muddy rock should dry out instead, which would also force you to irrigate your farm plots.

[ March 13, 2008: Message edited by: zagibu ]

[ein Syndication]

The problem is, the "random" movement isn't so random. The odd amount of water tends to zoom around in formation, essentially seeming to hate leaving its cell, which usually does nothing except chew through your framerate like a carp. If it somehow grouped a bit together and spread out more uniformly, it'd more than likely get to the destination quicker and cause a lot less of a problem.

[Exponent]

What if 2/7 water did not reset the evaporation counter?  Assuming there is such a thing, while a square is at 1/7, the counter goes up (or down, whatever) until it hits the magic value for being able to evaporate.  If it becomes 2/7 before this occurs, the counter stops counting, but doesn't reset.  If it goes back down to 1/7, the counter continues where it left off.  If it goes up to 3/7, then the counter gets reset to 0, and the next time it gets to 1/7, it will have to go through the whole amount again before it can evaporate.

It wouldn't dump any more water than before, but it would hopefully evaporate more quickly, thus terminating the CPU load more quickly as well.

[Narmio]

I think the problem is that the cellular automata model of fluids lacks adequate effect of momentum.  Once water has started moving in a direction to "even out", say for those last few squares of 2/7, it should be more likely to continue moving in that direction (and if it hits an obstacle, to bounce off, but our CPUs may complain at that point).  

I'm not thinking "full fluid dynamics and rigid body impacts" here, just a weighting of the "water randomly moves to an adjacent square" behaviour by what square the water came from.  A really trivial model of inertia.

Can anyone see that causing too much trouble?  I think it would help DF's fluids greatly, but I'm neither a fluid dynamics nor cellular automata expert.

[numerobis]

Basically, we want convection-diffusion rather than the present diffusion code.  A proper code might be highly expensive; dunno exactly if we could cut enough corners to be practical.

Staying within small changes to the current engine: it should be a relatively small expense -- 3 or 5 bits per cell (plus padding) -- to store a vector to each grid cell, and, when water moves into a square, to update the vector.  A square with more water than its neighbours would preferentially send water in the direction of the vector instead of being random.  Perhaps 3 forward, and 2 each at 45 degrees, and 1 each orthogonally or backwards, repeat until there is no flow left to move.  The 3-bit solution would use the current solution for the z-axis and ignore vectors in the z-axis case.  The 5-bit version would have momentum through the z-axis, but I don't really want to think it through.

Maybe I should cut a prototype.

[Derakon]

quote:Originally posted by Narmio:
<STRONG>I think the problem is that the cellular automata model of fluids lacks adequate effect of momentum.  Once water has started moving in a direction to "even out", say for those last few squares of 2/7, it should be more likely to continue moving in that direction (and if it hits an obstacle, to bounce off, but our CPUs may complain at that point).  </STRONG>

That was basically the goal of my post. Calling it "surface tension" was a mistake; more that a 1/7 would flow off the edge, leaving a gap that a 2/7 should fill.

[BishopX]

Would it be simpler to simply consider 2 cells in any direction, with water moving from square 0 to sqaure 2 if 2 is lower than 1 as well as water moving from square 1 to sqaure to on the same movement?

This might be more processor intensive but it should reduce the probability of bouncing waves.