This is already done a hundred times, but still I'm a bit proud that I've
managed to figure out how to do it and that it worked out this well. I've done a
sea surface with heightfields before but this is my first serious use of
isosurfaces. Tada! I never thought I would get them to work and I still don't
understand a lot of things that are supposedly possible with isosurfaces (for
instance: craters?) but at least now I know where to start.
Assuming that this is part of a scene with a gently rippling sea, any comments?
Oh and it's supposed to loop. It looked perfect when I previewed it (with
bumper) but the mediaplayer gives a flicker at the end, distorting the loop. I
don't know how to fix that.

Cheers,

Remco

Post a reply to this message

Attachments:
Download 'wripple.mpg' (124 KB)

Looped perfectly in Windows Media Player 7 for me here.
Very effective water surface.  Too bad the whitecaps are only specular
reflection.  At least I *think* that is from the light.

Bob H.

Post a reply to this message

Looks very realistic to me! :)

And it loops fine here after a few loops.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org

Post a reply to this message

nice and realistic - well done (almost as impressed that it loops as wel!!)


--
Rick

POV-Ray News & Resources - http://povray.co.uk
Kitty5 WebDesign - http://kitty5.com
Hi-Impact web site design & database driven e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

Very nice! There is sometimes (not at every loop) a little flicker while
looping in the ActiveMovie-Player, but that is probably M$'s fault.
Could you post the source, please?

BTW: There is a tutorial of making earth-like moons (ehm, or moon-like moons
... well, you know what I mean) at www.xenoarch.com and he adds craters as
well. Perhaps it's of help for you.

Marc-Hendrik

Post a reply to this message

Marc-Hendrik Bremer wrote:
> 
> Very nice! There is sometimes (not at every loop) a little flicker while
> looping in the ActiveMovie-Player, but that is probably M$'s fault.
> Could you post the source, please?
> 
> BTW: There is a tutorial of making earth-like moons (ehm, or moon-like moons
> ... well, you know what I mean) at www.xenoarch.com and he adds craters as
> well. Perhaps it's of help for you.
> 
> Marc-Hendrik

Thank you. I know about the loop-problem but was hoping there was a way to avoid
it when encoding the aniamtion.

The source is small enough to post here I guess:

#$rr=seed(77);

$t1=4+rand(rr)*8+rand(rr)*clock;
$t2=4+rand(rr)*8+rand(rr)*clock;
$r1=4+4*sin(clock*pi/36);
$r2=4+4*cos(clock*pi/36);

$vv=4+sin(clock*pi/36)*cos(clock*pi/36);

$pw=4;
$ph=3;
$f1=1+sin(t1*pi*r1/16);
$f2=1+cos(t2*pi*r2/12);


isosurface{
  function{
    (y*(
      1+sin(vv*(x+z)*pi/pw*sin(x*f1*pi/ph))/2
      +
      1+cos(vv*z*pi/ph*cos(z*f2*pi/pw))/2
    ))
   } 
  threshold 1 sign 1
  bounded_by{ box{<-12,-12,-8><12,12,12>} }
  pigment{rgb 2} finish{phong .7 phong_size 120  
  brilliance 4
  }
}

I got the funny stuff with all the variables and sin/cos from a screensaver I
was working on. It's far easier to test this out in a simple program then as it
is with an isosurface in povray.
I doN0t know much about the isosurface-settings as I'm just beginning on that.

Thank you for the link to the tutorial, I'll go check it out right away.

Cheers!

Remco
http://www.xs4all.nl/~remcodek/screensaver.html

Post a reply to this message

Remco de Korte schrieb in Nachricht <3A798CFB.7C1649A3@xs4all.nl>...

Thank you for the code. I was thinking, that this were some combined
pigment-functions, but I bet your solution is way easier to control.

>I doN0t know much about the isosurface-settings as I'm just beginning on
that.

One optimisation could be to reduce your containing box. If I see it
correct, it is way to big in the y-direction, since 1+sin(x)/2 and
1+cos(y)/2
can each not be more than 1.5. Both can't be less than 0.5. So you can
reduce your container box to y*1 and y*4, perhaps even more, but I'm not
that familiar with a threshold of 1. That will save you some rendertime.

Marc-Hendrik

Post a reply to this message

Marc-Hendrik Bremer wrote:
> 
> 
> One optimisation could be to reduce your containing box. If I see it
> correct, it is way to big in the y-direction, since 1+sin(x)/2 and
> 1+cos(y)/2
> can each not be more than 1.5. Both can't be less than 0.5. So you can
> reduce your container box to y*1 and y*4, perhaps even more, but I'm not
> that familiar with a threshold of 1. That will save you some rendertime.
> 
> Marc-Hendrik

Thanks for the hint. I didn't think it would matter much but I expect if you
think about it would. I was already worried about the speed. Then I tried to do
the same with a tiled mesh and rendering was much much faster but it took ages
to parse (and the result was less subtle).

Remco
http://www.xs4all.nl/~remcodek/

Post a reply to this message

Remco de Korte schrieb in Nachricht <3A79D232.8C7C423C@xs4all.nl>...

>Thanks for the hint. I didn't think it would matter much but I expect if
you
>think about it would.

Well if I understand it right, the function must be calculated for every ray
hitting the container object. Okay, there may be (no, there are) some cache
strategies, but if you make a picture which is only partly occupied by a
isosurface you can see that rendering slows down, when it comes to the
container. Since you don't need the empty parts of the container, it's only
wasted time.

> I was already worried about the speed.

I did not try it myself but maybe it would help to precompute some more
constant terms in your final function. If you precompute things like w*pi/ph
or add  #declare f1 = f1*pi/ph, less has to be computed at rendertime. I
might be wrong with this but I don't think that POV really recognizes those
constant terms in the function (but I would be glad if someone would tell me
that I'm wrong).
As far as I can see, the '1+' for the sin and cos part is not nessecary too,
because it only levitates the Iso a bit. It would be intresting to test if a
translated Iso with a simpler function is faster than a more difficult one,
which is at the right place allready. I bet it is.

OTOH all this will not make that much difference IMHO, and there were some
rumours that Isos will be 10 times faster in the next official version.
Hopefully who ever is working on that is succesfull!

BTW: What are the rendertimes for this? How long took one frame?

Marc-Hendrik

Post a reply to this message

Marc-Hendrik Bremer wrote:
> 
> Remco de Korte schrieb in Nachricht <3A79D232.8C7C423C@xs4all.nl>...
> 
> >Thanks for the hint. I didn't think it would matter much but I expect if
> you
> >think about it would.
> 
> Well if I understand it right, the function must be calculated for every ray
> hitting the container object. Okay, there may be (no, there are) some cache
> strategies, but if you make a picture which is only partly occupied by a
> isosurface you can see that rendering slows down, when it comes to the
> container. Since you don't need the empty parts of the container, it's only
> wasted time.
> 
> > I was already worried about the speed.
> 
> I did not try it myself but maybe it would help to precompute some more
> constant terms in your final function. If you precompute things like w*pi/ph
> or add  #declare f1 = f1*pi/ph, less has to be computed at rendertime. I
> might be wrong with this but I don't think that POV really recognizes those
> constant terms in the function (but I would be glad if someone would tell me
> that I'm wrong).
> As far as I can see, the '1+' for the sin and cos part is not nessecary too,
> because it only levitates the Iso a bit. It would be intresting to test if a
> translated Iso with a simpler function is faster than a more difficult one,
> which is at the right place allready. I bet it is.
> 
> OTOH all this will not make that much difference IMHO, and there were some
> rumours that Isos will be 10 times faster in the next official version.
> Hopefully who ever is working on that is succesfull!
> 
> BTW: What are the rendertimes for this? How long took one frame?
> 
> Marc-Hendrik

Thanks again for the hints. I have tried some optimizing but with tweaking the
function things got messed up a bit and I didn't bother any more. I don't know
the eaxct render time because whenever I have such scenes that take longer then
a minute to render I start doing other things on the same system or go to bed to
see the results in the morning. In this case it was a combination, but I
remember something like half an hour per frame (320x240). That is, on a P233,
with lots of other stuff going on and render priority set at lower. Not very
useful information...
I may use this in a larger scene (animated) so I'm sure I'll optimize it a bit
in that case, but I'm also considering using heightfields.

Remco

Post a reply to this message