"pan" <pan### [at] syixcom> wrote:
> "Kirk Andrews" <kir### [at] tektonartcom> wrote in message
> news:web.494144ad151cbdc1da29fa390@news.povray.org...
> > 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.
> >
>
> After reading this thread so far, there is one element that is missing and
> might lead to a different approach.
>
> Water flow and accumulation and erosion depends more on ground
> composition than anything else.
> At high altitudes it is likely you have hard rock surfaces that result in
> movements of thin sheets of water.
> If you think about it, the lower you go in altitude the 'softer' the material is
> and thus the greater effect water has on surface deformation.
> The volume of colected and moving water will channel through a
> linked chain of soft areas. Soft areas will grow with time.
> (movable debris goes downhill.)
> Also- water falls on surfaces not at discrete target points, but as a
> general area effect. Accumulation is a differential process that
> changes at particular points depending on what the nearest neighboring
> points are doing.
>
> So - what to do? Add an array (or other data keeper) that tracks the
> relative 'softness' of a determined delta of surface.
> Assume something about average rainfall/snowfall, temperatures and
> whatever else seems pertinent.
> Search for points or areas that are the softest at the highest altitude
> and calcualte average accumulation based on slope, etc.
> Once you have these starting points your pump, so to speak, is
> primed and then you can make subsequent passes over your data to
> simulate a dynamic re-distribution of water stores.
> (the array of point softness will change with time)
>
> Detailed granularity of your analysis will make for a better simulation
> and might make the actual cranking out of implementation code
> easier as you will not box yourself into so many untenable concepts.
>
> Oh - yeah - springs will be a whole different layer of complexity you
> might add. Water seeps down into underground spaces and follows
> its own unseen path to 'spring' out at locations that might never see
> rainfall or might seem to defy local topology.
>
> Go for it - I don't think you can ever get to a final, all encompassing,
> method, but the journey should be fun.
>
> Hope some of this sparks your imagination.

Good point, and one that I had actually already started to implement in the
array method.  Basically, the strength of the erosion effect is proportional to
the softness of that particular point.  Once soil has been moved, the current
point decreases in softness (some of the moveable debris has be removed
already) and the the receiving point increases in softness.  I would need to
work out the details--I've tried giving every point a starting value of .5, and
I've tried varying it by height, which was promising but needs refining to get
the values right.

To join in the discussion about programming languages, I will have to agree with
clipka at this point--SDL is far to slow for this method.  It seems to me that
these calculations ought to process fairly quickly, being little more
complicated than Photoshop filters (which render within seconds, even on huge
images). Right now, one erosion pass on a 2k x 2k hf takes about five minutes.
Maybe after my paper is finished and I have more time, I'll try Python again to
see if I can do the same thing there.  I could post my SDL code is some of you
programmers wanted to go ahead and put in a real programming language
(preferably one that I could figure out without a degree in computer science).

Post a reply to this message