I've got a paper due, so once again I am POV-ing.

I'm trying to calculate the flow of water across a terrain, so that hopefully I
could eventually add realistic rivers, gullies, and ponds to a terrain.  It
ought to be possible to feed the water flow information back into the function
used to create the terrain itself, to create erosion.

So far, my code simply picks a random starting point, checks the altitude of
points around it, and chooses the lowest point. Then it repeats, creating cones
to indicate its path.

When the lowest new point is higher than the current point, water ought to
collect.  I've tried adding code to create ponds where the water ought to
collect, but I'm running into weird problems.

I'm posting in the hopes that perhaps some of the brilliant minds around here
could improve upon what I'm doing.  In fact, I'd be surprised if no one around
here has tried this before, but I couldn't find anything like it yet.

Post a reply to this message

Attachments:
Download 'water201.jpg' (72 KB)

Preview of image 'water201.jpg'

Another:

Post a reply to this message

Attachments:
Download 'water205.jpg' (63 KB)

Preview of image 'water205.jpg'

500 streams:

Post a reply to this message

Attachments:
Download 'water206.jpg' (73 KB)

Preview of image 'water206.jpg'

"Kirk Andrews" <kir### [at] tektonartcom> wrote:
> 500 streams:

With some small ponds, now.  Not quite the lakes that I want, but it's an
improvement.

Post a reply to this message

Attachments:
Download 'water207.jpg' (267 KB)

Preview of image 'water207.jpg'

"Kirk Andrews" <kir### [at] tektonartcom> wrote:
> So far, my code simply picks a random starting point, checks the altitude of
> points around it, and chooses the lowest point. Then it repeats, creating cones
> to indicate its path.

So you're actually simulating the path of "droplets" down the terrain, right?

Hm... I'm not too familiar with this, but it's an interesting subject. And what
you achieved so far looks quite good already.


> When the lowest new point is higher than the current point, water ought to
> collect.  I've tried adding code to create ponds where the water ought to
> collect, but I'm running into weird problems.

Hum... what kind of problems do you get?


I'm thinking about what could possibly go wrong, and I'm coming up with these
issues:

- You have multiple options where to place cones while tracing the droplet's
path. If you place it at the point where the droplet moves to, you may be
ending up with pools being eroded further as water accumulates in them, which
is not realistic. So I guess the right thing is to place the cone where the
water comes *from* for every move.

- You need to take into account the slope of the terrain. Shallow areas lead to
a slow movement, which has less of an eroding effect.

- Actually, you may want to simulate that the droplets carry the eroded material
with them, depositing them where the water runs quite slowly.

- You may also want to take into account the speed of a droplet; moving along a
downward slope will accelerate it accordingly, and the current speed &
direction give it a bias for the direction of the next movement step, allowing
it to even travel slightly uphill. Furthermore, if a droplet's direction of
movement changes, erode the terrain in the original movement direction a bit.
This should allow you to get maeanders and such.

- You may also want to do some erosion of extreme terrain slopes even without
water being involved. Think of crumbling cliffs and such. (Note that material
deposited this way will in reality be more susceptible to further erosion
effects. Once it's crumbled, it's crumbled.)

- To simulate pools, one possible solution would be to add another layer above
the terrain that indicates how much water is currently "standing" there. A
droplet currently under simulation would continue "flowing" across this "lake
surface" (without eroding it of course, but maybe depositing eroded material on
the "lake bed" below), again until it cannot move further. At the place where it
comes to rest, raise the "lake surface" a little bit.

- If water flows across a "lake surface", then hits dry land again *and* can
continue to flow, remember that spot because your new droplet has just eroded
the shore a bit; as soon as you're finished with the current droplet,
pick a random droplet from the lake adjacent to the eroded place, and have it
flow out.

- Simulating layers of material which exhibit different resistance to erosion
will make for good effects I guess.


Just a bunch of thoughts that crossed my mind about this. They may be unrelated
to your actual problem though, so for further hints we'd probably need a
description of the issues you have with the pools.

Post a reply to this message

"Kirk Andrews" <kir### [at] tektonartcom> wrote:
> When the lowest new point is higher than the current point, water ought to
> collect.  I've tried adding code to create ponds where the water ought to
> collect, but I'm running into weird problems.

Please describe in more detail exactly what the problems you are encountering
are.

-Mike

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> "Kirk Andrews" <kir### [at] tektonartcom> wrote:
> > When the lowest new point is higher than the current point, water ought to
> > collect.  I've tried adding code to create ponds where the water ought to
> > collect, but I'm running into weird problems.
>
> Please describe in more detail exactly what the problems you are encountering
> are.
>
> -Mike

Well, I think I've solved that problem by using a different technique now.
Earlier I was trying to use triangles to create the pond surfaces, now I'm
simply using a cylinder which is easier and has more benefits anyway.

I'm trying to decide the best way to take this to the next phase--actually
deforming the terrain based on the paths of the water, as clipka discussed.
Perhaps you could store the altitude of each point of the hf in an array,
subtracting and adding to the altitude based on the water movement.

Post a reply to this message

"Kirk Andrews" <kir### [at] tektonartcom> wrote:
> I'm trying to decide the best way to take this to the next phase--actually
> deforming the terrain based on the paths of the water, as clipka discussed.
> Perhaps you could store the altitude of each point of the hf in an array,
> subtracting and adding to the altitude based on the water movement.

Now that I'm reading this... you're not actually doing this in PoV-ray's Scene
Description Language, are you?!

You must be mad! :)

I'd recommend some mainstream programming language, and exporting only the
*final* results of the sim to an SDL.

Performance of the SDL parser is *very* poor compared to compiled languages
(C/C++ or Visual Basic come to my mind) or VM-based languages (like Java or
C#), and given what little language constructs SDL provides I guess it's also
much slower than full-fledged scripting languages (e.g. JavaScript, Perl or
what-have-you).

Well, whatever you like :)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Kirk Andrews" <kir### [at] tektonartcom> wrote:
> > I'm trying to decide the best way to take this to the next phase--actually
> > deforming the terrain based on the paths of the water, as clipka discussed.
> > Perhaps you could store the altitude of each point of the hf in an array,
> > subtracting and adding to the altitude based on the water movement.
>
> Now that I'm reading this... you're not actually doing this in PoV-ray's Scene
> Description Language, are you?!
>
> You must be mad! :)
>
> I'd recommend some mainstream programming language, and exporting only the
> *final* results of the sim to an SDL.
>
> Performance of the SDL parser is *very* poor compared to compiled languages
> (C/C++ or Visual Basic come to my mind) or VM-based languages (like Java or
> C#), and given what little language constructs SDL provides I guess it's also
> much slower than full-fledged scripting languages (e.g. JavaScript, Perl or
> what-have-you).
>
> Well, whatever you like :)

Well, that'd be great, of course, except that I don't know any *real*
programming languages.  I'm a theology student, not a programmer!  I started
learning Python once but I've never had the time.  Most everything I know about
programming I learned in POV's SDL.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> I'd recommend some mainstream programming language, and exporting only the
> *final* results of the sim to an SDL.

I have to disagree with this statement. There's nothing wrong with POV SDL. The
only tricky bit is converting between data formats (i.e. HF, mesh and/or
isosurface).

-Mike

Post a reply to this message