This is a lot like my Generating a Wind Model thread. I'm still building up to that stage. Right now, I'm working on adding flowing water to the game.

Basically, you have your terrain and one of the functions you can do is add water at any given point of the graph (currently, each graph is made of nodes that each have a height and the amount of water on that node). The water needs to flow appropriately.

My current algorithm works decently, but becomes a problem after a while. Here's what I'm doing, in semi-pseudo-code.

add_water:
Calls raise_water (by a defined amount of water) at node(mouse_x, mouse_y). lSegment is set to this node and the update_water function is then called.

update_water:
Moves through linked list of all nodes that have water on them. To keep from tieing down the program, only a segment of the list is allowed during each game loop. lSegment defines where the list needs to update. Each node that does get updated in this function calls balance_water.

balance_water:
Calls moveable_water to find the locations where water can move to. Add 1 to this value to account for current position. Divide the amount of water at the node being balanced by the amount of moveable locations (with the added one). Lower the node to this amount (using lower_water) and add (using raise_water) this amount to each node the water can move to.

moveable_water:
Takes the height plus the amount of water on the current node and sees if it can move to the adjacent nodes' height + water. Calculates which adjacent nodes it can move to.

raise_water:
If the node we are adding water to does not have any water on it, add this node to the list of water (so it can be updated in update_water). Next, add the given amount of water to this node.

lower_water:
Take away the amount of water given. If the amount of water at this node is below 0.01, then set this node to have 0 water and remove the node from the list of water (so we don't have to worry about updating it again).

Like I said, the above works, but has a few problems. One thing that I should mention is the nodes are 1024 X 768 (each pixel is a node). Fortunately, this can be easily changed to 640 X 480 or even 200 X 200 the way I've set up my code. However, I want to try and have as many nodes as possible and the program still function. The algorithm works fine until you've added too much water. Then, via the segmented list, sometimes it takes a long time for some water to be updated, and appears frozen (which is uncharacteristic of real water). Note: the update_water function calls draw(node.x, node.y) for the nodes it updates. This function calculates what the pixel should look like based on how much water is on it and putpixel's it to the bitmap that eventually is output to the buffer and then to the screen.

I've never done any particle work before and all the above was completely experimental. If any one has any advice or if I need to supply more, I would greatly appreciate it. As I was writing this post, I got a few more optimizations that I'm going to try now.

Thanks in advance!

i cant picture it is this for 2d or 3d?

Yes! The fist of knowledge delivers the punch of advice into the face of problems!

I only make these posts so you can post when you make progress, you know.

I love the way water ripples in FB. It's such a nice little feature that's not a necessasity, which makes FB all the more brilliant.

Anyway, I let my current program run on a 100 X 100 graph with a few hills and added some water at different locations. I then went and took a shower, watched some TV, conquered a small country, followed by reading a gardening book while making an ice sculpture of a gnome. When I came back, the water had spread out across the 100 X 100 graph and was continually expanding and contracting across the graph. I was happy to see a few waves form as well. However, 100 X 100 is way too blocky and it still took forever, but it's good to know the algorithm is doing what it is suppose to, so when I switch to polygon nodes it will hopefully be what I want. One problem I did find was the count of nodes. I had a debug message relay to me how many nodes with water were being worked on. It said over 20,000! Now, with a 100 X 100, the max should've been 10,000. I've got some kind of anomaly producing unwanted nodes.

On the topic of polygons, I had a few minutes to write some code. I made a mistake in my recursion that caused each polygon to be too long, but that can be easily fixed. Wish I could work on it, but I'm doing a double shift at work today (and tonight).

It might be a lot of redesigning, but I'm sure it's possible. If the current solution doesn't provide the necessary results, I'll definitely look into it.

Here's an update on the polygon status. I've got the polygons, but the algorithm is currently not implemented for using it. Here's a test I did to make sure the polygon's were setting up correctly.

This is a picture of the terrain (with only red as the color, instead of green and blue above...)
http://comp.uark.edu/~spsilve/planet2.bmp

Here's what the polygon creating algorithm produced after translating the pixel by pixel setup to groups of pixels (aka polygon). I dyed each pixel a random color to differentiate the polygons. The random spot of dark blue was me adding water to the mix (and like I said, that is not working on the polygon setup yet). And of course, a few debug messages.
http://comp.uark.edu/~spsilve/planet2a.bmp

Lastly, I thought I'd mention that 51,000 polygons of max area 10 were produced (they are produced by grouping nodes that are relatively close in height). This is a 640 X 480 graph, so originally there'd be 307,000 nodes. Thus, this reduces my work size by about 600%. One foreseeable problem would be as CGames mentioned, in moving from one polygon to the next (especially the ones that turned out long and stringy).

If I get a chance before I head out for vacation, I'll see if I can get the water to work with the polygons instead of at the pixel level. Any comments are always welcome.

Actually, I'm only looking at 4 nodes with the non-polygon algorithm (above, below, left and right). Also, it doesn't always move to the 4 nodes, particularly when a node is higher than the node being balanced.

Nonetheless, I might be able to incorporate a bitwise operation somehow to optimize it. Hopefully I'll have at least some time to work on it tonight.

Alright then, time for a little update. I've got the water acting with polygons now, although there is plenty for me to optimize in the polygon setup. Even with the unperfected setup, it is quite an improvement from the original. One method I hope to implement is the rectfill hack for polygons, somewhat mentioned here.

However, I'm not satisified with the current results. I will probably try to do the shift bits method this weekend as well to compare and contrast. Here's a picture of the reddish world with some water added on. Here, I've made the polygons very small (can only hold about 5-10 pixels in a polygon). You can see on the bottom left there are over 4000 polygons that have water. And yes, the color of the water is still kind of odd, bear with me.

http://comp.uark.edu/~spsilve/terrain3.bmp

I'm doing something similar in a 3d game. I'm only having nodes at the vertices between the tiles, which vastly reduces the number. The water height is stored as absolute height above sea level, and so the zbuffer is used to decide how far up the slopes (in pixels) the water is drawn.

You could do something similar on your 2d terrain by having nodes every 4x4 pixels or so.