"SharkD" <nomail@nomail> wrote:
> "Kirk Andrews" <kir### [at] tektonartcom> wrote:
> > 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.
>
> Awesome! Please share your results in either case. I have a planetary surface
> pigment that could benefit from such a technique.
>
> -Mike

Well, I'm on another computer right now so I don't have the code I used, but it
really is quite simple.  This is the basic idea:

1.  Choose random staring point on surface (using trace).
2.  Using trace, check the altitude of several points at a specified radius.
3.  Choose the lowest of these points as the current direction and new starting
point. Create a cone between old point and new point.
4.  If the altitude of the lowest point is actually higher than the starting
point, create a pond (using a cylinder at the altitude of the lowest point).
5.  Repeat X times to create a whole stream.
6.  Repeat the whole thing X times to create more streams...

It could be improved by developing a better way to simulate the accumulation of
water.  In this method, the potential size of any body of water is quite small.
 I would like to be able to fill up whole lakes (or oceans in you case,
perhaps?).

Post a reply to this message

Kirk Andrews wrote:
> 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.

I worked on something similar months ago:
http://news.povray.org/povray.binaries.images/thread/%3C489e1fe2@news.povray.org%3E/?ttop=290287&toff=100

But my technique involved simply moving the next point according to the 
normal of the hf at any given tested point. This was a sloppy way of 
handling it, because oftentimes there would be a "ping-pong" effect 
along the rivulets. I had originally considered testing the lowest point 
like you do, but ended up going forward with the easier way, which 
turned out being difficult to work with :( Attached is an image I 
rendered today using my trace/normal technique. I managed to improve the 
shading somewhat, allowing the rivulets to "cut" into the height field 
pattern in one render step. If I work on this again, I think I will try 
to test for lower points (like you are doing) instead of using trace(). 
It can be done by testing patterns, which might reduce the parse times. 
In fact, erosion could take place during an animation sequence, with 
erosion working on earlier erosion over time, without using height 
fields at all... Hm.

Sam

Post a reply to this message

Attachments:
Download 'erosion_test.jpg' (33 KB)

Preview of image 'erosion_test.jpg'

stbenge <THI### [at] hotmailcom> wrote:
> Kirk Andrews wrote:
> > 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.
>
> I worked on something similar months ago:
>
http://news.povray.org/povray.binaries.images/thread/%3C489e1fe2@news.povray.org%3E/?ttop=290287&toff=100
>
> But my technique involved simply moving the next point according to the
> normal of the hf at any given tested point. This was a sloppy way of
> handling it, because oftentimes there would be a "ping-pong" effect
> along the rivulets. I had originally considered testing the lowest point
> like you do, but ended up going forward with the easier way, which
> turned out being difficult to work with :( Attached is an image I
> rendered today using my trace/normal technique. I managed to improve the
> shading somewhat, allowing the rivulets to "cut" into the height field
> pattern in one render step. If I work on this again, I think I will try
> to test for lower points (like you are doing) instead of using trace().
> It can be done by testing patterns, which might reduce the parse times.
> In fact, erosion could take place during an animation sequence, with
> erosion working on earlier erosion over time, without using height
> fields at all... Hm.
>
> Sam

Ah yes, now I do remember that previous post!  I thought someone had starting
working on something like this.  My first attempt tried using the normals also,
and it wasn't working nearly as nicely as the lowest point version.

You're quite right.  Instead of actually making the hf, why not just define an
initial function, and then simply evaluate the function at the appropriate
points?  The problem then is this--how do you feed the erosion data back into
the function?

I am imagining a few possibilities, but none seem as simple as it should be:

-- you could create the cones and render with an orthographic camera to create a
16 bit tga (to be add/subtraced/averaged with the original hf function).

-- you could create the cones and use it to create an object pigment, to be
subtracted from the original function.

-- you could put the function into an array, with a pointer for each pixel in
what will eventually be a tga, and mathematically edit each point according to
the erosion function, and finally create the tga by making one pixel-sized box
per pointer in the array.

Surely someone can think of a better way?

Post a reply to this message

Kirk Andrews wrote:
> stbenge <THI### [at] hotmailcom> wrote:
>> I worked on something similar months ago:
>>
http://news.povray.org/povray.binaries.images/thread/%3C489e1fe2@news.povray.org%3E/?ttop=290287&toff=100
> 
> Ah yes, now I do remember that previous post!  I thought someone had starting
> working on something like this.  My first attempt tried using the normals also,
> and it wasn't working nearly as nicely as the lowest point version.
> 
> You're quite right.  Instead of actually making the hf, why not just define an
> initial function, and then simply evaluate the function at the appropriate
> points?  The problem then is this--how do you feed the erosion data back into
> the function?
> 
> I am imagining a few possibilities, but none seem as simple as it should be:
> 
> -- you could create the cones and render with an orthographic camera to create a
> 16 bit tga (to be add/subtraced/averaged with the original hf function).

This is pretty much the way I planned on doing it. It simplifies the 
process, and with several animation frames I can erode the pattern in 
steps. This just leaves two steps: one for the creation of the height 
field's pattern, and one for rendering the height field.

To this end, I just now managed to adapt the Round_Cone2() macro to 
connect two +y cones with triangles. This gives me an object with a 
smooth a transition between the cones and triangles. The object makes a 
ridge which can be rotated in the direction of the lower point. The 
ridge can then be used to subtract height from the pattern to create 
sharp gullies. I have attached an image showing what the ridge looks like.

Sam

Post a reply to this message

Attachments:
Download 'ridge.jpg' (9 KB)

Preview of image 'ridge.jpg'

Well, I went ahead and did a small attempt at the array possibility.

I create an array based on values from a pigment function, exactly like an hf
would.

In this case, in each erosion pass I reevaluate every single point, subtracting
from higher points and adding to the lowest adjacent pixel.

It's pretty slow, this render took over eight minutes to parse with a resolution
of only 300x300 (of course, there's some extra time for actually creating the
meshes for each pass).  It probably would be a good deal faster in C++ or the
like.

Evaluating each pixel may not even be what is wanted.  It may be better to
return to the stream technique I had used before.  The current technique
softens the landscape, and there's some indication that perhaps gullies are
beginning to form, but there's too few passes and the resolution isn't good
enough to tell.

Post a reply to this message

Attachments:
Download 'erosiona.jpg' (147 KB)

Preview of image 'erosiona.jpg'

This is already looking quite good and interesting. Apart from the comments 
already given, I think you should consider critically the random selection 
of your starting point. If you look carefully at your images, you will see 
that sometimes a rivulet starts on a ridge and flows down more or less along 
a ridge, which is unnatural of course. And rivulets start sometimes just 
beside a natural indentation of the surface, instead of starting in the 
indentation itself. This is a kind of chicken-and-egg conundrum of course as 
a rivulet creates an indentation which in turn attracts more rivulets etc. 
Still, I think you should consider the "randomness" of your starting points 
as you start already with a fully formed landscape in the first place. This 
means that the starting points cannot be random at all.

Thomas

Post a reply to this message

I feel that I am joining this discussion quite late on however I do have
something of worth (hopefully) to add. Having said that I am not entirely sure
of the applicability to this situation.

If one uses an actual function to generate the original surface then there are
methods using integration and differentiation along with other mathematical
operations which allow one to find the steepest path (another function) down a
surface starting from any given point. This would mean no requirment for
evaluation of many many equations but rather a few simple calculations.

Also I am fairly sure that the generated functions could also be used to then be
subtracted from the original function and hence fed in to simulate erosion. As a
mathematician I would highly favour this method as it potentially might cut a
vast amount of calculation in pov. As a method it also suits pov SDL quite
well.

I can rake up the details if anyone is interested? I will be following this post
closely to see what the conclusions to this discussion are.

Malcolm

Post a reply to this message

"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.

Post a reply to this message

"SharkD" <nomail@nomail> wrote:
> "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

Mike, there is *A LOT* wrong with POV SDL if you try to mis-use it as a
full-fledged programming language:

- No support for data structures other than arrays
- Poor performance with sub-routines (macros are parsed over and over again for
each invocation, and there is no alternative that would be pre-compiled)
- Inconsistencies as to built-in functions & variables (not all are available in
user-defined functions)
- No native support for integer numbers
- Inconsistent support for vectors (speaking of user-defined functions again)
- Poor loop statements, being prone to programming errors
- Various other (comparatively minor) issues

I'm quite sure you can do *everything* with POV SDL, as it is basically
touring-complete (if I'm not mistaken) - but so is brainfuck, and I guess even
*you* wouldn't want to program anything more complex than maybe "hello world"
in *that* language...

After all, SDL was designed as a *scene description* language, not as a
*programming* language, and if you have ever *used* (not just toyed around
with) a full-fledged *programming* language you'll notice the difference.

From my experience, I can only say that POV SDL becomes *very* slow *very*
quickly with increasing problem complexity, when comparing it to a full-fledged
programming language.

But then again I'm not an SDL pro, so I may be missing out on some tricks &
quirks of SDL.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> From my experience, I can only say that POV SDL becomes *very* slow *very*
> quickly with increasing problem complexity, when comparing it to a full-fledged
> programming language.
>
> But then again I'm not an SDL pro, so I may be missing out on some tricks &
> quirks of SDL.

I just hate having to learn Yet Another Programming Language just to figure out
how someone did something POV-related. (And that's assuming the source code is
available.)

-Mike

Post a reply to this message