POV-Ray : Newsgroups : povray.binaries.images : Calculating water flow : Re: Calculating water flow Server Time
1 Aug 2024 10:18:15 EDT (-0400)
  Re: Calculating water flow  
From: Kirk Andrews
Date: 11 Dec 2008 17:55:01
Message: <web.49419a2fb440b799b555cae70@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.