Print

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

[HartLord]

Currently we have ramps and flat tiles; this isn't very good when dealing with flows, liquid or gas. A simple way to solve this is to give every tile (including those with ramps) a slope direction, e.g. "This tile slopes down towards the southwest."  There would need to be nine possible slope directions, the ninth being no slope. Naturally, there would need to be a way for dwarfs to change a tile’s slope.

Fluids would be changed from “1/7 water” to “1/7 water flowing southwest” or “1/7 stagnant water.” This could be depicted the way water while liquid depth is turned off (or rainwater) is now: the tile gets the water tile (or simply turns blue) while there is water on it; or it could be depicted in the liquid depth manner: a number indicating the amount of water moving from tile to tile as it flows across the landscape. This also allows rain to realistically fill bodies of water: when rain hits a tile, a 1/7 water appears and begins to flow downhill.

This change would force constructed tiles to have a slope direction selected for them, the default being flat. Roofs in particular would need to be tilted or water would pool on top, which would be a hazard once structural integrity and what not are implemented.

Fluids under pressure should ignore slopes to some degree. That's my only idea in regard to pressure, so if you've got better ideas, speak up.


tl:dr
Add a new bit of data to tiles: the direction they tilt towards. This causes fluids on the tile to move to the tile indicated by the slope.
Also, allow rain to form water which then flows downhill.
Require a constructed tile's slope direction to be selected, and allow non-constructed tile's slope direction to be changed.


I have trouble explaining stuff with just words, so refinement, suggestions, and such are wanted.

[NW_Kohaku]

Flows telling you what direction they are flowing it would require that the game actually know what direction the flow is traveling in. 

Current flows are "dumb" in the sense that they simply randomly travel into other tiles with lower water levels than their own, and are forced to continuously check for directionality. 

They have to do this because the whole point is that players interfere with how rivers flow.

What happens when a player blocks off a river?  What happens when a player digs a channel?  Do those slopes keep pushing water into a stone wall without diverting?

By the way, you might want to look at parts of this thread on the topic of flows, as well - http://www.bay12forums.com/smf/index.php?topic=61215.msg1390985#msg1390985

[tsen]

Hmm. Does anyone know precisely how it decides on flows? In theory a lot of processor time could be saved by altering the order flows are calculated in.

If we could do top down along the edges and somehow link fluid squares that have identical depths so that that information could be cached, most of the fluid calculations that bog things down could be skipped. Granted, it would make new fluid calculations feel more spiky, but I think most people would be willing to accept that if it lowered the "day to day" processor load.

[MarcAFK]

The only major problem i have with the way DF handles flow, apart from the lag and the fact that nothing really flows in any direction, is the fact that waterfalls have low height at the top, yes it makes sense for what DF does for flow, but in reality the top would be at the same damn level as the river itself, or at least very slightly less depending on the amount of pressure behind it.

Perhaps DF should depict flow in much the same way as it deals with multiple zlevels of water, with teleportation. If 100 continuous tiles of 7/7 water exist with an empty space at one end then that tile instantly gets 7/7 of water teleported into it. the 100 tiles behind it then get converted to 6/7 water and the remaining 93 1/7's gets randomly divided among the 100 tiles.
It seems to me that treating whole bodies of deep water like this might reduce processor usage somewhat, perhaps along with perhaps making water with 1 height difference stop swapping place with each other (yeah it's like waves, pretty but kinda unnessicary lag inducing).
I know theres been lots of debate about fluid flow but it seems i have missed most of those threads, someone's probably already mentioned a better manner of doing it.

[HartLord]

Flows telling you what direction they are flowing it would require that the game actually know what direction the flow is traveling in. 

I was saying it simply flows in the direction the tile is sloped in.
So the water goes, "I'm on a tile. The tile says it points this direction (the slope direction). I move in that direction." Just while it's on the tile, if you loo"k" at it, it says it's "1/7 water flowing [insert direction]."

What happens when a player blocks off a river?  What happens when a player digs a channel?  Do those slopes keep pushing water into a stone wall without diverting?

Exactly the problem I noticed, too.

The problem is how to deal with overflow.

Maybe if it can't flow into the next tile downhill it becomes stagnant. That's not a great solution, but if we wanted it to keep flowing, instead of stopping at the wall, it would have to check which direction is "more downhill."

Maybe an overall slope to an area, to go with the individual slopes? But that would be increasingly complex and raise problems of its own. Like on complex hills and what not.


Consider this idea unconnected to the idea of this thread \/. (I think water moves around the top of tiles.)
To cause overflow, simply put the new water in at the bottom of the tile, pushing the rest of the water up, potentially into the tile above.


As a side note, the inspiration my original idea came from was watching water flow through the grass as it was raining.

[NW_Kohaku]

*sigh* nobody ever follows links...

OK, I'll just quote myself, then:

Also note, I am mostly talking about water when I am talking about fluids, here.  In fact, I have to constantly correct myself from saying "water" when I mean "fluid".  I will make another post later that will incorporate special quirks of magma, like pressure that builds up in magma chambers to cause eruptions.

So to try to make a quicky version of the previous deleted post (spoiling this into sections to keep length managable:

Spoiler: Current system, and its problems (click to show/hide)

Current fluid dynamics are one of the most inefficient aspects of the game, only surpassed by pathfinding, and even then, largely because pathfinding is unavoidable, wheras you can always just avoid using fluids.

The problem with fluids in this game are that they are a part of every tile (every tile has 4 bits for fluids, it's just that most tiles have a fluid level of "0"), and apparently, every single frame, the game checks every tile to see if there is going to be a fluid mechanic process run.  If there IS fluid that is not locked up (like water in the ocean that isn't on the surface z-levels, where the game can assume nothing is moving), then the process is quasi-realistic in that water units move about randomly, and will eventually fill up a container to a fairly level amount, but is massively inefficient about doing so. 

The process seems to run on every tile with water in it individually looking around it for a tile with lower water level, and then passing one unit of water over to one random nearby tile with a lower water level, even if this means a 5/7 tile passes water to a 4/7 tile, causing the tiles to become 4/7 and 5/7, respectively, and, in the iteration to the very next tile that just recieved water, that tile will pass the water straight back to the first one... accomplishing nothing but consuming CPU time.

The thing is, this would be realistic if we are dealing with individual molecules of water, and wanted hyper-realistic mechanics with CPU time being absolutely no object, but instead, every fluid unit constitutes around a foot and a half of water depth sloshing around at high speeds, frequently almost eternally in a cistern at the bottom of your fortress, unless you are particularly careful about making sure all water is exactly 7/7.

What's worse is that even though all these calculations are being done on an iterative per-tile basis, the game still needs to measure water in "bodies" just to find out how pressure works, anyway, meaning the game has to track water as single large units, anyway.

Running fluids as single large multi-tile bodies, where more complex calculations can be run, but are only run once per frame per fluid body, rather than on a per individual tile basis, would be able to greatly reduce the amount of total calculations that the CPU will have to run.

First, bodies of water must be composed of objects that are handled in their own special case of dynamic memory, rather than as properties of every tile.  For the purposes of pathfinding, there will probably need to be flags for "dangerous amounts of water, non-aquatics cannot path here" or "MAGMA! HOT!" that can be put in individual tile mapdata memory, but otherwise, like contaminants or furniture, fluid bodies can potentially be seperate chunks of memory, with a seperate "fluid mechanics" phase of every frame.

After that, we need fluid body to recognize when they are in a state of rest - that they are filling the container that the fluid body is in as efficiently as possible, and that no further motion is necessary, unless it is somehow disturbed.  This means that fluid, which would probably now be measured in liter form or the like, would try to level off, and then form a "placid lake" when not disturbed, with the top levels of a fluid body evenly distributed, with a remainder of water bodies, for example, probably gravitating to the edges in a little mockup of surface tension just to make things as even as possible.  Once it hits this state, fluid mechanics only checks for disturbance of the water, even if there is non-filling of the tiles.

Density can then become a matter of bouyancy.  Water has a density of 1000 in the game's choice of units, but this has problems since creatures are mainly made of 500 density organs, bones, and the like, which would make most creatures bouyant, and we need to have creatures capable of sinking to be capable of drowning.  Most woods, then, would also be bouyant, which may make for some fun mechanics, like floating logs down rivers to get to the sawmill.  (Of course, I do consider bouyancy something of a low priority if you do not wish to do all this in one go.) 

With that, however, we can also start modeling Displacement.  Dumping a 70-liter stone into the water will displace 70 liters of water when it sinks.  This causes a 70-liter rise in one tile of the fluid body (as the fluid mechanics would have to recognize how much space is available in every tile), and this would then have to start getting distributed. 

This brings up distribution rates, which is where we typically have to start breaking open the calculus.  Distributing the fluids, when we no longer have simple tile-to-tile transfers and delays between checks being the means of altering flow rates, depends on a great many factors, although fortunately, constant gravity, incompressible fluids and several other quirks of DF mechanics allow us to reduce several difficult variables to constants.  This means that we really only need a few variables: viscosity of each fluid (which will need to be a constant variable associated with every type of fluid), density (again, already a constant variable associated with every type of fluid), and fluid pressure (which is a simple, direct function of fluid depth, unless we start getting vulcanism involved with magma, where we might get some fun-fun with magma getting pressure that builds up from below).

Spoiler: Fluid mechanics formulas that later get turned into simplified form, part A (click to show/hide)

Pressure I could go into a long calculus formula about, but the whole thing simply reduces, because of the number of constants, to the pressure at any given point essentially being a function of a fluid's density times the distance to the surface plus the pressure of all fluids above the fluid body (which means you add air pressure, which is probably a constant), so a point 5' below water has half the pressure of a point 10' below water (if you ignore air pressure).

This means that if you have a one-tile (with each tile being a 3m cube) pit filled completely with water, and then mine out a tile below that water so that the water can escape, the pressure at the moment of being allowed to flow would be the pressure of 3 meters of water (plus atmospheric pressure) (I'll get into the exact mechanics of the rate of flow a given pressure implies later) (Figure A), while if the pit were two tiles deep and completely filled with water, and the bottom carved out, then it would have the pressure of 6 meters of water, which would cause twice the rate of flow of the first pit at the instant of being undermined (Fig B).

If we were to carve out that pit from the side, however, we would have a different problem, in where to measure the "depth" of the water.  If you carve a full wall away so that there is an entirely empty tile next to a tile that is completely full of water, then we are actually talking about the average of densities from the top of the tile to the bottom of tile to find a sort of average pressure between the two.  In a one-tile deep pit of water, this means that water will flow as if it has 1.5 meters of depth for simplicity (Fig C).  If it was two-tiles deep pit, and the hole was carved at the bottom, it would flow like the water at the bottom of the pit had 4.5 meters of depth (Fig D).  If the empty space were carved at the upper tile in the water pit, then it would still only be an effective 1.5 depth of water, and the lower part of the pit would obviously not matter for this fluid calculation. (Fig E)

Using this, what's really nice about this is that it can also be used (if with some slightly more complex mechanics), we can find how fast a fluid will flow when we are talking about a 3-meter-deep tile of water flowing into a 2-meter deep tile of water, which would have a .5 meter depth pressure pressing the flow, because of taking half the relative difference in the water heights, which is a difference of 1 meter. (Fig F) 

This also works in the exact same way if you have 1-meter deep water flowing towards a dry tile, a .5 meter pressure flow. (Fig F)

Now then, why am I saying "4.5 meters of pressure"?  That's because, thanks to all the variables being constants (at least, constant to each fluid type) except pressure, which is, itself, a direct function of fluid depth, that means that, except for specific density and viscosity of each fluid, all we need is a constant to find the rate of flow for all these fluids.

Spoiler: diagram (click to show/hide)

Spoiler: Calculating the formulas, Part B, simplifying the constants (click to show/hide)

These constants, however, are actually a bit of a matter of taste, as a rate of flow necessarily requires the dimension of time, which, as I've already said, we don't want to make on the same scale as everything else. 

This means we basically just need to find a constant to force flows to move at a rate that, for lack of better technical terms, "looks good".

Viscosity can simply be a constant of 1 or 1000 or some such for water, and be a different variable for other fluids to reflect their resistance to flow. (This is assuming simple newtonian fluids.)  You can simply divide the flow rate by the viscosity of the fluid to produce the "fluid friction" specific to that fluid because of viscosity.  This can, in fact, be kludged by simply setting a different effective "SPEED" rate for every type of fluid's checks - if magma is arbitrarily set to be 10 times more viscous than water, you could simply run magma flow checks 1/10th as frequently as the water flow is checked.  (Which may be what is already happening.)

Density is the opposite - the denser the material, the more force gravity can apply to a material, and for the purposes of purely gravity-driven fluid flows, doubling the density will double the rate of flow.  (So flow rate is multiplied by density when calculating purely gravity-driven flows.)

This is just a basic, 2-d version of fluid flow, however, I'll update on how "puddle mechanics" should work, since this whole thing is getting pretty long already.

Click on the quote, I go on after that for a couple more posts.  I'll hit the character limit if I quote more.

Basically, calculating fluid as a single body (which is the way most games perform the action) using calculus equations instead of brute-forcing simple math would result in more easily calculated flows, as well as stop problems like rivers that "empty out" in Adventurer Mode because the direction they are flowing out into has gone off-screen, so the game doesn't realize there isn't water over there anymore, and the river dries up.

[HartLord]

*sigh* nobody ever follows links...

Actually, I followed your link and found I'd already read that well-written stuff before, however, I don't think I've read the part you quoted. Doing that now.
And now that I have read the quoted stuff, I'm going to lose hours of my time finding and reading the other stuff you mentioned. 


I over-extrapolated a flawed idea with my slopes stuff, however, I did actually notice it was flawed before I posted and you pointed it out, I was just hoping there was some simple solution. I'm pretty sure now there isn't one.


NW_Kohaku, I have read a lot of your stuff over time, both old and new, and I find it all to be well thought out and well written. I think you are one of the most productive members of the forum, and I'm sure your logged in time is listed in the weeks or some silly-long amount like that.