"Kirk Andrews" <kir### [at] tektonartcom> wrote:
> To do this *right*, I'm thinking you'd have to do a full-blown physics
> simulation.

Hey Kirk,

I'm not sure if this is helpful or not, but if your computer has a GPU
supporting pixel shaders, check out this one I posted a while back:
https://www.shadertoy.com/view/XsKGWG

It approximates hydraulic erosion on a height map, using a sort of basin-filling
method as a key part of the process. It won't form rivers on flat plains, since
momentum isn't taken into account (would need to probably implement
Navier-Stokes equations for that, which would be difficult using Shadertoy since
a fluid sim needs to iterate over a certain operation some 30-50 times per
frame, to the same texture). Also, the lakes seem to be slightly sloped.

Sam

Post a reply to this message

"Samuel B." <stb### [at] hotmailcom> wrote:
> "Kirk Andrews" <kir### [at] tektonartcom> wrote:
> > To do this *right*, I'm thinking you'd have to do a full-blown physics
> > simulation.
>
> Hey Kirk,
>
> I'm not sure if this is helpful or not, but if your computer has a GPU
> supporting pixel shaders, check out this one I posted a while back:
> https://www.shadertoy.com/view/XsKGWG
>
> It approximates hydraulic erosion on a height map, using a sort of basin-filling
> method as a key part of the process. It won't form rivers on flat plains, since
> momentum isn't taken into account (would need to probably implement
> Navier-Stokes equations for that, which would be difficult using Shadertoy since
> a fluid sim needs to iterate over a certain operation some 30-50 times per
> frame, to the same texture). Also, the lakes seem to be slightly sloped.
>
> Sam

Wow! I'd never heard of Shadertoy. Is it possible to download the resulting
height map?

Post a reply to this message

"Kirk Andrews" <kir### [at] tektonartcom> wrote:
> "Samuel B." <stb### [at] hotmailcom> wrote:
> > "Kirk Andrews" <kir### [at] tektonartcom> wrote:
> > > To do this *right*, I'm thinking you'd have to do a full-blown physics
> > > simulation.
> >
> > Hey Kirk,
> >
> > I'm not sure if this is helpful or not, but if your computer has a GPU
> > supporting pixel shaders, check out this one I posted a while back:
> > https://www.shadertoy.com/view/XsKGWG
> >
> > It approximates hydraulic erosion on a height map, using a sort of basin-filling
> > method as a key part of the process. It won't form rivers on flat plains, since
> > momentum isn't taken into account (would need to probably implement
> > Navier-Stokes equations for that, which would be difficult using Shadertoy since
> > a fluid sim needs to iterate over a certain operation some 30-50 times per
> > frame, to the same texture). Also, the lakes seem to be slightly sloped.
> >
> > Sam
>
> Wow! I'd never heard of Shadertoy. Is it possible to download the resulting
> height map?

It's possible, but will require editing the source code of the Image shader to
have it display only the height map (or water map, or both [hint: the landMap()
and waterMap() functions give this data]). You can then (in Firefox) right click
on the display window and choose Save Image As... Unfortunately this will only
get you an 8 bit image. For 16 bit data, you'll need to convert it over to the
red/green format (which POV-Ray supports) and then save. (For all I know saving
16 bit data from Shadertoy might be possible if you know Java.)

Better yet is to get your own shader program up-and-running using SFML or the
like. (Although the last I heard SFML would only support 8 bit textures, the
devs assuming anything else was unnecessary :P I was able to add 16 bit texture
support myself, but who knows how many versions ago that has been...)

Sam

Post a reply to this message

"Kirk Andrews" <kir### [at] tektonartcom> wrote:
> > To do this *right*, I'm thinking you'd have to do a full-blown physics
> > simulation. But, I'm wondering if we can't get to a reasonable approximation
> > with some extra trace checks. Right now, it's only checking straight down from
> > above, but if we also checked across from the center point, maybe we could
> > eliminate points that didn't have a straight path from here to there. I
> > experimented with that idea some but I can't tell if it's really working yet.
> >
>
> Or, I suppose it could be as simple as what paint programs do with the fill
> tool, and treat it more like square pixels.


really what pulled me into the world of programming, and I'm incredibly thankful
for that. In the years since I left off of POV, I've been doing more and more
coding, mostly in PHP and javascript. So it's a bit of a shock to jump back into
POV and try and code things in SDL, and realize all the things I can't do! It
definitely forces you to get creative. It also makes you think hard about
optimizing your code, since you know any inefficiencies will likely have
significant impacts in parsing time.

Post a reply to this message

On 17-2-2017 14:29, Kirk Andrews wrote:
> That's looking really good, Thomas!

Thanks, yes, especially the second image, which indicates to me that a 
well-behaving substrate does wonders for your little code ;-)

>
> Which software are you using for erosion? Now that I don't have a PC anymore,
> I've got to find something to run on my Mac.
>

I am afraid that most are Windows only.

There is Wilbur http://www.fracterra.com/software.html which does a very 
good job in tracing river patterns but needs a very noisy substrate to 
do it correctly so additional smoothing is necessary (in Wilbur or - as 
I do - in another application);

Terrabrush http://www.cyberfunks.de/page/terrabrush/index.htm is another 
program I use in between but not so good for erosional processes;

GeoControl (which now seems to be WorldCreator I discover) 
http://www.world-creator.com/ is not a free program. It is the heart of 
my height_field creation modules. It does a fair erosion job. I don't 
know about its latest versions though;

World Machine http://www.world-machine.com/ you already know.

I also grabbed a free copy of Bryce 7 when DAZ made it available a few 
years ago. It can generate some interesting height_fields to serve as 
basis for deeper treatment later.

Interestingly, You can make fascinating height_fields with Apophysis 
flames as basis https://sourceforge.net/projects/apophysis/ . Loaded 
into GeoControl for instance, the pattern is transformed into an 
interesting landscape.

-- 
Thomas

Post a reply to this message

On 17-2-2017 14:54, Kirk Andrews wrote:
> To do this *right*, I'm thinking you'd have to do a full-blown physics
> simulation. But, I'm wondering if we can't get to a reasonable approximation
> with some extra trace checks. Right now, it's only checking straight down from
> above, but if we also checked across from the center point, maybe we could
> eliminate points that didn't have a straight path from here to there. I
> experimented with that idea some but I can't tell if it's really working yet.
>
> https://www.dropbox.com/s/49nmnd5z1kzhms0/Water4.pov?dl=0
>

This version does interesting things, different from the previous one. I 
am not entirely sure if it solves the problem and I need to investigate 
further.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'ka_water4.jpg' (210 KB)

Preview of image 'ka_water4.jpg'

On 22-2-2017 13:17, Thomas de Groot wrote:
> This version does interesting things, different from the previous one. I
> am not entirely sure if it solves the problem and I need to investigate
> further.
>

I think it is worthwhile to re-think the random starting point code as 
the existing one has not a coverage including the complete terrain.

I use RRand() from rand.inc (to be included into the scene) in the 
following manner:

First, add the following lines after the height_field making:

#declare Min = min_extent(Terrain);
#declare Max = max_extent(Terrain);

Then replace the line:

   #declare Pos = trace(ThisTerrain, <rand(r)-.55, 10*Flattening, 
rand(r)-.55>*0.9*TS, -y);

by:

   #declare Pos = trace(ThisTerrain, <RRand(Min.x, Max.x, r), 
10*Flattening, RRand(Min.z, Max.z, r)>, -y);

The result is shown in the attached image, searching for 100 streams I 
commented out the black cones).

-- 
Thomas

Post a reply to this message

Attachments:
Download 'ka_water4.jpg' (186 KB)

Preview of image 'ka_water4.jpg'

Thomas de Groot <tho### [at] degrootorg> wrote:

> I use RRand() from rand.inc (to be included into the scene) in the
> following manner:

Can you also use VRand_In_Obj ?

What ..... stream are you using?   :D

Post a reply to this message

On 22-2-2017 14:01, Bald Eagle wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>> I use RRand() from rand.inc (to be included into the scene) in the
>> following manner:
>
> Can you also use VRand_In_Obj ?

Yes, of course. It is a matter of taste imho.

Another interesting option would be to use a pigment_pattern, or an 
image_pattern of a flow map, and only allow for streams to start from 
the higher grounds. Hmm... going to have to implement that...

>
> What ..... stream are you using?   :D
>

:-) ?

-- 
Thomas

Post a reply to this message

Overall, I think that version 4 is doing a good job and solves the 
problem of version 3. The attached image demonstrates that. Never mind 
the columns for supporting the sky ;-) Those are little troubles at the 
height_field's edges.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'ka_water4.jpg' (180 KB)

Preview of image 'ka_water4.jpg'