Print

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

[Qyubey]

NOTICE: A lot of this early stuff I've now abandoned or changed up a lot to fix various issues and oversights I could think of while running simulations. Refer to the newest posts in this thread for the most up-to-date functions.

I've been binging some fluid dynamics threads here in the suggestion forums to try and collate some general ideas for a new mechanic that could improve the system.

I have a lot of time on my hands. 

Please be advised: I'm not really versed on hydrophysics or pressure dynamics, so if anyone wants to chime in with little additions or problems, feel free to do so. This all just theoretical calculations and speculations after all. I'll try and include visual aids where I can to describe some things, so please bear with me.

All good? Good.

First, let's get some basic definitions down for how things currently work. This thread by Kanddak has a lot more information that I don't want to seem like I'm stealing, so here is the link for your perusal:
http://www.bay12forums.com/smf/index.php?topic=32453.0

Spoiler (click to show/hide)

The little three-step flowchart they have illustrates the basic idea of how Fluids move around using a small heirarchy of possible movement. I don't actually recommend removing this: it's a fine idea. But assuming we want to eventually have Fun with simulated pressure, flows, and less of a CPU drain, there are some things that should change. We shouldn't be simulating every unit of water, essentially.

For your reading, here's some much smarter people discussing the issue of fluids in some more depth. Big kudos to NW_Kohaku and Tehran for giving me some ideas about this.
http://www.bay12forums.com/smf/index.php?PHPSESSID=592d789b855135c9e78d6acc42cfa38f&topic=61215.0
http://www.bay12forums.com/smf/index.php?topic=58397.0


Anyhoo, so now, onto problems. Tarn has already described some issues with the current system in an old interview with Gamasutra:
http://www.gamasutra.com/view/feature/3549/interview_the_making_of_dwarf_.php?print=1

He talks about how waterfalls form bizzare pyramids, the issues with a purely cellular fluid system that doesn't 'talk' to all of the nearby tiles, and the little shortcut for simulating pressure using pathing.

One of the biggest and most basic problems with current fluid dynamics is the every-frame checks: unless a water tile is entirely full, there's a constant CPU drain as the system attempts to reconcile draining fluid levels into each other.

I myself have cobbled together a little picture explaining the 'topfluid' problem, or so I call it:

Spoiler (click to show/hide)

I've got quite a bit to post and discuss, so let's hope I can keep it together until then.

Strike the Fluid

[Qyubey]

So I've spent a post essentially bashing Toady's fluid system - and I apologise for that - so how am I going to be productive and suggest a fix? Probably poorly, but let's give it a shot.

Well, I don't have much in the way of programming skills, but I do have some time to kill and decent visualization skills, so I've been trying to reason through an Entity-based water flow system. NW_Kohaku has suggested something of the sort before, so I apologise if I reiterate some of what they've said.

Okay, so here goes. Basic definitions:

A Fluid Body is an entity. It is defined as a consistent and unbroken body of fluids of the same kind. Each tile containing fluid is considered to be 'owned' by the corresponding Fluid body. Tiles can contain (let's just say, for Armok's sake) 7 units of fluid. Fluids follow a heirarchy of movement; where they seek to first occupy tiles according to their Flow value (and I'll talk more about Pressure later, but right now it just means they occupy lower slots before higher ones).

Now, that's just some basics, and it seems identitcal to Toady's system, right? Yes and no. Currently, the game handles each tile separately and runs a check for each non-static one. A Fluid Body Entity system would only check each unbroken body of water - so potentially it would check each lake, ditch, ocean, etc and really cut down on the total checks.

This what I envision the process of distributing water to be:

Spoiler (click to show/hide)

In the initial state, the block of water is static. When the time comes to intiate the flow of water (every few frames or so), the Fluid Body performs a check of the surrounding tiles. Solid tiles are disregarded, whereas open tiles are 'temporarily owned' by the body. It then assigns priority to which tiles it should flow into. Anything with an open top does technically own the space above it, but I've set it as 255 to make sure water doesn't flow upwards without outside pressure (more on that later). After deciding its priorities, it distributes the volume of the body all in one movement, settling half and half in the two tiles. After this, it 'disowns' each tile it does not fill and finishes its process.

Because this doesn't rely on moving fluid for each tile it potentially should cut down on CPU usage. Not only that, but making fluids into generic entities allows them to be Raw-able - with more fluids capable of being added. I might talk about mixing fluids later (that's a whole other issue), but let's first talk about the problems with this.

Upon further testing, this concept doesn't work very well. Ignore it.
Miniscule Volumes

Spoiler (click to show/hide)

So at this point I really regretted using units of 7. 10s would be easier. Anyway; the problem is evident here, at a certain point of spreading out, the amount of water becomes infinitesimal and not worth considering. Not only that, but because it would infinitely claim tiles, it could have the chance of trying to link every single fluid body it touches. I don't know what that would do, but I imagine it wouldn't be good.

To solve this, I'd say the easiest method is simply by assigning any tile with >1 fluid to be 'virtually empty' and to delete the fractional volume. Could reason it by saying it evaporated or diffused into the rock/soil - muddy the tiles and maybe spawn some small 'puddle' entities. If this was combined with true nutrients for soil, it could be an easy way to simulate irrigation via bucket brigade. I may come back to address this at some point.

[Qyubey]

Tile Priority & Movement

So, let's get onto Priorities now. Priority is a value for which a Fluid body dictates it's heirarchy of movement. Functionally, it wouldn't be that much different from Toady's system; it'd fill lower spaces first, then lateral ones, then higher ones. Restrict 0 for some dev purpose maybe, and keep 255 for never-fillable.

Spoiler (click to show/hide)

Simple enough. I was curious, so I started doing some more flow diagrams.

Spoiler (click to show/hide)

This one is also simple enough, but addresses both down and lateral movement. A simple outcome I see is that if you tunneled an 8 tile room underneath a single fluid tile, the fluid would flow down and delete itself once it settled on each tile - since it'd be below 1. Up to Toady whether that's a good idea or not.

So, here's where things start to get more complex, when you want to simulate displacement:

Spoiler (click to show/hide)

At #10, real world water should exude enough pressure on itself to equalize out levels, even through a U bend. This is a problem Tarn described back in the Gamasutra article, for which he had this fix:

"So then, how does this cause water to flow up the right-hand side of that U pipe?
TA: When a water is doing a search for an outlet, it is allowed to go anywhere up to one below its original Z level, including up the pipe.

I don't let it go the last step, or you'd end up with a three-quarter split that doesn't know how to stop. I have a dev item to improve that, but that involves expanding the static flag to a byte size counter.

And it respects physics, because it can't rise above its original height!

TA: Yeah, I was happy with it. It's crude, but it works, like the rest of the game. It would be nice to have a local model, but those are hard to come by."

So basically we have a z-1 check to simulate pressure. Works for U bends, but its not exactly how pressure works. But, for sake of moving on, let's just say we use this method for now.

Spoiler (click to show/hide)

Also seems to work for an S bend. if we combine it with our Entity/Volume system for the redistribution of water, levels equal out exactly without the 'topfluid' problem. However, another problem arises when we try to fill some separate things.

Spoiler (click to show/hide)

As you can see here, we have two possible spaces to flow into; one down and one up. Real world dictates that both would get filled with some degree of water, which is were pressure comes into play. Now, for our purposes, let's say we use the 'fill lowest first' method. We get:

Spoiler (click to show/hide)

While it does technically level out as it should, it completely disregards the fact that water SHOULD flow into the left tube. So lowest first can't really work.


So what if we tried it on a Z-level method?

Spoiler (click to show/hide)

By analyzing Fluid Bodies using Z layers, you can pretty quickly set up a path for fluid to flow into. This would probably be the trickiest part to implement, but I'll try to talk my way through it.

Essentially, the system would check the available slots to fill, then check the total Volume of the fluid in a given Z layer. If it works from the bottom upwards, it would fill the lowest slot first - which doesn't work for my purposes. However, if it works from the top down, it would fill the other slot first and distribute that top layer to the left. Technically this does mean that one fluid block is kind of floating, but given that it only lasts a frame, it's probably fine.

After this, you'd need to implement a check that identifies whether a body of water has split or not, after which their checks would occur separately. For the purposes of this, I've made them run at the same rate.

Spoiler (click to show/hide)

Just another problem I ran through to see how it works by separating smaller volumes. The reasoning seems to dictate things just fine.

Spoiler (click to show/hide)

Here's where things get interesting, specifically at #7. Two slots, technically on the same Z layer, but which should be filled first? This is where pathfinding could be useful - routing the shortest distance between the Z layer of fluid to be moved, and the first open slot. This would give the left slot first priority, since the path to it is only one space, as opposed to 7 spaces on the right.

This also partially solves the issue of objects not moving in the direction of flow - ironically - by keeping things static for a second. If we imagine there was a Sock introduced in #6 at the bottom of the pipe, then during the #7-8 resolution, yes, it wouldn't move, but neither would the fluid. The immediate resolution afterwards, however, could use pathfinding to dictate a 'Flow path' that would draw objects along, perhaps according to weight, bouyancy, and rate of flow.

Spoiler (click to show/hide)

Another little test involving a sort of more maze-like setup. Mostly for my own headspace.


Whew, still with me? Good, because we're about to get 3-dimensional.

[Qyubey]

3-D Movement

Now I'm not gonna run through every iteration of 3-D fluid movement. This one alone took me way too long to plot out.

Spoiler (click to show/hide)

I'm using a depth of 3 blocks here, presented in vertical slices to cut down on the amount of space I had to use. Not exactly Dwarf Fortress style, but looking top down might have been more confusing to convey.

This one proved a little too big to fit in the window, so here's an external link:
http://imgur.com/qOccueq

Okay, I know this is a lot but I've tried to convey it as easily as I can. In my headspace, I was essentially trying to figure out how much water would need to be displaced to fill each block, then to fill it from the bottom up. In the game, I imagine they would fill by assigned priorities based on things like pressure and pathfinding.

Now, the curious thing here is what occurs around resolution #4. Given that the fluid all settles equally, you have 1.4 units spread across 5 tiles on the same Z level, which are a part of the same fluid body. This accounts to 7 total units. Now this can flow into 3 available tiles (not counting up the original pipe), so it needs 21 units to be filled. As it should work by checking available volume per Z level first, that level should be entirely drained into the left branch, since it has the highest priority for Flow.

A thought occured to me here: I'd only been talking about flow priority in terms of available spots, but what about the already occupied spots? More on this later, when I discuss Waterfalls.

In general terms though, 3-D movement seems to work decently here.

[Qyubey]

Waterfalls

So, this is kind of a biggie it's another problem that was discussed by Tarn in the Gamasutra article. The way individual water flows means that it constantly piles ontop of each other, forming that bizzare water hill. I decided to reason through ways to get waterfalls working using Fluid Bodies.

Spoiler (click to show/hide)

My basic setup for the Waterfall, with an infinite water source.

Spoiler (click to show/hide)

Here, an immediate problem arises: infinite water means infinite flow rate. I've kept the top layer from being filled just to bullshit some gravity in, but the problem is very evident - water cannot be transmitted instantaneously throughout the Fluid Body in infinite Volumes.

It's also a problem that would occur with any large body of water that becomes displaced, although it's most evident here with an infinite source. If a waterfall is considered to be virtually infinite, we need a way to fix this.

My idea was a fixed Flow Rate. Within the fluid body, only 7 units can be moved at a time.

Spoiler (click to show/hide)

Huh, seems to work? 7 units always occupies the lowest slot. But I doubt it would scale well.

Let's make Flow Rate equal to 14 (2 tiles worth) at this point and see how it would progress.

Spoiler (click to show/hide)

...I may have accidentally created fluid tension as a byproduct.

Alright, it's not exact - it's happening over buckets worth of water instead of droplets, but I'm proud of it nonetheless. This effect will really only happen when fluid is freefalling anyway, and there are possible fixes for it; one I can think of is to add a special exception to certain tiles that are considered to be 'open air' that will prevent them from being entirely filled. This should condense the waterfall so that it maintains an unbroken stream from source to destination. However, given that waterfalls are not actually unbroken flows of water, this effect might even be desirable.

Regardless, Flow Rate shouldn't be a constant value anyway - it should be dependent on the Volume of water being displaced and the possible forces behind it. It's basically a speed marker.

• A small body of water, like a small pool, should flow pretty steadily down an incline.
• A large body of water, like a lake, should flow pretty rapidly when available - water breaking apart into individual entities might be okay here, since water does scatter when it moves quickly.
• The more water that can potentially be displaced, the more Force should be considered to be increasing Flow Rate.
• An ocean should have special rules, given the vast Volumes being dealt with. Ocean tiles on the edge should likely be considered to be Infinite, so long as they're only filling at or below Sea level.
• Water with pressure acting on it should flow more rapidly.
• Objects in water should be affected by flow rate, and possibly affect it back?
• Gravity should increase flow rate when going down, and decrease when climbing.
• Different fluids should have different flow rates to simulate differing viscosity.
• Heat might have an effect. Cold could cause liquids to flow slower.

I'm afraid that's all the fun charts I have for now, but I want to make one more post about the importance of Flow Rate in this fluid system.

[Qyubey]

So I've posted a wall of text and about a dozen excel diagrams, but I've really yet to get into the Fun that could potentially lie in this system.

Apart from being able to save some raw CPU power, this system offers 3 gameplay effects over the current system in the game: Pressure, Flow Rate, and Multiple Fluids. Now this is the part I've gone over the least in terms of all of this, so I expect there to be some stretching of imagination here.
Under Pressure
https://www.youtube.com/watch?v=a01QQZyl-_I

This is obviously the goal of any fluid dynamics system - being able to simulate the hydro-static forces that propel water. If Toady were to implement a true pressure system with current fluid dynamics, it'd murder your CPU. Not only would it be calculating pathing for each fluid tile, it'd also be considering the pressure of every single tile surrounding it, and using that to direct movement.

However, doing this for an entity might be a bit easier.

Now, I am not going anywhere near Air/Water Pressure, as I doubt I'm well-versed enough to understand those interactions, but adding a simple pressure system that affects distribution priority might not be that hard to do. I'd imagine it'd involve another check around each Open and Owned tile that the system intends to flow into - the higher the pressure in and around the tile, the lower it's distribution priority. This creates a simple modification that means fluid will flow towards the point of least resistance.

Spoiler (click to show/hide)

This is also why I didn't simply set above tiles to be unfillable - with enough pressure from every other open tile, you could lower the value above the top fluid tiles, resulting in the liquid actually being propelled upwards - perhaps even up a mineshaft. Imagine if a solid shaft of fluid water suddenly interacted with magma. The open space between the two suddenly spikes in pressure, so the next time the Water attempts to flow, it would shoot upwards instead of going down. Making pressure consistent from tile to tile might be difficult, but keeping a simple variable isn't too hard to imagine, huh?

EDIT: Oh, and I stumbled upon this while looking up Pressure stuff: http://gamedev.stackexchange.com/questions/58734/simulating-pressure-in-a-grid-based-liquid-simulation
Not sure if it could apply here, but maybe Sean's answer could be the beginnings of an air pressure system? It's possible that air bodies could be used as well - there'd likely be less of them to worry about since most air is unbroken (connected to the sky).

Flow
https://www.youtube.com/watch?v=FUH9S44D1BM

Dwarf Fortress currently only simulates flowing water on a flat surface immediate to the tile. If a sock is near to a water tile that flows past it, it will move along with it. Currently, I don't know how this is calculated, but I'm guessing it's some kind of trigger that water initiates when it moves into an occupied tile.

Simulating flow with a Fluid Body is problematic, but potentially could work in a similar way, but I'm interested in a new variable that the fluid body system naturally introduces: the flow rate of the body itself.

I described this back in the waterfall segment where I restricted the flow rate to 7 units, then 14. The variable, in practice, would likely need to be scalable with larger bodies of water, to prevent the entire thing just blebbing together like a viscous mass. Unless you wanted that...

So assuming the variable - through a lot of MATHS or something - could be scalable, it stands to reason that the flow rate could also convey how much water is flowing through a particular tile. This could be converted into force, which could carry objects or even damage things - especially if the fluid was pressurized!

In other words, Dwarf Hydro Cannons.

Now this only works for the borders in the way I've described - flow rate really only matters for filling nearby tiles, after all. But it also stands to reason that if the system was using pathfinding to route from upper layers to lower ones (and vice versa for pressure geysers), then it could probably also flag objects or tiles as it went and encode a direction and force. That way you have motion within the body as well - although I don't really know how that could work. Wishful thinking, I suppose.

and finally, More FLUIDS

Spoiler (click to show/hide)

Yes, the ideal situation is for Fluids to be raw-ified so we could add whatever we wanted. Water, Magma, Oil, Beer, Filth, Blood, Elf Tears- all possible if it were in raw. With a fluid body entity, that would actually be entirely possible, since they wouldn't be hard-coded to be water or magma. Obviously I'm talking out my ass here; I don't know how the fluids are currently coded or even how my system would work in practice. I'm just proposing a theory, after all - one that I hope could help Toady or Tarn, or even just give them some ideas.

Anyway, in terms of something I COULD speculate on, the intermixing of different fluids. Currently the game does support multiple things occupying the same tile, so that's not a big deal. Assuming you didn't want to bother with physical objects displacing water, you could just make the only interactions that matter be between different fluid classes. When initiating checks, I imagine it would check what fluids are in play and which are the densest, then order a list from heaviest to lightest and run the distribution checks.

This way, something like oil or magma would get first dibs on moving around, allowing water to flow over it. You could probably simulate vicosity by simply including a self-timer that begins when the heavy fluid moves, then forces it to skip two checks before it moves again - thus making it appear to be moving slower.

As for heavier fluids actually displacing lighter ones that already occupy regions; using the Ownership system for when it selects a tile to occupy, you could organize a density hierarchy so that dense fluids will straight-up over-write spaces that are already occupied, and place the removed fluids in temporary memory - either inside that tile or a surrounding one (the one it came from perhaps?). These units will come back into play when their corresponding fluid body gets its turn to move, and will simply route to the nearest open space. Presumably, this should allow you to dump 7 units of oil into a cistern, and allow it to slowly settle to the bottom as water rises up to the top.


Aaand, that about wraps it up for now. For anyone that got this far and read this stuff, I really appreciate the effort you made to read my nonsense~

I really appreciate this game and I think fluid physics add a great deal to it, so I wanted to share my thoughts and hope they can aid in future development in some fashion. If anyone wants to poke holes in this theory or further add to it, by all means - I welcome your input. Thanks!

[Bumber]

It all sounds very efficient in 2D, but there are way more tiles to be checked in 3D. For the cavern lake, you're pretty much talking about reshuffling the entire water contents of several z-levels each time the player pumps a little out. Some kind of improvement must be made where 7/7 water at the bottom isn't touched unless needed.

How do we reconcile the limited flow rate of a waterfall with the need to get the water there efficiently? (That is, without continuously calculating fluid movement across the entire source body of water.)

What happens if there's a setup where two bodies of water are repeatedly connected then separated for some reason? That's going to ruin FPS when the ownership is recalculated.

On the bright side, something might be doable with the flow direction. Perhaps we could optimize movement in that direction, and the up/down component of the vector might tell us about waterfalls. Too broad a generalization might not work with weirdly shaped paths, however. Give each 16x16(x1?) area its own flow direction? Zero flow indicates that the area can be ignored for calculations.

[Qyubey]

It all sounds very efficient in 2D, but there are way more tiles to be checked in 3D. For the cavern lake, you're pretty much talking about reshuffling the entire water contents of several z-levels each time the player pumps a little out. Some kind of improvement must be made where 7/7 water at the bottom isn't touched unless needed.

How do we reconcile the limited flow rate of a waterfall with the need to get the water there efficiently? (That is, without continuously calculating fluid movement across the entire source body of water.)

What happens if there's a setup where two bodies of water are repeatedly connected then separated for some reason? That's going to ruin FPS when the ownership is recalculated.

On the bright side, something might be doable with the flow direction. Perhaps we could optimize movement in that direction, and the up/down component of the vector might tell us about waterfalls. Too broad a generalization might not work with weirdly shaped paths, however. Give each 16x16 area its own flow direction?

That's actually pretty hard to speculate on. Currently the game just marks 7/7 water tiles as Static and skips over them when it loops. This system, as I've described it, would basically 'refresh' every single tile with the indexed Volume of fluid when movement is to be made. I know that sounds worse, but in essence it's only updating a few Zones at a time - whereas current system loops for every single water tile. The biggest CPU drain is flicking Whole Numbers around to each tile in an attempt to fill them; whereas making Tile Volume a property of a Fluid Body Entity relating to it's Total Volume allows it to use decimals instead.
TLDR, if you did grab some water out, it'd only need to do those calculations once and leave all the top layer at like 6.99 in a static state - current system would repeat infinitely as you've left a 6/7 hole in the lake that needs to be constantly looped since it isn't static.

Still, it might be possible to speed the efficiency up by including a 'skimming' function. You could check the Z level of open tiles (open being anything less than 7/7) against what Z levels the fluid body occupies, and just refresh the layers from there upwards. Cut the 'refresh' function off half-way when it isn't required.

Waterfalls are still bumping around in my mind. Flow rate is probably one of the most complex parts of this if you want to get it decently realistic. It'd need to scale with the Volume of water (although probably only to the Z level to which is moving), so more water will flow faster than a trickle would. That 'Skimming' function would probably be handy here as well.

I can do up a small diagram of what I mean by skimming in a second.

Yeah, the creation and destruction of Fluid Body Entities is one of the parts I purposefully skipped over, because I don't know how entities really work in DF. It might actually be really easy to create/destroy them over and over - or it might be a huge memory sink. Dunno. As for two Fluid Bodies combining, I'd imagine they just fold into the lower ID number and collate Volume/Owned tiles. I will say that this would need to be more complex than that and probably take into account how much Volume was previously in each tile before it moves it all around.

As for the Ownership calculation, I don't see that being a huge deal. It's just a glorified Collision function: "I own the tiles I owned last time I did a check, and I will add any open tiles adjacent to them." and when it Disowns tiles it goes "I do not own any tile to which I have no fluid in."
As for how that works with Miniscule Volumes being deleted? I'm not sure, something to figure out. Maybe an extra check that clears those tiles which are >1 before running Disown.

Yeah, I was thinking that when it paths, it might leave behind on each tile a Direction and Force variable. Direction would be one of 16 directions, and Force would be a derivative of Flow Rate that could affect movement. Could actually ride the rapids.

I doubt Force would ever reach dangerous levels without pressurization, or perhaps a gravity assist for waterfalls as they fall down can increase Force.

[Qyubey]

Actually, already seeing a problem involved in 'Skimming':

Spoiler (click to show/hide)

Those open tiles technically correspond to the lowest tiles of the volume, so it would activate the lot. Skimming still might work for the scenario you described, but it certainly doesn't work for waterfalls.

Some ideas occur. Pathfinding or maybe some kind of lateral line system to trace whether the owned, open space has any impassable terrain between. Very hackneyed, I know, probably doesn't work in 3D. Pathfinding would be most efficient here.

Full runthrough:
http://imgur.com/BUzWRLM.png

EDIT: Also decided to throw in a small mockup of flow direction:

Spoiler (click to show/hide)

[Qyubey]

Had a few other minor thoughts regarding how fluids relate to other stuff.
Oceans

Did mention a bit earlier, but if the functions for water flowing prove too taxing for the system, ocean fluid bodies might require their own special set of rules which are more abstract. Could be something as simple as "when an tile next to an ocean body of water becomes open, it fills with water at the flow rate". As for separating out ocean water into new Fluid Bodies when it is physically distanced, it'd probably have to revert back to regular salt water. This means you could still dump earth and section off some ocean water to be removed.
Aquifers

These would probably necessitate a secondary check when observing other tiles around the body. Rather than an aquifer being an infinite water source, I'd recommend it be considered a special tile that has a higher capacity for fluid than regular tiles. So if regular, open tiles can hold 7 units, maybe an aquifer holds 70. This means you could potentially refill aquifers for a huge supplier, though I'd imagine the flow rate back into the rock would be excruciatingly slow.
Cooling & Ice

Also lightly mentioned before, this one actually is slightly tricky. You could either maintain a flat temperature throughout the water, and just freeze it when it passes 0 degrees centigrade, but that's not very realistic. Water tends to freeze from the top down, so you could automate it to only freeze maybe the top 1 or 2 layers. Additionally, Temperature could be another value for each owned tile alongside Volume and Pressure; and a corresponding temperature flows along a gradient throughout the body by affecting nearby tiles. The interesting aspect there is that you'd have gradual freezing as the cooling spreads, or even the reverse with a heat source that dissipates out - although if you want only the top to freeze, you'd need to reason a system out that only freezes the top. Speaking of which...
Heating & Steam

Dwarf Fortress really should be on Steam.

Oh right, water steam. Same arguments as for cooling, but evaporation is a curious thing. The easy option is just to convert water from the top layer into steam, but assuming you went the full 9 yards and tracked temperature per tile, you could potentially create a bubbling system, where water boils from the bottom up. Again, since I don't want to extrapolate into Gas Bodies, I'll leave this thought there, but the potential exists in some form.
Displacement of Water By Mass

Currently, I just imagine water as being completely separate from objects floating within it - that's how the current system works. But potentially, if you're only recording Volume for each tile, you could assign other entities or objects with a Volume as well. Then you'd have to define tiles that are open, but 'occupied', in order to reasonably use their Volume/Size variable. This would probably require extrapolating out from units of 7 though. Functionally, it'd work the same as how I suggested Multiple Fluids should.

One big problem here is Swimming. If a dwarf falls into the water and displaces it, under current swimming rules he could potentially displace enough water to where he isn't actually considered to be in 'Swimming' water. If every tile's volume is calculated independently, it wouldn't know how to consider keeping that dorf under the water. I still think this system would be possible, but I don't know if its worth the effort just to make dwarf swimming pools have legitimate diving.

Oh, and don't get me started on trying to make Water-Wheels actually displace water. Yeesh.
Mixing Fluids into a New Fluid

Spoiler (click to show/hide)

Haha, oh I hate this. This one is real nasty and would require some complex interactions between fluid bodies. You'd need to check if they touch, what kind each of them are, what happens when they come into contact, and resolve it for - potentially - every tile that they both own (when not moving, naturally). The biggest problem I can see is that if two fluids mix in the centre of a lake, this would create a new fluid body for that new type. Doesn't sound too bad, until you start to throw in more types of fluids together.

Pour the fresh water and the elf tears in, then the filth and the booze in. Oh, and don't forget the Blood, Bile, Honey, Juice, and Milk! They're all fighting with checks to mix with each type and subtype, selecting spaces, potentially displacing each other enough to create new fluid bodies like some kind of dividing bacteria.

To me, it sounds like a big, terrifying mess. But then DF is itself a terrifying mess, so maybe it fits right in.
Pumps & Pipes

Should probably have its own entire section but I'm getting pretty exhausted reasoning all this out, so I'll try and be brief.

Pumps likely could function the same as they currently do in technically just teleporting water from one tile to another. Perhaps they could provide an ownership to a fluid body and allow it a high priority so it could flow upwards. Additionally the tiles it occupies could just be considered special cases with high priority so they immediately flow into them - like the pressurized system would. Alternatively, you could try and make it a function of pressure itself - where is where pipes might come into play.

Pipes, I imagine, would be single-tile constructions that can hold fluid - probably less volume than an open space though. Fluid flowing through them would be resolved as per normal, but with the added benefit of only allowing them to consider pipe openings to connect to valid, ownable tiles when considering movement. So a straight pipe would only allow flow to the two tiles adjacent to it. Or, if you wanted to make building easy, you could just have a generic 'Pipe Segment' and 'Pipe Opening' parts, rather than trying to create individual pipe segments for each possible shape a pipe could take. Segments would allow flow to other segments and openings, but not to open tiles. Pipe openings allow flow to open tiles though, and could probably be 'aimed' to a specific one to control flow.

The good part of this is since Pipe tiles would be considered in the same system, it'd be easy to implement pressure changes in them. Adding shutoff valves, pressure cookers, and other steam-related parts could all be used to manipulate which tiles are considered highest priority by manually increasing pressure in places. If people are interested, I might throw some diagrams of how pipe systems could work together. But hey, this is Dwarf Fortress - you probably just wanna know what Fun could be had when Pipes rupture, right?

Again, this isn't too hard to work out if each tile has a variable for it's pressure - just have a check that examines if the pressure is exceeding the Pipe segment's tolerance and convert it to a 'Ruptured Pipe' if it does. Ruptured pipes could randomly select one or more adjacent tiles - that are not other pipe sections - to create 'holes' facing, allowing water flow to flow out into open tiles again. If Flow Rate affected a Force variable that determined if water was moving with enough force to displace, injure, or destroy something, it could even possibly hurt or kill unlucky dwarves who happen to be next to the sudden hole in the pressurized pipeline. Ruptured pipes could be 'patched up' with craftable patches that dwarves hammer on, or simply deconstructed and replaced. Patched Pipes which would seal the pipe but reduce it's pressure tolerance dramatically, meaning it's very likely to bust open again at a lower pressure.

Hoo, I think that covers my current thoughts. I need some sleep~

[Wyrdean]

Dwarf fortress needs to be on Steam.

[Bumber]

Rather than an aquifer being an infinite water source, I'd recommend it be considered a special tile that has a higher capacity for fluid than regular tiles. So if regular, open tiles can hold 7 units, maybe an aquifer holds 70.

*Archimedes rolls in his grave*

The aquifer material must displace the water. Only a trickle makes it through the small gaps. It should feed from rivers/off-map.

[Qyubey]

Rather than an aquifer being an infinite water source, I'd recommend it be considered a special tile that has a higher capacity for fluid than regular tiles. So if regular, open tiles can hold 7 units, maybe an aquifer holds 70.

*Archimedes rolls in his grave*

The aquifer material must displace the water. Only a trickle makes it through the small gaps. It should feed from rivers/off-map.

I had to actually go research how aquifers work after reading that.

Spoiler (click to show/hide)

https://www.youtube.com/watch?v=guqinVOHTqc
https://www.youtube.com/watch?v=RUt43dSOsZQ
https://www.youtube.com/watch?v=RCu4UWDiiQw
https://www.youtube.com/watch?v=8K6V450StO4

This stuff is actually super interesting. I never did know how wells worked before. 

Ahem, anyway, I see your point. After going over the wiki entry on DF's aquifers, the system ingame right now is woefully unrealistic - but I suppose it accomplishes the main effect of water-bearing rocks filling spaces up to the water head. Though it is technically infinite, so if you were to connect a cavern to an aquifer, it'd fill the entire thing. Currently it also absorbs any water above the aquifer as well, but presumably just deletes it instead of actually storing it.

I'm not exactly sure how to handle them in my system though. They could just be a regular body that happens to have porous rock tiles Owned, and has special rules dictating pressure and flow within those tiles; or they could be a special type of body that is capable of transferring a Volume between two adjacent bodies without combining (and also only Owns porous rock tiles). Potentially those interactions could be more complex though.

Tried my hand at doing up fluid body aquifers:

Spoiler (click to show/hide)

Note: I've kept everything at a Flow Rate of 7 units here, just to show pathing at an equal rate. If Aquifers were to be realistic, it'd have a very slow flow rate into, between, and from porous rock tiles.

The porous rock flow should be fine so long as a POROUS_ROCK tab is given to the appropriate rock tiles. Can even turn that tab off when it gets smoothed to stop flow. My immediate concern is regarding Soil - since if we're extrapolating out to water flowing through porous things, soil should also be allowed.

Buuuut, given just how MUCH soil is any given DF map, that would probably mean any current map would have their lakes and rivers simply diffuse into the ground immediately. Adding porous soil would require an entire re-write of Terrain Generation to accommodate for a real water table so that lakes and rivers make actual sense for why they exist.

That's a lot of work that I don't know would be worth it, honestly. However, if T&T wanted to also implement a more realistic Farming & Plant Growth system that took groundwater into account, it'd actually work pretty nicely.

[Qyubey]

Aaaand, immediately found another problem:

Spoiler (click to show/hide)

Given that rule I instituted way back when about Miniscule Volumes, a low flow rate actually makes this be a big problem. It means an Aquifer (or anything with a low enough flow rate) cannot actually fill spaces if the speed is slower than what is considered to be a Miniscule Volume.

But, I have two solutions:

• Extend the Units out to a much higher number, like 20 or 100 or something, so that Volumes of >1 are very difficult to achieve.
• Get rid of Miniscule Volume rule. In truth, I don't think the issues of Miniscule Volume would be toooo bad? Again, it depends on how efficient the Combining/Separating of Fluid Bodies would be.

[Qyubey]

Hm, another thing occurs to me. If an Aquifer is a separate body, it wouldn't be able to easily find out the highest Z level for the liquid feeding into it - not without interacting with other bodies. If it were one body, a simple Z check would solve it, so that's a favor in its point.

Additionally, since water tables actually decline, there'd need to be some kind of calculation for a declining Z level in the Water Table in an Unconfined Aquifer:

Spoiler (click to show/hide)

This, unfortunately would require some maths to pull off and that's not exactly my specialty. To figure out the water table level, it could perform a calculation that takes the highest Z level of the table and plots a grid extending out from the highest point, then stores the water table in an XYZ array. Then, when distributing water, it can check the XYZ levels of the owned tile against the grid of the water table. If the tile is below or equal to the water table, it gets a high priority - if its above, it does not.

Presumably the grid itself could be plotted using distance from the origin point of the water table, and Pressures values in surrounding tiles.

ALSO, I keep saying 'High Priority' when referring to a low distribution priority (1 is the first to be filled, 2 is second, 3 is third, etc). That's just me being a derp with nomenclature.

Also-Also (I get distracted a lot), I got bored and decided to see if I could make a pressure system:

Spoiler (click to show/hide)

     

So the rate of pressure expansion and fluid movement isn't correct right now, but just bear with me for a bit. What currently happens here is every Pressure change check, the system logs the Current Pressure of each tile. Then, for each tile, it adds the pressure of all the surrounding tiles (that have a pressure value) and divides them by the number of tiles it took those values from. This is a quick and dirty pressure equalization system that flows pretty well through open air - but it should realistically should interact with water and objects (like pushing water).

The second one simulates a pressurized tank that suddenly opens. Again, the water flowing out is actually pretty good. I tried to show what I imagine the water flow to be as well, although I'm just guessing on the last part about how the water would spread itself out. Ideally Gravity would be like a constant pressure depending on z level that affects what tiles to flow into.

Maybe there could also be a pressure-volume interaction if you wanted to try compressing something.

I also tried to show what the Liquid flow would look like (currently I've set a pressure of 15 psi to be the limit that 'pushes' water out of its tile, just based on atmospheric pressure at sea level). This actually seems to work pretty well, but I dunno how well it'd hold up in a variety of situations though.