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

So you're basically saying, "please keep your solutions POV SDL becasue I want
to be able to understand and learn from them as well"?

That's a whole different statement than "there's nothing wrong with SDL", and
has more potential to get you what you actually want.

Post a reply to this message

"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

"Kirk Andrews" <kir### [at] tektonartcom> wrote:
> 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).

I would be interested to see how POV SDL fares on a benchmark test, such as the
following:

http://shootout.alioth.debian.org/

As for your particular case, I suspect that the bulk of the speed difference
stems from the fact that image software programmers have had years to finetune
and optimize how filters are handled and applied. Arrays are probably the slow
way to do it.

-Mike

Post a reply to this message

Some success, I think.

This is a return to my original method.  I rendered a 16 bit tga from the
original function, then made a render another 16 bit tga from a render where
the terrain was flat white and my water cones were black.

In a separate file, I subtract the second function from the first to create this
hf, here with a resolution of 2000x2000.  I achieved better results when I
blurred the water function a little.

It doesn't do any global erosion, but I think it does a nice job of making
gullies and rivers.  I could place a second hf without the erosion just
slightly below the first to fill in the rivulets with some kind of water
texture.

Post a reply to this message

Attachments:
Download 'together_a.jpg' (262 KB)

Preview of image 'together_a.jpg'

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

It really shouldn't be taking that long. What language are you 
programming with? Do you compile your code? How are you storing/testing 
the map entries?

There are two things I can think of which may be slowing your code down.

The first that you might be testing pixels instead of having a large 
array (int map[2000][2000];) of values. Obtaining values from arrays 
will always be faster than testing pixels.

Another reason for the slowdown is that you have a function like this:

void RenderGraphics(int bLogicUpdate)
{
  test_value(..);
  draw_pixel(..);
}

Some SDL setups have a function like this to place the drawing functions 
into. I have seen a *huge* speedup by doing this instead:

void RenderGraphics(int bLogicUpdate)
{
  for(int v=0;v<20000;v++)
  {
   test_value(..);
   draw_pixel(..);
  }
}

That way the program isn't flipping the video page every time you draw a 
pixel to it. I hope this helps.

By the way, it looks like your (POV) SDL version is coming along nicely :)

Sam

Post a reply to this message

Looks great!

"Kirk Andrews" <kir### [at] tektonartcom> wrote:
> In a separate file, I subtract the second function from the first to create this
> hf, here with a resolution of 2000x2000.

A separate POV file?

> It doesn't do any global erosion, but I think it does a nice job of making
> gullies and rivers.

What do you mean by "global erosion"?

-Mike

Post a reply to this message

That's really interesting Kirk, and it's amazing you had the patience to 
try that in POV :-)

One of my first project in C++ has been doing something like that. It's 
been ages since I've played with it and I don't remember all the 
details... But I remember I had the lake problem and solved it by 
filling them allup to the point where they overflow.

I looked into papers about erosion and in the end I was able to simulate 
global erosion as well. You can see the result in this animation done 
with POV-Ray:
http://mink.chewa.net/Erosion.mpg

(I should do it again and adjust the frame rate, it's too quick :-\ )

I also used the same program to get more "realistic" images in Terragen 
(first image) and a played a bit with it in POV-Ray as well (second 
image). I wanted to procedurally add detail in POV-Ray as a function of 
image maps  generated by my program, but unfortunately it was too slow 
to be really usable.

I'd have to dig in the old code again to give more specific help. 
Unfortunately since it was my first project it's not really easy to read...

Good luck !

-- 
Vincent

Post a reply to this message

Attachments:
Download 'ridges2.jpg' (160 KB) Download 'ridges86.jpeg.jpg' (103 KB)

Preview of image 'ridges2.jpg'

Preview of image 'ridges86.jpeg.jpg'

stbenge wrote:
> It really shouldn't be taking that long. What language are you
> programming with? Do you compile your code? How are you storing/testing
> the map entries?

He's using SDL :)

Post a reply to this message

Nicolas Alvarez wrote:
> stbenge wrote:
>> It really shouldn't be taking that long. What language are you
>> programming with? Do you compile your code? How are you storing/testing
>> the map entries?
> 
> He's using SDL :)

Oops, with all this talk about C++ and *other* languages, I got the two 
types of SDL mixed :|

Post a reply to this message

Kirk Andrews nous illumina en ce 2008-12-12 21:12 -->
> Some success, I think.
> 
> This is a return to my original method.  I rendered a 16 bit tga from the
> original function, then made a render another 16 bit tga from a render where
> the terrain was flat white and my water cones were black.
> 
> In a separate file, I subtract the second function from the first to create this
> hf, here with a resolution of 2000x2000.  I achieved better results when I
> blurred the water function a little.
> 
> It doesn't do any global erosion, but I think it does a nice job of making
> gullies and rivers.  I could place a second hf without the erosion just
> slightly below the first to fill in the rivulets with some kind of water
> texture.
> 
> 
> ------------------------------------------------------------------------
> 
Good, but with a problem: the streams are jutting up from the surrounding terrain...
So, maybe that instead of substracting, you should add, or substract a black 
terrain with white or gray water.
You should also concidere that streams on steep slopes tend to be narrow, and 
getting broader on gentle slopes.

When you get a pond or lake, try increasing the level until you get to a point 
where the edge hit a lower point, and start a new stream there. That's the way 
lakes form. Water flow from high to low altitude. When it reatch the bottom of a 
"bowl", it acumulate, the level rises, and, eventualy reatch a low area on it's 
perimeter from where it can continue down.

-- 
Alain
-------------------------------------------------
It is the passion that is in a kiss that gives to it its sweetness; it is the 
affection in a kiss that sanctifies it.
~Christian Nevell Bovee

Post a reply to this message