I've got a question about your implemenations of
Hugo Elias' description for water. I'm trying it myself,
so I've got the array x*y and save the heights as
floats, later converting it to positions.

But, when I just raise a single point, I get a stupid
kind of criss-cross effect: One node will stick
out, and the adjacent won't. I know that this is
supposed to happen on the first step of raising
a point, but how do I get rid of this? How did
you achieve that, surely you've run into the same
kind of trouble?

I'll keep experimenting until I hear something from
you guys...

Regards,
Tim

--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

Post a reply to this message

Tim Nikias v2.0 wrote:
> I've got a question about your implemenations of
> Hugo Elias' description for water. I'm trying it myself,
> so I've got the array x*y and save the heights as
> floats, later converting it to positions.
>
> But, when I just raise a single point, I get a stupid
> kind of criss-cross effect: One node will stick
> out, and the adjacent won't. I know that this is
> supposed to happen on the first step of raising
> a point, but how do I get rid of this?

Try to sample more than the four adjacent points. The eight adjacent
points for example (with fitting weights). It's a long time ago, but I
think that did the trick for me. I never solved all problems with the
algorithm though. Never finished the project. Maybe one day.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

"Tim Nikias v2.0" wrote:
> 
> I've got a question about your implemenations of
> Hugo Elias' description for water. I'm trying it myself,
> so I've got the array x*y and save the heights as
> floats, later converting it to positions.
> 
> But, when I just raise a single point, I get a stupid
> kind of criss-cross effect: One node will stick
> out, and the adjacent won't. I know that this is
> supposed to happen on the first step of raising
> a point, but how do I get rid of this? How did
> you achieve that, surely you've run into the same
> kind of trouble?

Like Rune i don't precisely remember how i implemented this but IIRC the
algorithm involves an averaging/smoothing step - this can be varied quite
easily.  

You will also have to experiment with the disturbance of the surface - the
size and form of this much influences the resulting waves.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

That hint about the averaging/smoothing step was
a good one, never really thought about it that way.
In my mind, it was more like a "take the adjacent
sides" in order to "know what height is coming at this
pixel", rather than thinking of it as smoothing.

I'll keep on experimenting. Hopefully I don't have to
rewrite my Mesh-Macros, cause I somehow expected
that connecting four corners with triangles via checking
shortest connection might harm the resulting mesh,
but perhaps the "original" algorithm works better just
for pixel-waves, rather than mesh waves. Its funny though
that I cannot find much about mesh waves on the net,
its just always the pixel-code.

Looks like people are just too possessive about how they
came up with things (there's always that second thing about
people getting it to work, and then just forget what they
did, cause they're just using it, instead of thinking about it).

Regards,
Tim

--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

Post a reply to this message

Hm. Just noticed: this gets pretty darn slow, doesn't
it? I've been experimenting with a 20x20 res. mesh, and
now I'm just doing a 60x60, using photons and smooth-
triangles... Photons are done just like *zap* but tracing and
parsing... wuhee...


--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

Post a reply to this message

On Sat, 15 Mar 2003 19:22:41 +0100, "Tim Nikias v2.0" <tim### [at] gmxde> wrote:

>Hm. Just noticed: this gets pretty darn slow, doesn't
>it? I've been experimenting with a 20x20 res. mesh, and
>now I'm just doing a 60x60, using photons and smooth-
>triangles... Photons are done just like *zap* but tracing and
>parsing... wuhee...
>
>
>--
I noticed the same slow times using SDL I wrote a Basic programme that I called
from Pov which created a tga to be used as a heightfield. It worked ok but I had
problems with the size and memory. I could not use an array larger than 121*121.
I have been trying to redo the programme in C++ but am having problems. (First
C++ attempt and finger trouble.)
Just a thought.


Regards
        Stephen

Post a reply to this message

If I'd had to, I'd script in JAVA, not so much because of its widely
claimed versatility on different OS', but because I'd have to know
JAVA for studying...

Besides that, the only speed-up I'd get would be to calculate the
arrays of heights, cause I'd later want to be able to map the
water-data on meshes made with my MMM...

Also, I can have objects interact with the water. As long as its
just plain raining, it wouldn't matter, but dropping CSG objects
into the pool and getting realistic results (to that certain degree
this algorithm allows) wouldn't be possible very easily without
implementing it as a patch for POV, and I'm not into C++ THAT
much, and not yet that skilled at programming.

--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

>
> >Hm. Just noticed: this gets pretty darn slow, doesn't
> >it? I've been experimenting with a 20x20 res. mesh, and
> >now I'm just doing a 60x60, using photons and smooth-
> >triangles... Photons are done just like *zap* but tracing and
> >parsing... wuhee...
> >
> >
> >--
> I noticed the same slow times using SDL I wrote a Basic programme that I
called
> from Pov which created a tga to be used as a heightfield. It worked ok but
I had
> problems with the size and memory. I could not use an array larger than
121*121.
> I have been trying to redo the programme in C++ but am having problems.
(First
> C++ attempt and finger trouble.)
> Just a thought.
>
>
> Regards
>         Stephen

Post a reply to this message

S McAvoy's furious key-hammering produced this:
> I noticed the same slow times using SDL I wrote a Basic programme that I
> called from Pov which created a tga to be used as a heightfield. It worked ok
> but I had problems with the size and memory. I could not use an array larger
> than 121*121. I have been trying to redo the programme in C++ but am having
> problems.

What flavor of Basic are you using?  If you're using QBasic I can definitely
see where you're running into a problem (64K memory limit for data).  If you
send me the code I can do a quick VB port for you since the code is so similar.
VB doesn't have the strict memory requirements that QB does and can still run
without having a user interface pop up.

Well, on second thought, I can do it if you're using Windows. :) If you're using
Linux or something like that then a C++ port will probably be the way to go.

-- 
/*^*/light_source{100*<-5,2,-5>2}#macro I(i,n)#while(strlen(i)>=n)#local A=asc(
substr(i,n,1));#local a=asc(substr(i,n+1,1));cylinder{<div(A,8)-12,mod(A,8)-4,4
><div(a,8)-12,mod(a,8)-4,4>,0.1pigment{rgb z}}#local n=n+2;#end#end I("ScUe[]"1
/*<*/)I("mkmtlttk"1)//@_$#!,:<"Thhis polysig brought to you by Ian Burgmyer :)"

Post a reply to this message

On 16 Mar 2003 01:39:54 -0500, "Ian J. Burgmyer" <the### [at] maccom> wrote:


>What flavor of Basic are you using?  If you're using QBasic I can definitely
>see where you're running into a problem (64K memory limit for data).  If you
>send me the code I can do a quick VB port for you since the code is so similar.
>VB doesn't have the strict memory requirements that QB does and can still run
>without having a user interface pop up.
>
>Well, on second thought, I can do it if you're using Windows. :) If you're using
>Linux or something like that then a C++ port will probably be the way to go.
>
>-- 
Ian thanks, I am using QB 4.5 and will take up your kind offer. I just need to
find the last working version and clean it up. It may take a day or so to find
the correct version. I hadn't thought of using VB.  
Regards
        Stephen

Post a reply to this message

In article <3e741c3a$1@news.povray.org>, the### [at] maccom says...
> Well, on second thought, I can do it if you're using Windows. :) If you're using
> Linux or something like that then a C++ port will probably be the way to go.
> 

Wish there was at least a VBScript clone under Linux. When the mud client 
I use gets ported over to it I am going to lose my favorite script 
language for coding. Python looked promising (I.e. reasonably non-
cryptic), but the developer or Mushclient couldn't get the engine to link 
in and work right, it kept crashing the client under windows. :P

For that matter, it would be nice if someone designed a Basic language 
that supported the stuff VB does and got it bloody right. lol Some very 
strange quirks in the language and some where actually added that didn't 
"ever" happen in QB. lol

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message