Working on a ambitious world generating tool...

[Sigurd]

One thing to talk about how it should work in theory, another to see it through to the trials and compromises of completion.

How bout a working demo Nick ?

Sigurd

[Nickadimos]

Sigurd,

In all theorys of course you need proof. And of course you have skeptics. .

But you see my proof in my image that I provided.

I did all the steps from my explanation manually and slowly.. took 4 hours..

Its not as perfect as it would be if it was coded with a nice interface to work from with a more direct approach instead of the color select tool and 800% zoom.

And would take minutes if it was in a prog.

And of course, the whole purpose behind explaining the Chaos theory in the first part, was to explain my method. We arent trying to implement the Chaos theory in the program, were taking a feather out of its hat.

Im not a coder so I cant make it.

They also use a similar system in L3DT with thier rivers and such. Mine is just simpler still.

Thanks!
Terry

[Redrobes]

Aaron of L3DT does not do it your way. Here is a quote from him.

The 'dropwise' algorithm I use (I've coined another one!) simulates the path of each drop individually, which has certain limitations, but works well with large tiled data that's too large to hold in memory all at once (crucial in the context of L3DT.)

He has two models one of which he has released in his app and the other (at least as far as I know) he did not because its too slow. The dropwise algorithm he talks about takes a drop of water at each pixel and looks to see where it flows to get to the sea by moving to the lowest point adjacent to it. Eventually it must either pool or hit sea. He then aggregates the amount of water in each pixel and draws rivers where there is a lot of water. Makes sense and is the simple 'water flows downhill' theory.

It has limitations and he knows all about them. If you are on a flat-ish plane near the sea and this plane is like a mud flat then in this algo the water takes the most direct course to the sea. Usually in a few straight line sections. In real life it does not because sediment is dropped and the river changes direction. If you don't drop sediment then it wont meander.

Your straight down to the sea idea is fine in only a limited instance and the reason why you haven't found why it doesn't work so well is that you haven't programmed it and haven't tested it. If you look at your height field in 3D you will see that its actually a mass of spikes in which the water droplet will fill a depression and clog. With no accumulation it will stay there and fail. If you accumulate then you have a series of pools which will spread out and because you cant model the very low viscosity of water then it will spread out in a fan like direction instead of a nice thin line to the sea.

If your looking for the highest and lowest points and then interpolate then that's fine for the top & bottom but you have a million middle points in your spiky terrain to choose from and even then how do you know that you wouldn't have to go up hill before going down again to make that line.

So we need to see a working program that we can enter some height fields in and watch it plot water courses. Nothing else will cut it. Theres a lot of experienced and bright people looking at this problem and its not all that simple.

[Nickadimos]

RedRobes;

The dropwise algorithm he talks about takes a drop of water at each pixel and looks to see where it flows to get to the sea by moving to the lowest point adjacent to it. Eventually it must either pool or hit sea. He then aggregates the amount of water in each pixel and draws rivers where there is a lot of water. Makes sense and is the simple "water flows downhill" theory.

You do realize that is almost exactly what I said right? (where do you think i even got the idea from??) Did anyone even read what I wrote?

Except mine is WAY simpler and doesnt allow water to pool as much. Mine goes from pixel to pixel just the same high to low, except instead of finding the next lowest point, it finds the very next lower color on the height-map.

Which, in so many ways is the same cause you use color to determine height anyway, but it is not as absolute as the very next total lowest point.

The other major difference is the fact that the whole drop of water at every pixel then tracing between the ones that form a pool of water, is an over complicated way of just saying here are the lowpoints.

In my method it finds the high middle and low points, then you can choose which ones you want to keep, then it traces in between them following my basic subtraction method.

This is better cause you dont end up with any suprize pools of water or rivers.

What this method fixes is the tendancy for things to pool and the algo to fail.

The reason that the dropwise algorithm method fails so often is because of the method itself. It finds the absolute next lowest point, which could very easily be a height considerably lower at the next pixel.

Aarons,
Say it is at 240 White, the program checks all 8 of the adjacent pixels, starting at the top left they are, (S = start) (U = used once)

238 - 246 - 220
190 - S - 224
168 - U - 222

Now the path that the dropwise method will take is easy to figure out. it will go to 168 because that is the lowest next pixel.

In my method,
Say it is at 240 White, the program checks all 8 of the adjacent pixels, starting at the top left they are, (S = start) (U = used once)

238 - 246 - 220
190 - S - 224
168 - U - 222

Now the path that mine will take will be 238. because it is the very next lower pixel. Not the lowest.

It has limitations and he knows all about them. If you are on a flat-ish plane near the sea and this plane is like a mud flat then in this algo the water takes the most direct course to the sea. Usually in a few straight line sections. In real life it does not because sediment is dropped and the river changes direction. If you don't drop sediment then it wont meander.

I agree that this is could be a fundamental problem with both mine and aarons methods But also remember that mine finds its way from lowest point to lowest point (main rivers) by counting up as outlined in my first post and the only river/rivers of water that go to the sea are the ones you choose to go there...

Your straight down to the sea idea is fine in only a limited instance and the reason why you haven't found why it doesn't work so well is that you haven't programmed it and haven't tested it(1). If you look at your height field in 3D you will see that its actually a mass of spikes in which the water droplet will fill a depression and clog(2). With no accumulation it will stay there and fail. If you accumulate then you have a series of pools which will spread out and because you cant model the very low viscosity of water then it will spread out in a fan like direction instead of a nice thin line to the sea.

As previously explained, its not strait down to sea, its strait down to the next midpoint, then the next lowest points, that you chose to leave behind once the high, middle, and low points were all determined in the first part.

(1) I have tested it,

But you see my proof in my image that I provided.

I did all the steps from my explanation manually and slowly.. took 4 hours..

Its not as perfect as it would be if it was coded with a nice interface to work from with a more direct approach instead of the color select tool and 800% zoom.


(2) I made that heightfeild in L3DT by the way. I own the professional version. I beleive it got pixelated when saves as a jpeg from L3DT to gimp to here and thats why you would think its a ton of spikes...

I could make another picture at the pixel level if that helps more.

And please read the rest of what I wrote.

What we do need, is something that is in between the two methods I would presume.

Thanks
Terry

[Redrobes]

Terry, I will look at it some more. Maybe I didn't read it well enough. I have read it again and I still don't see how by looking at the next lower value it will work any better than using the lowest point. It still seems as though you can almost immediately run into a dead end pooling situation in the same way. Its a bit late here so ill try again shortly and I might even code up the app for you because I am interested to see it too. It should not be difficult for me to write something to take a 64x64 image which has large blocks to see the action.

[Nickadimos]

I will however digress and admit that I am terrible at getting my thoughts on paper in a clear and concise way as I am dyslexic.

90% of the time it seems like im being mean or sarcastic or whatnot. If we were talking face to face and i could use my hands to talk to you we would be in like flint.

Just please try to remember that about me guys..

Im a great public speaker.. LOL

Terry

The little faces help!

[Nickadimos]

This is a simple as I can make to show the difference between the My method and the L3dt method..

The Blue line is the path that L3DT would take.

The Red Line is the path mine would take.

Terry

[Wordman]

This is a simple as I can make to show the difference between the My method and the L3dt method.

That's exactly the correct image to illustrate the difference. Unfortunately, if you spilled water on the white triangle, the vast majority of it would almost certainly follow the blue line, not the red one.

[covatex]

Let me see if I get Nickadimos's algorithm right:
1.- Find the highest, lowest and mid points
2.- Let one highpoint be the actual pixel
3.- Starting from an actual pixel, test the 8 non-used adjacent pixels looking for the lower color (or altitude) that is the closest to the starting center point. (Not the lowest one, but the color closest one, in other words look for the minimun nonnegative difference between the center and the 8 neighbors)
4.- Mark this neighbor "used" and make it the actual one.
5.- Repeat from 3 until we reach one nonmarked midpoint pixel, or we get out of the map. Mark this midpoint
6.- Do the same, but in reverse order from a lowpoint until we reach a midpoint

Is that correct?

If so, I'm not getting the expected results... Look at the pic...

[Redrobes]

If your able to run this through then it would be great. I was expecting to have to write something to show what it might do later this evening so if you have the framework available that would save me some time. Are you able to show whats happening with zoomed up tiles so that the black line doesn't obscure the height map underneath. If not, are you able to show the height map before the line was drawn too so that we could clip out that section and follow it through ? What we need to do is pin down either why its not working or why what your doing is different to what we think we need to do to follow the algorithm.

I agree with Wordman in that water would flow to lowest point and thats what most people have done but we also know that it tends to stall quickly by hitting locally low points with higher pixel values all around it. You can avoid this by accumulating water in that ditch, filling it up until it overflows and that's what Aaron of L3DT has called a continuum model instead of the drip model. This is the kind of model I think he has programmed and not released because its a lot slower as it means you have to iterate a lot before it starts to overflow. It is the basis of how I do it in GTS however which is why it takes hours for my app to run.

Heres a link to Aarons posts on L3DT, its a bit old tho - maybe he has done more work in this area.
http://www.bundysoft.com/phpBB2/viewtopic.php?t=404