POV: Tracing realixtic water...
Paul Holmes
Have a seen that I'm working on that needs a working model
of water with realistic looking ripples that will eventually
be used as part of an animation. Using a height feild (for
the most part) as the land mass how do I create a realistic
looking lake/river?
Thanks for any help you could suggest...
Paul
Norman Doering
Paul Holmes <hpa...@qwest.net> wrote:
> Hi all..
> Have a seen that I'm working on that needs a working model
This might help -- it's from a POV example:
// an ocean surface
plane
{ y, -10.0 // adjust the -10.0 till it hits your height
hollow on // field where you want it.
pigment { Aquamarine } // Blue, or rgb 0.01, 0.3, 0.8, or rgbt
// with a t to add transparency.
normal
{ waves 0.06 // This will give you your ripples
frequency 5000.0 // play with the values till it's
// right for your picture. --
scale 1000.0 // You may have to switch to bump maps
} // to animate it right... but try changing
finish // the values here slightly with each frame.
{ ambient 0.1
diffuse 0.1
reflection 0.8 // this is a good reflection value for water.
}
}
> ....that will eventually be used as part of an animation. Using
> a height feild (for the most part) as the land mass how do I create
> a realistic looking lake/river?
> Thanks for any help you could suggest...
> Paul
I'm not sure about animation stuff, I'm doing still work for now.
---
Norman Doering
http://normdoering.homepage.com
Sent via Deja.com
http://www.deja.com/
Paul Holmes
what happens...
Warp
: pigment { Aquamarine }
Realistic water? Water has no color and it's completely transparent
(unless it's explicitly colored with some substance).
Water also has an ior.
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Chris Huff
> Have a seen that I'm working on that needs a working model
> of water with realistic looking ripples that will eventually
> be used as part of an animation. Using a height feild (for
> the most part) as the land mass how do I create a realistic
> looking lake/river?
http://www.lehigh.edu/~mbp2/wyzpov/water.html
The tutorial is written for WyzPOV, but the relevant patch has been
added to MegaPOV and will be in POV 3.5 in some form. If you only have
the official version, you might want to check out MegaPOV:
http://nathan.kopp.com/patched.htm
--
Christopher James Huff
Personal: chri...@mac.com, http://homepage.mac.com/chrishuff/
TAG: chris...@tag.povray.org, http://tag.povray.org/
<><
Norman Doering
Warp <wa...@cs.tut.fi> wrote:
> Norman Doering <normd...@my-deja.com> wrote:
> : pigment { Aquamarine }
>
> Realistic water? Water has no color and it's completely transparent
> (unless it's explicitly colored with some substance).
> Water also has an ior.
What works in POV and what's actually the case are two different
things. It depends on the environment. Most panaramic views of bodies
of water don't show transparency... in a glass it's different.
But hey, if you can do better, show us the code.
Norman Doering
> : pigment { Aquamarine }
>
> Realistic water? Water has no color and it's completely transparent
> (unless it's explicitly colored with some substance).
> Water also has an ior.
What works with POV and what actually is the physics of water are two
different things. When looking at a lake or large body of water the
transparency doesn't show, adding it will make it unrealistic, but you
can add slight amounts as you get closer to the water's surface. Now,
water in a glass is a completely different story than a large body, like
a lake -- which is what was asked for.
But, if you've got POV code that looks good for a lake, let's see it.
Michael Brown
news:3A7BA1DB...@qwest.net...
Finite element analysis! Mwaahaaahaaahaaahaaaaaaaa!
Sorry. I'm under control now. Really :)
Michael
--
Code snippit 1 : Fibbonachi fill
Stats:
In : esi = destination address, ecx = number of numbers / 2
Out : esi,eax,ebx,ecx destroyed. [esi] = 1,2,3,5,8...
Time: 2.5 clocks per Fibbonachi number + 1 clock initialisation
Code (replace ";" with newline):
mov eax,1;mov ebx,1;L1:mov [esi],eax;add ebx,eax;add esi,4;
mov [esi],ebx;add eax,ebx;add esi,4;dec ecx;jnz L1
Alexander Wilkie
> What works with POV and what actually is the physics of water are two
> different things. When looking at a lake or large body of water the
> transparency doesn't show, adding it will make it unrealistic
Well, if one were in the mood for nitpicking one could add that having
transparency would not impair the realism of a lake if realistic reflection
models were used. Lakes are generally viewed at very shallow angles, where
the refectivity of the water is very high (the Fresnel terms for
reflectivity are the formula for this), so you really don't get to see the
transparency of the water except on the facing sides of waves or ripples.
(can POV use the Fresnel terms for reflectivity?)
Of course, in super-nitpick mode one could add that under a clear sky the
apperance of outdoor water bodies is also quite strongly influenced by
something else: skylight polarization. If the angle between your viewing
direction and those parts of the blue sky which emit strongly polarized
light (90 degrees from the sun, usually) is favourable, you can get a quite
drastic reduction or increase of the surface reflectivity. Of course, this
is one of those effects which you only consciously notice once you know
it's there, but on good days it can be quite strong.
Just my $0.2E-32
Alexander
Norman Doering
Alexander Wilkie <wil...@cg.tuwien.ac.at> wrote:
> Norman Doering wrote:
> > What works with POV and what actually is the physics of water are
> > two different things. When looking at a lake or large body of water
> > the transparency doesn't show, adding it will make it unrealistic
>
> Well, if one were in the mood for nitpicking one could add that
> having transparency would not impair the realism of a lake if
> realistic reflection models were used.
Therein lies the problem.
MegaPov I think has better models.
> Lakes are generally viewed at very shallow angles, where
> the refectivity of the water is very high (the Fresnel terms for
> reflectivity are the formula for this), so you really don't get to
> see the transparency of the water except on the facing sides of
> waves or ripples. (can POV use the Fresnel terms for reflectivity?)
MegaPov might -- but I don't think POV can.
If it can, I don't know how.
Also, the more you try to get all the physics working, the longer it
might take to trace when you could have gotten the almost identical or
better image by "cheating" the physics and just giving the water an
opaque color with an almost mirror like surface.
> Of course, in super-nitpick mode one could add that under a clear
> sky the apperance of outdoor water bodies is also quite strongly
> influenced by something else: skylight polarization.
And that's not something I think either POV or MegaPov will model.
Can one do any polarized light tricks with any ray tracer without
faking it?
> If the angle between your viewing direction and those parts of the
> blue sky which emit strongly polarized light (90 degrees from the
> sun, usually) is favourable, you can get a quite drastic reduction
> or increase of the surface reflectivity. Of course, this
> is one of those effects which you only consciously notice once you
> know it's there...
And even if you do notice, you won't know why unless you're a physicist.
>... but on good days it can be quite strong.
>
> Just my $0.2E-32
Well, the physics of it will tell you why a lake looks the way it does,
but don't try to model all that physics with any ray tracer I know of...
Not yet... Wait till we have teraHertz computers.
Alexander Wilkie
> And that's not something I think either POV or MegaPov will model.
> Can one do any polarized light tricks with any ray tracer without
> faking it?
Well, I probably wouldn't have known about the stuff I wrote in my previous
posting if I hadn't recently extended our raytracer
(http://www.artoolkit.org/) to do just that kind of thing. As far as
published CG literature goes, there have been two previous renderers that
were capable of doing this (Wolff and Kurlander in 1990, and Tannenbaum &
Co in 1994), but neither of them was ever made publicly available, or were
developed any further, so that one could have had a look at the code. Nor
were the authors vocal enough about warning other hackers about what kind
of subtle problems you run into if you try to extend a normal rendering
system to accomodate something like this.
Apart from the easily underestimated complexity, there is one other reason
no--one else has bothered so far: we put several months work into making
ART "polarizable", only to find out that -- apart from the kind of outdoor
scenes I mentioned in my previous post -- including polarization state in
you raytracer usually alters the resulting images in no instantly obvious
way. Of course glass objects look slightly different, and multiple
interreflections, especially of metal objects in dieelectric mirrors,
exhibit colour shifts. But none of these phenomena is something that one
would instantly notice as "missing" from an image.
> Well, the physics of it will tell you why a lake looks the way it does,
> but don't try to model all that physics with any ray tracer I know of...
> Not yet... Wait till we have teraHertz computers.
I tend to disagree with you there. You don't have to wait for THz machines
to arrive before you can do physically correct raytracing - that's a
popular misconception. The main problem with this kind of approach lies
elsewhere, not in the CPU cycles it would consume.
For example, the polarizing spectral raytracer we wrote (which is about as
physical as you can get, except for diffraction effects) is 50%-200% slower
than its "plain" spectral counterpart. That's quite a lot, but in the big
scheme of things it's not earth-shattering, and it certainly does not
relegate raytracing to THz boxes.
The _real_ problem is that for a physically correct raytracer you need
pretty accurate measurements of the physical properties of the involved
objects, and these are in general beastly hard to come by. Finding the
dispersion curve for water turns out to be bad enough (you get that kind of
thing from chemical handbooks), but if you want spectral measurements of
particular surface reflectivities you are usually pretty much out of luck.
Guessing reflection spectra the way you can guess RGB or HSV values does
not really work, since the relationship between percieved colour and its
associated spectral curve is a) ambigous and b) sometimes quite nonobvious.
You can of course shell out $5K for a Spectrolino (a popular make of
low-cost (!) spectrophotometer), but not even that kind of device will tell
you the whole story about a surface. If you -- for example -- want to do
fluorescence effects, you need measurements from a bispectral photometer (a
device that is extremely rare and expensive), or if you want to represent
arbitrary BRDFs, you need BRDF measurements (which are hard to take, huge
datasets, and are hard to use). And so on.
The nasty bit is that once a part of your renderer operates in a physically
correct way, the rest more or less has to follw suit. There is little point
in e.g. mixing spectral reflectances with RGB values (actually this is also
quite tricky, since RGB values do not have an inherent spectrum associated
with them), or using fake water shaders along polarizable fresnel
reflection calculations.
No, the physics are not really the problem. How to properly handle physics
in a renderer is a problem which is pretty well understood, tedious as some
aspects of it might be. Nor is performance the main issue.
_Using_ such a renderer in a practical way is a different matter
altogether, and this will be a problem for quite some time to come yet.
So, to properly sum this thread up, the merciful thing to tell the original
poster is probably "by all means, use that aquamarine pigment for water the
first reply talked about, and think no further!" ;-)
$0.2E-32
Alexander Wilkie
--
http://www.cg.tuwien.ac.at/staff/AlexanderWilkie.html
http://www.cg.tuwien.ac.at/staff/AlexanderWilkiePGPKey.asc
Warp
: What works with POV and what actually is the physics of water are two
: different things. When looking at a lake or large body of water the
: transparency doesn't show
Yes it does.
What happens with a lake is that the light fades with the distance inside
the water until it becomes practically nonexistent. This is why you can
see the bottom of the lake in shallow water but as the bottom gets deeper
it becomes less and less visible until it's completely black (and you only
see the reflection).
If you don't see the bottom of the lake even at the beach, that's
unrealistic.
Fortunately you can also apply a light fading in the water (in standard
povray), which sould give a more realistic result.
Norman Doering
Warp <wa...@cs.tut.fi> wrote:
/snip/
> Fortunately you can also apply a light fading in the water (in
> standard povray), which sould give a more realistic result.
Sounds good. I'll have to look up that "light fading" trick.
Have you got any POV code to illustrate how it's done?
Chris Huff
(csbh<REMOVE>@(TH+ESE)datahit.com) (Coridon Henshaw) wrote:
> In my experience media is overkill unless the water is shallow and seen
> from a low angle.
Absorbing media isn't that slow, but there are faster and easier to use
methods available (object attenuation).
> Conventional (and much faster) techniques work just as well for
> medium-distance and background elements. This is what I came up
> with:
Unfortunately, since you used a colored pigment, your water will always
have a certain amount of color and attenuation, even for just a thin
film or very shallow puddle...since you are using MegaPOV and
fade_distance, you might as well use fade_color to get the attenuation
color.
Norman Doering
Warp <wa...@cs.tut.fi> wrote:
Thanks again for the code.
I checked it out and you made your point about water.
However did tweak it up for you to make it more photorealistic, but
I don't think either of us have quite that part of the scene yet.
Maybe we should start a challenge thread where people post POV and
MegaPov code to meet various hard challenges?
Here's my tweakz:
-------------
// Original scene by warp, tweaked by normdoering
//
// Anyone else with MegaPov want to tweak this scene further?
// Here's the challenge: Make it as photorealistic as possible without
// using image files, (like .gif, .tgs, .png etc...) or complex mesh
// models. The picture has to made from a single file you post on
// usenet and plug into MegaPov.
#version unofficial MegaPov 0.6;
camera { location <0,.5,-7.8> look_at -y angle 40 }
light_source { <3000, 4500, -20>, 1 }
// I moved the light source from { <1000, 3000, -200>, 1 }
// for a more dramatic effect. Use of area light might help
global_settings { assumed_gamma 2.1 }
// I think this helps get darker shadows on the rock/isosurface
fog
{ distance 85
color rgbft< 0.43, 0.45, 0.87, 0.27 0.72>
}
// an atmospheric hazing, slight.
// Sky:
sky_sphere
{ pigment
{ gradient y color_map
{ [0 rgb <.9,1,1>][.2 rgb <.5,.8,1>][1 rgb z]
}
}
}
plane
{ -y,-1000 no_shadow
pigment
{ bozo color_map
{ [0 rgb 1][.25 rgb 1][.5 rgbt 1][1 rgbt 1]
}
turbulence .5
scale 1000
}
finish { ambient .9 }
}
// Landscape:
isosurface
{ function { y-(noise3d(x,y,z)+noise3d(x*12,y*14,z*16)*.04) }
// How do you understand what kind of shape will be made by such
a function?
// Can an isosurface be used to make ripples and waves on the
water, thus
// getting rid of the false un3D edges caused by normals?
contained_by { box { <-2,0,-10><2,1,4> } }
accuracy .0005
pigment { rgb <.43,.37,.34> }
normal { agate scale .25 } // dents replaced by agate
finish
{ crand .75 // I've added a water weathered, rock-like texture to the
isosurface
diffuse .6
specular .35
roughness .83
}
}
// Water:
plane
{ y,.4 clipped_by { box { <-2,.4,-10><2,.4,4> } } bounded_by {
clipped_by }
pigment
{ color rgbft < 0.71, 0.78, 0.81, .24, .76 >
// you used only a filter value for transparency, I made it more
transmissive
}
finish { reflection .65 specular .8 }
// I made the water slightly more reflective - and still you see
more of
// what's beneath because of the lowered filter value
normal { granite .1 scale .5 }
normal
{ ripples 0.64
turbulence 0.82
scale 0.25
translate <0.3, 0.0, -7.1> // I've added turbulent ripples, though
it needs work
}
interior
{ fade_distance .05
fade_power 2
ior 1.33
}
}
// A couple of sticks:
cylinder
{ <-.1,.5,-7.2><.3,-1,-7.2>,.005
pigment { rgb <.97,.67,.43> }
finish
{ specular .35
roughness .28
}
}
cylinder
{ <.3,.5,-6.5><.1,-1,-6.5>,.005
pigment { rgb <.97,.67,.43> }
finish
{ specular .35
roughness .28
}
}
// specular and roughness make the sticks catch light better
-------------
Here's the original code:
> Here is an example scene that uses water.
> It uses megapov only to create the landscape, but nothing else:
>
> #version unofficial MegaPov 0.6;
>
> camera { location <0,.5,-7.8> look_at -y angle 40 }
> light_source { <1000,3000,-200>, 1 }
>
> // Sky:
> sky_sphere
> { pigment
> { gradient y color_map
> { [0 rgb <.9,1,1>][.2 rgb <.5,.8,1>][1 rgb z]
> }
> }
> }
> plane
> { -y,-1000 no_shadow
> pigment
> { bozo color_map
> { [0 rgb 1][.25 rgb 1][.5 rgbt 1][1 rgbt 1]
> }
> turbulence .5
> scale 1000
> }
> finish { ambient .9 }
> }
>
> // Landscape:
> isosurface
> { function { y-(noise3d(x,y,z)+noise3d(x*10,y*10,z*10)*.04) }
> contained_by { box { <-2,0,-10><2,1,4> } }
> accuracy .0001
> pigment { rgb <.8,.5,.25> } finish { specular .1 crand .05 }
> }
>
> // Water:
> plane
> { y,.4 clipped_by { box { <-2,.4,-10><2,.4,4> } } bounded_by {
clipped_by }
> pigment { rgbf <1,1,1,.99> }
> finish { reflection .5 specular .8 }
> normal { granite .1 scale .5 }
> interior
> { fade_distance .05
> fade_power 2
> ior 1.33
> }
> }
>
> // A couple of sticks:
> cylinder
> { <-.1,.5,-7.2><.3,-1,-7.2>,.005
> pigment { rgb <.9,.6,.3> }
> }
> cylinder
> { <.3,.5,-6.5><.1,-1,-6.5>,.005
> pigment { rgb <.9,.6,.3> }
> }
>
> --
> char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
> main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
> c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
---
Norman Doering
Alexander Wilkie <wil...@cg.tuwien.ac.at> wrote:
> Norman Doering wrote:
> > And that's not something I think either POV or MegaPov will model.
> > Can one do any polarized light tricks with any ray tracer without
> > faking it?
>
> Well, I probably wouldn't have known about the stuff I wrote in my
> previous posting if I hadn't recently extended our raytracer
> (http://www.artoolkit.org/) to do just that kind of thing.
I just checked out your page, briefly... so you're working on
a new ray tracing engine -- great.
> As far as published CG literature goes, there have been two previous
> renderers that were capable of doing this (Wolff and Kurlander in
> 1990, and Tannenbaum & Co in 1994), but neither of them was ever made
> publicly available, or were developed any further, so that one could
> have had a look at the code. Nor were the authors vocal enough about
> warning other hackers about what kind of subtle problems you run into
> if you try to extend a normal rendering system to accomodate
> something like this.
Is POV a "normal" rendering system?
What kind of abnormal rendering systems are there? Anything public
domain?
> Apart from the easily underestimated complexity, there is one other
> reason no--one else has bothered so far: we put several months work
> into making ART "polarizable", only to find out that -- apart from
> the kind of outdoor scenes I mentioned in my previous post --
> including polarization state in you raytracer usually alters the
> resulting images in no instantly obvious way.
There are ways to call attention to subtle things, but I imagine that
there's not a lot of call for polarized light tricks in ray tracers...
Unless you're a company that makes polarized filters for cameras and
want fancy illustrations of what the filters do before they're made.
> Of course glass objects look slightly different, and multiple
> interreflections, especially of metal objects in dieelectric mirrors,
> exhibit colour shifts. But none of these phenomena is something that
> one would instantly notice as "missing" from an image.
You would have to call people's attention to it. You'd be amazed at
some of the things artists have tried to paint, subtle details no one
notices for years.
> > Well, the physics of it will tell you why a lake looks the way it
> > does, but don't try to model all that physics with any ray tracer I
> > know of... Not yet... Wait till we have teraHertz computers.
>
> I tend to disagree with you there.
Well, it is a bit of an exaggeration I suppose -- but I lose my
patience on a pentium trying normal ray tracing.
> You don't have to wait for THz machines ...
Just for POV to finish, by which time we might have THz machines.
> ...to arrive before you can do physically correct raytracing -
> that's a popular misconception. The main problem with this kind of
> approach lies elsewhere, not in the CPU cycles it would consume.
>
> For example, the polarizing spectral raytracer we wrote (which is
> about as physical as you can get, except for diffraction effects) is
> 50%-200% slower than its "plain" spectral counterpart. That's quite a
> lot,...
Yes, but polarizing spectral raytracing isn't the final word in
realism either, it's just one of many, many elements that get
simplified out of modern raytracing. What about atmospheric
distortions -- like heat waves, mirages, etc.? You have to fake
those with warped transparent sheets, there are no temperature
variables in any ray tracer I know of.
>... but in the big scheme of things it's not earth-shattering, and it
> certainly does not relegate raytracing to THz boxes.
True, but think of what raytracing will be like when we have THz
machines? People will start to get more discriminating because they
can afford to be.
> The _real_ problem is that for a physically correct raytracer you
> need pretty accurate measurements of the physical properties of the
> involved objects, and these are in general beastly hard to come by.
Now that's a good point!
You're right. I don't use physics in such a pure form. I rely on my
eye to tell me what looks "right." A little physics here and there
helps when you can't figure out why something doesn't look right, but
the details that a scientist measures these days are not necessary
for an artist... Unless one is doing scientific illustration - that's
a market I might try for.
> Finding the dispersion curve for water turns out to be bad enough
> (you get that kind of thing from chemical handbooks), but if you want
> spectral measurements of particular surface reflectivities you are
> usually pretty much out of luck.
Who would have a use for such information?
Does pollution change it -- environmentalists might have data?
Water surfaces are all different too. Different lakes will have
different microbes on the surface.
> Guessing reflection spectra the way you can guess RGB or HSV values
> does not really work, since the relationship between percieved colour
> and its associated spectral curve is a) ambigous and b) sometimes
> quite nonobvious.
Another good point.
You have to use variables an artist can grasp -- or teach them how
to make sense of non-obvious variables.
> You can of course shell out $5K for a Spectrolino (a popular make of
> low-cost (!) spectrophotometer), but not even that kind of device
> will tell you the whole story about a surface. If you -- for example -
> - want to do fluorescence effects, you need measurements from a
> bispectral photometer (a device that is extremely rare and
> expensive), ...
Or you fake it, relying on your eye.
You would have to include examples, like your gallery does.
> or if you want to represent arbitrary BRDFs, you need BRDF
> measurements (which are hard to take, huge datasets, and are
> hard to use). And so on.
Unless you have THz machines with Terabyte memories and the right
way of conceptualizing things so people can learn how to use the
new variables.
> The nasty bit is that once a part of your renderer operates in a
> physically correct way, the rest more or less has to follw suit.
Yep.
It's kind of silly to have one area accurate when other areas still
make raytracing look a bit cartoony.
> There is little point in e.g. mixing spectral reflectances with RGB
> values (actually this is also quite tricky, since RGB values do not
> have an inherent spectrum associated with them), or using fake water
> shaders along polarizable fresnel reflection calculations.
>
> No, the physics are not really the problem. How to properly handle
> physics in a renderer is a problem which is pretty well understood,
> tedious as some aspects of it might be. Nor is performance the main
> issue.
>
> _Using_ such a renderer in a practical way is a different matter
> altogether, and this will be a problem for quite some time to come
> yet.
Scientific illustration I assume.
> So, to properly sum this thread up, the merciful thing to tell the
> original poster is probably "by all means, use that aquamarine
> pigment for water the first reply talked about,...
That was me.
> and think no further!" ;-)
Well, we are thinking a little further - warp proved his point with
some code.
> $0.2E-32
>
> Alexander Wilkie
> --
> http://www.cg.tuwien.ac.at/staff/AlexanderWilkie.html
> http://www.cg.tuwien.ac.at/staff/AlexanderWilkiePGPKey.asc
---