Print

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

[Zorbeltuss]

Water physics aren't bad in DF, it is really workable already but, I've thought of a way to handle it a bit more realistically, currently depth of water is between 0-7 or at least that is what we see, where there is a direct physical difference in between every level, I will give an alternate system to what is now being done.

First lets say the water depth is internally 0-15, 0 is still 0, 1 might be enough to wet your feet, as in puddles and brooks, the rest of the values will respond to the values 1-7 by dividing and rounding down for the current effects, as in where you need to swim when you start drowning under bridges and so on.
Not only that, but each water piece between 1-15 will have a speed and a direction, this will also give them momentum as we already have mass for the amount of water in a level.

At each movement the water will move as much as its speed allows (and any sources on the original tile fills up the slack a speed given for the source), if two bits of water should end up on the same tile at the same amount, the water level there will rise and their vector will be averaged if possible, otherwise one of the two bits of water will try to continue to move one tile and have its speed adjusted for it, should it not be possible to speed forward, pressure will be created for the tile.
 If any tile of water has more than two higher water levels compared to the any of the surrounding tiles after moving all water, the speed and vector will be adjusted with towards that place (or if several towards the average direction of them (which might increase or decrease the speed of the water)).
 If the water was indeed standing still, it would move to the empty tile, this will make filling of a water tank directly after a curve in a river somewhat hazardous, not only will you have the speed of the river creating extra pressure within your water tank you'd effectively have a water hammer coming increasing the pressure of your tank even more if you do not have the opposite wall shaped to absorb the waters momentum to any effect.

These things gives us some trouble with making water tanks and such, and because of that I've thought about what a fortification and a pump would do to ease this situation, because they still would with real physics.
-Fortification will only let through water of 2 and higher in the new system, somewhat blocking brooks (pressure buildup will however increase the depth of the brook and flood it anyway), and it will only contain at most 7 water, this will have the effect of requiring higher speed or pressure of water to get through at the same amount as it ordinarily would, (not unlike the small holes in a dam (this also makes it possible for beavers to build beaver dams maybe making the first non cavernous site for non intelligent non civilized creatures)).
-The pump in the ordinary direction would reduce the pressure to zero (if non powered) from water at the same height as it is, it would also only contain 7 water as the fortification, pressure stemming from up to one z level above it will be totally canceled and the rest of the pressure will be converted to speed (as speed in a closed tank is converted to pressure one might have several in a row to decrease pressure however.
-The pump in the reverse direction can be unlocked for a different usage (as in carrying water the other way than it usually does) it will have almost the same effect as the ordinary direction pump but any pressure will be converted to speed, and with the extra effect of if 7 or more water passes through it it will give the somewhat modest power (in water power terms) of 40, this will work in the same manner as modern water turbines, a well constructed dam might even store energy and let out water above any turbine to make it a viable river power source during the freeze of water.

This might or might not be hard to implement, but it would be awesome, (it would also create what is needed for realistic floodplains and even somewhat realistic waves)

EDIT: I also might note that I tend to over-complicate explanations, so if you understand what I mean, like what I say and see how my explanation could be simplified, please tell me and I will change it, also if you'd want the credit for that change I would be more than willing to give it.

/Zorbeltuss who has many times thought about suggesting this but only recently come up with the way to stop the flooding of every fort in existence

[10ebbor10]

This is going to flush your FPS down the drain. And flood your ram as well.

Per tile, you would need:
4 bits for water heights
4 bits for speed (If you limit it to 15)
5 bits for direction

And then you'd still need a way to implement pressure, transfering of momentum, and others. Every turn you would need to calculate the movement of every water tile (and somehow find a way to list them logically), then calculate the new pressure, and then the new speeds resultant from said pressure and new locations. This can ridicoulously complex really fast.

I'm sorry, I don't see this working. The current way is quite accurate, and much more reliable.

[Zorbeltuss]

This is going to flush your FPS down the drain. And flood your ram as well.

Per tile, you would need:
4 bits for water heights
4 bits for speed (If you limit it to 15)
5 bits for direction

I cannot say that it wont flood your ram, it probably won't however, (it depends on how much ram is used for water already), but it is definitely not more than 5 times more than the current usage, in memory, and if you add three bits extra to it you could handle other fluids too or even heavy gasses and wind. and that is a measly 2 bytes, whatever you might think that isn't much.
Anyway, currently it is world generation which is a ram hog, I can't do worlds older than 150 years, but I can make 16x16 forts, if I so wish, considering that a 16x16 fort takes 16 times more ram than the standard 4x4, that my water would be a be a memory hog and fill up the ram, well, have you made any real calculations behind this?

And then you'd still need a way to implement pressure, transfering of momentum, and others. Every turn you would need to calculate the movement of every water tile (and somehow find a way to list them logically), then calculate the new pressure, and then the new speeds resultant from said pressure and new locations. This can ridicoulously complex really fast.

Implement pressure? I can say that that is already implemented, haven't you ever flooded your forts because of pressure?
Transferring of momentum is quite easy, and if you'd wish you can even leave it out, it is still more accurate than the current system.

Unlike the current system, this system will only need to be calulated every time the river changes shape, when that is calculated you know when waves are supposed to be created and such (the waves themselves still need calculation, but that is less than a current big river in calculation).

I'm sorry, I don't see this working. The current way is quite accurate, and much more reliable.

Accurate? Reliable? First, the accuracy of the water in dwarf fortress is currently behaving like a ballpit, secondly you haven't seen my system in code, so you have no idea if it will be reliable at all.

Final words, I've come up with ways to use optimizations which are used in worldgen to speed up my idea, which currently isn't possible with the ordinary system and this system wasn't meant to be implemented now but maybe for the first 64bit release or so, lastly this could be an optional thing like temperature and such while falling back on the ballpit mechanics.

Edit: But anyway, as no one else has commented means that the idea is probably worth scrapping, no not because it is unfeasible but because of lack if interest in actual water streams.

/Zorbeltuss

[Starver]

Well, I just saw the post in passing, when looking for other things to read, and then had to re-hunt off the first page of "(all) unread posts" to chase it up and have to look for it...  Might just be busy at the moment, for anyone not explicitly camping on the Suggestions forum...


I think it'll definitely be a hit on performance, based upon the difference with current implementation.  If it's not particularly selectively implemented right now (say each volumetric tile has a byte reserved, three bits for level, one bit for magma/water, one bit for salinity[1][2], one bit for staleness[1]/whatever, two more bits for things I doubtless have forgotten), then your system is going to demand a big increase (multiply total number of tiles by bytes to be used for new system) in basic memory overheads.

Now, there's ways that this might be optimised.  RLE, for one, KDTree-splitting or otherwise sub-domaining (at least until variance within a domain might as well be explicit for each item, or a large area of "No water" or "All water, stationary" or "All magma, flowing left" getting a quick bounding-box around them).  The trouble then is the updating and changing.  When water flows, things equalise, and all the rest, first of all you have to have a nice way to peek at the values that are there go into the structure (working out where your cells of interest are, if it's not a simple 3D array), and then potentially (when poking back the changes) reshuffle the data structure that holds your situation...

It seems difficult, but I'm probably missing something.


[1] I've no idea if Magma can technically be 'salty'.

[2] A bit that only ever gets set (initially on terrain/biome generation, then when water flows) would explain the "once it's salty, it's always salty!" issue.

[10ebbor10]

This is going to flush your FPS down the drain. And flood your ram as well.

Per tile, you would need:
4 bits for water heights
4 bits for speed (If you limit it to 15)
5 bits for direction

I cannot say that it wont flood your ram, it probably won't however, (it depends on how much ram is used for water already), but it is definitely not more than 5 times more than the current usage, in memory, and if you add three bits extra to it you could handle other fluids too or even heavy gasses and wind. and that is a measly 2 bytes, whatever you might think that isn't much.
Anyway, currently it is world generation which is a ram hog, I can't do worlds older than 150 years, but I can make 16x16 forts, if I so wish, considering that a 16x16 fort takes 16 times more ram than the standard 4x4, that my water would be a be a memory hog and fill up the ram, well, have you made any real calculations behind this?

Depending on how the current system works, it would be 2 to 4 times more, and that's not including the chances to pressure needed. Also, you have a strange computer, mine will crash at anything larger than an 10x10, but can do 1000 year worlds just fine, if extremely slow.

And then you'd still need a way to implement pressure, transfering of momentum, and others. Every turn you would need to calculate the movement of every water tile (and somehow find a way to list them logically), then calculate the new pressure, and then the new speeds resultant from said pressure and new locations. This can ridicoulously complex really fast.

Implement pressure? I can say that that is already implemented, haven't you ever flooded your forts because of pressure?
Transferring of momentum is quite easy, and if you'd wish you can even leave it out, it is still more accurate than the current system.

Unlike the current system, this system will only need to be calulated every time the river changes shape, when that is calculated you know when waves are supposed to be created and such (the waves themselves still need calculation, but that is less than a current big river in calculation).

You'd need to reimplement pressure to make it work with the new system. As you might or might not know, pressure doesn't exist in DF. Communicating vessels are simulated, but the amount of stacked water doesn't change the flow rate.(Except for the part where water teleports under certain conditions). If you want to implement a realistic water system, you should not leave a thing like teleporting water in. After all, weird bugs could happen. Water hitting a curve at high speed would logically move up and overflow the river bancs, but if you were to build a dike there, it would be pushed up vertically. At this point the communicating vessels mechanism would kick in, and teleport the water downstream.

Also, you're constantly talking about speed induced pressure, but completely negate gravity based pressure. You have to do both or none.
As for transferring momentum, you'd probably have to leave that out. Assume 11 water tiles are flowing downriver, and the first one is slowed down, second one colides into it, speeding it back up and causing the comp to have to recalculate tile one again. This way you get 10! calculations that need to be done for 11 tiles. You can solve this of course, by limiting each tile to one calculation/ tick (Transfering of momentum will be unrealistically slow) or by starting with the top blocks(Computer would need to have a way to find out which thing this is, and this would need to be recalculated every tick.)

I'm sorry, I don't see this working. The current way is quite accurate, and much more reliable.

Accurate? Reliable? First, the accuracy of the water in dwarf fortress is currently behaving like a ballpit, secondly you haven't seen my system in code, so you have no idea if it will be reliable at all.

Final words, I've come up with ways to use optimizations which are used in worldgen to speed up my idea, which currently isn't possible with the ordinary system and this system wasn't meant to be implemented now but maybe for the first 64bit release or so, lastly this could be an optional thing like temperature and such while falling back on the ballpit mechanics.

Edit: But anyway, as no one else has commented means that the idea is probably worth scrapping, no not because it is unfeasible but because of lack if interest in actual water streams.

/Zorbeltuss

I pointed out several bugs that would occur, several ways it would wreck your framerate, and I can come up with more. So no, not really reliable . The current system works exceptionally fine for me, and gives a semirealistic implementation, on par with the rest of the simulation.

[Bot Hack]

Considering the density of water at incredibly low temperatures, water under a frozen lake would never completely freeze. It would be fantastic to emulate this, and it would allow ice fishing! I don't know how deep lakes can become, but the frozen one I am at is three layers deep. I suppose keeping a golden ratio would suffice to emulate the physics. Something like 2:5; 2 layers frozen to the whole if 5 layers deep. It would be difficult to calculate freezing water once some Dwarf decides to open a whole in the dirt next to the lake, but I haven't a clue as to how that would work.

[Starver]

Considering the density of water at incredibly low temperatures, water under a frozen lake would never completely freeze. It would be fantastic to emulate this, and it would allow ice fishing! I don't know how deep lakes can become, but the frozen one I am at is three layers deep. I suppose keeping a golden ratio would suffice to emulate the physics. Something like 2:5; 2 layers frozen to the whole if 5 layers deep. It would be difficult to calculate freezing water once some Dwarf decides to open a whole in the dirt next to the lake, but I haven't a clue as to how that would work.

Might I suggest something that works more like...

At "just freezing", it's an ice-floor at surface level but fluid beneath.  Perhaps even "slush" floor that can't be walked upon (slightly colder makes it a "1/7th thickness" of ice floor above the 6/7ths of fluid beneath, and walkable on, or some other abstraction.

Then as temperatures decrease (or, as you come back up as temperatures increase again from very cold) you get depths of ice, beneath which water survives.  Polar winter temperatures mean glacial ice "all the way down" up to some large value (5 to 20?) tiles from the surface, but temperate winters hardly mean one soliz Z-layer of ice, regardless of depth.

Salt water has a reduced (half?) propensity. (Or needs more (double?) sub-zero depression of temperature for the same effect.)  Flowing water also has a similar (smaller) effect, but when a shallower water-feed gets frozen to zero it allows the rest of the water to (potentially, assuming it's not also frozen-through in the flow-to channel, e.g. diverted underground) leak away.  Perhaps a minimally frozen ice surface could cave-in as if it had no support, even if it's Ok to walk on when water fills the gap beneath.

(A think to watch out for for your dwarves and legitimate site visitors, or possibly a seasonal trap for your enemies.)

Of course, there's a lot more code and working out needed to do the more complex aspects.  So, just for simplicity, a linear progression of "surface temperature below zero/(salinity or flow modifier number) -> number of tiles down that ice forms" could be all that's needed.


edit: Ouch, so many typos and awkward grammatical phrases!  I must have been distracted when I wrote this.  But YGTI, I'm sure.

[Bot Hack]

I like the idea. It would save a lot of space under the lake from becoming whole ice chunk layers, basically a glacier. At what temperature does water freeze in-game? I like the idea of 1/7 the thickness of the layer of water freezing and gradually deepening as it gets colder.

This then ties to a thread I read about fluids mixing like blood taking on 7/7 volume like water does.

[GreatWyrmGold]

Water freezes at 0 degrees Celsius (or 32 degrees Fahrenheit), which I believe is 10,000 degrees Urist.

[dwarf_sadist]

This is going to flush your FPS down the drain. And flood your ram as well.

Per tile, you would need:
4 bytes for water heights
4 bytes for speed (If you limit it to 0/15)
5 bytes for direction

Fixed

In a 4x4 embark: 393 kB per z level
In a 16x16 embark: 6.2 MB per z level
Calculate roughly 130z: ~817 MB of RAM


CPU with quasi script and code:
function(fluids) { //tiles & actions per cycle for [4x4][16x16] embark
check each tile for fluids   //532,480  8,519,680

for each tile of water found, do: {
check pressure /, pressure has no direction
check adjacent tiles water level //anywhere from 10 directions to 26
check adjacent tiles pressure
function calculateSpeed();
function tilePlacement();
};


Tell me if I screwed up somewhere. I personally don't think this is practical or that calculating fluid pressure in a detailed way would even run on my computer.

PS: Ignore all the editing I'm doing.