Print

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

[numerobis]

quote:Originally posted by benoit.hudson:
<STRONG>Maybe I should cut a prototype.</STRONG>

So, my idea looks ugly: you get these straight lines of water charging through.

[Nadaka]

No what we really need is a total revamp of the fluid dynamic system.

No more cellular automata. A body of water should be a single entity and calculations only need be performed when its surface is violated. These calculations need not be made for every tile in the volume of the body, but only really for the specific site of "contact" where the water will be flowing + a minor hit to update the overall depth of water in relation to its container. This will fix not only lag issues, but weirdness like water refusing to flow over a cliff.

[numerobis]

quote:Originally posted by Nadaka:
<STRONG>No what we really need is a total revamp of the fluid dynamic system.</STRONG>

You're now going to describe an algorithm we can try out, right?  With some argument about why we should believe that it looks like a proper flow?

[numerobis]

quote:Originally posted by ToxicFrog:
<STRONG>This results in things taking a very, very long time to drain all the way, with attendant heavy CPU load.</STRONG>

Do we actually believe this heavy load thing?  We're talking about pushing an item on a queue, then doing a couple of comparisons and PRNGs, for each '2' in the undrained pond.  I have difficulty believing this is particularly noticeable.

What's noticeable with flows is: (a) opening a big deep pool; (b) flows that separate and rejoin path components.  Both are linear-time operations, rather than piddly constant-time operations.

It looks ugly, though, I'll agree to that.

[Derakon]

I took a major hit for sending water through a new 7-wide tunnel I'd dug that empties into a lake. Even after I turned off the pumps (so no more water was entering the tunnel), everything remained slow, and as ToxicFrog noted earlier, the tunnel is now semi-stable at an average depth of around 1.5. If I had to guess, my fortress is at least twice as slow now as it was when I turned the pumps on.

[Nadaka]

quote:Originally posted by benoit.hudson:
<STRONG>

You're now going to describe an algorithm we can try out, right?  With some argument about why we should believe that it looks like a proper flow?</STRONG>

its beyond the scope of a bug report discussion. But I wouldn't mind looking into it. But it would be convenient if I know the precise algorithm used by Toady to compare against.

[Sowelu]

Bodies of water that aren't completely stable (2s in a pool of 1s, 7s in a pool of 6s) have been known from the beginning of the 3d version to be HUGE lagbeasts.

I really like the surface tension ideas--might as well use them to only happen on a *cliff* and the squares immediately ajacent...

Doesn't solve the problems of an enormous pool split between 1s and 2s though.

[Nadaka]

quote:Originally posted by Sowelu:
<STRONG>Bodies of water that aren't completely stable (2s in a pool of 1s, 7s in a pool of 6s) have been known from the beginning of the 3d version to be HUGE lagbeasts.

I really like the surface tension ideas--might as well use them to only happen on a *cliff* and the squares immediately ajacent...

Doesn't solve the problems of an enormous pool split between 1s and 2s though.</STRONG>

if the surface of a pool is a single volume, rather than a set of connected cellular automata then there would be no (or virtually no) CPU hit from random walk water particles because the volume of water held could be a single value.

Of course it wouldn't be as "pretty" as watching the waves generated by the random walk algorith.

[zagibu]

quote:Originally posted by Exponent:
<STRONG>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.</STRONG>

I think this would be the easiest solution with the current model.

[numerobis]

quote:Originally posted by Nadaka:
<STRONG>

its beyond the scope of a bug report discussion. But I wouldn't mind looking into it. But it would be convenient if I know the precise algorithm used by Toady to compare against.</STRONG>

The gamasutra article and provided enough detail to reconstruct something that acts pretty similarly on a given z-level; I can mail you the C code (with the vectors idea) if you want to play around with it.

[Nesoo]

This reminds me of splashing magma as well. A few times I've sealed off a magma tube with water to prevent the nasties from getting out, and occasionally some of the magma splashes up, so you'll get a little red 1 zooming around on the surface despite there being a few 6's below. I think it just happened to be on a spot with 7's, so it won't go down. I've even had a few reach the shore! That was several versions ago though, so I don't know if this still happens on occasion.