Floody water

[xoft]

I've created a new SVN branch to play with an algorithm for water physics that I've wanted to try out. I call it "floody water", because what I expect it to do is to distribute water much more aggressively than the vanilla algorithm, yet it should be perfectly predictable, unlike our current fluid simulator.

The general idea is to completely remove current fluid simulators, then code the fluid physics in the block update handlers. The block udpate handler will decide if it wants to flow or not, based on the block ID (same as vanilla MC; the reason for having still-water and regular water); if it wants to flow, it will check the immediate neighborhood of itself in 4 directions and try to flow into all 4, if possible. Then it will mark itself as having flowed, not wanting any more updates, until a block next to it updates.

The vanilla algorithm tries to search for a "hole" that would allow it to flow lower, and then only flows towards such a hole. "Floody" will flow all over the place, reaching not only the hole, but all its surroundings.

I believe it will be possible to finally include a switch and have the world use either Floody or Vanilla algorithm, based solely on server admin's desire.

[FakeTruth]

Isn't that like the original water in Minecraft? Where one high water block would flood then entire world?

[xoft]

No, not that kind. I will make water levels disappear just like in vanilla, only I won't make the water head toward lower areas, I'll let it go in all directions.
When I come back from work in the evening, I'll try to snap a few pictures of what it'll look like; I'm rather good with water routing in vanilla, so I think I'll be able to simulate this behavior

[NiLSPACE]

maybe can you make the water just like minecraft. it generates the water that is not flowing (ID=9) and when it gets a update it changes to 8 so it will flow.

[xoft]

Yes, I'll be using the same algorithm to ease the updates. But vanilla's way of calculating flow is a bit too CPU-intensive, I think Floody will do much better CPU-wise. Of course, I'd like to implement both, in the longer run.

Here's the promised pictures:
Situation 1, vanilla algorithm. The water source is under the stone ^-shape, top right:


Same situation, Floody algorithm:


Situation 2, vanilla algorithm. The water source is the "spring" in the wall:


Situation 2, Floody algorithm. Notice the awesome water curtain it produces:

[NiLSPACE]

thats actualy pretty cool but it wil break some constructions people make :S so a swich is smart to add like you said

[xoft]

I think Floody is better than our current water physics, so if I manage to implement it, it will be better, even without the switch. Until someone finds the time to write the vanilla algorithm, too.

[NiLSPACE]

this is better than the current water physics thats for sure but are you only working on the water or wil a new lava algorithm be added to?

[FakeTruth]

Ah, that's what I imagined it would do. Looks nice

[Taugeshtu]

Idea time:
what if "floody" will check for the ammount of still water blocks adjascent to the processing flowing water block and will tune its spread ammount based on that ammount? (big lakes of still water would produce big floods, one block would produce a tiny spring)

As for "speed" - we could search like in 5x5x5 box.

One more crazy idea: block-dependant water drain. Sand would make water drop it's level much faster than stone, for example (i.e. one water block would produce lesser "flowing water spot")