I'm a rookie in pov-ray, and want to use height_map for water-simulation, I
tried to use "intersecion" on the height_map,box objects, but caused strange
artifacts, but I don't know how to solve it? Could someone help?

Here's the code:

#include "colors.inc"
camera {

location <-1,4,-2>
look_at <0.5,0,0.5>

angle 36
}

light_source { <-1, 1.30, -1> White }

plane { y, 0
texture {
//pigment {  White }
pigment {
image_map {jpeg "brick.jpg"}
    rotate <90,0,0>

 }
finish{
ambient .3
diffuse 0.7

}
}
}
plane { z, 1
texture {
pigment {  White }
finish{
ambient .2
diffuse 0.7
}
}
}
plane { x, 1
texture {
pigment {  White }
finish{
ambient .2
diffuse 0.7
}
}
}
/*
box{
 <0,0,0>,<1,1,1>
 pigment{Green}
 }      */
intersection{
height_field {
sys "Surface.bmp" //can be replaced by other images
smooth



 }
box{
// <0.000001,0.000001,0.000001>,<0.999,0.999,0.999>
// <0,0,0>,<1,1,1>
// <-0.000001,-0.000001 ,-0.000001>,<1.000001,1.000001,1.000001>
//<0,0,0>,<1.000001,1.000001,1.000001>
// <0.000001,0.000001,0.000001>,<1.000001,1.000001,1.000001>
 <-0.000001,-0.000001,-0.000001>,<1.000001,1.000001,1.000001>
 }
 texture
    {
        pigment {   color rgbt <1, 1, 1, 1> }
        finish
        {
            ambient 0.0
            diffuse 0.0  //
            reflection
            {
                0.02, 1.0
                fresnel on
            }
            specular 1
            roughness .003
        }
     }
interior {ior 1.333}
}

Post a reply to this message

Your intersection is not serving any purpose, because the 'box' part of
the intersection is actually the same size or slightly larger than your
height_field. So the result is just the height_field itself. (If the box were
smaller, then it would successfully 'trim off' part of the height_field.) By the
way, it's usually a good idea to scale down a height_field in the y-dimension,
for example <1,.25,1>. Without scaling it, it takes up an entire 1X1X1 cubic
space, and looks very jagged and odd when it's that tall. I'm guessing that you
don't want it to be so tall.

I think what's mostly confusing the scene is the pigment{rgbt <1,1,1,1>} for the
entire intersection. I assume you want it there, in order to see through the
height_field's 'water' to the bottom plane. But if the effect has ended up
looking grainy and strange, it's a result of global_settings{max_trace_level
....}  needing a boost. (Take a look in the documentation for max_trace_level.)
The default is 5; but your height_field has reflection and ior (both at *high*
values, which may not be a good idea), so a camera ray is having to do a lot of
work on its way to the bottom plane. If max_trace_level is too low, you'll
always see dark spots, or graniness. Try a higher value.

Another suggestion would be to use as high-resolution an image as you can, to
make your height_field.

Here's your intersection code slightly re-worked:

intersection{
height_field {
sys "Surface.bmp"
smooth
scale <1,.15,1>
translate -.001*y // to eliminate any possible 'coincident surfaces' between
// height_field and bottom plane. It puts the bottom of the water slightly
// *below* the plane, but that's OK.
 }
box{
-.1,.7 // this trims the height_field somewhat. And it's an easier way of
// writing <-.1,-.1,-.1>, <.7,.7,.7>
 }

 texture
    {
        pigment {color rgbt <1, 1, 1, 1> } // or simply rgbt 1
        finish
        {
            ambient 0.0
            diffuse 0.0
            reflection
            {
                0.02, 1.0
                fresnel on
            }
            specular 1
            roughness .003
        }
     }
interior {ior 1.333}
}

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Your intersection is not serving any purpose, because the 'box' part of
> the intersection is actually the same size or slightly larger than your
> height_field. So the result is just the height_field itself. (If the box were
> smaller, then it would successfully 'trim off' part of the height_field.) By the
> way, it's usually a good idea to scale down a height_field in the y-dimension,
> for example <1,.25,1>. Without scaling it, it takes up an entire 1X1X1 cubic
> space, and looks very jagged and odd when it's that tall. I'm guessing that you
> don't want it to be so tall.
>
> I think what's mostly confusing the scene is the pigment{rgbt <1,1,1,1>} for the
> entire intersection. I assume you want it there, in order to see through the
> height_field's 'water' to the bottom plane. But if the effect has ended up
> looking grainy and strange, it's a result of global_settings{max_trace_level
> ....}  needing a boost. (Take a look in the documentation for max_trace_level.)
> The default is 5; but your height_field has reflection and ior (both at *high*
> values, which may not be a good idea), so a camera ray is having to do a lot of
> work on its way to the bottom plane. If max_trace_level is too low, you'll
> always see dark spots, or graniness. Try a higher value.
>
> Another suggestion would be to use as high-resolution an image as you can, to
> make your height_field.
>
> Here's your intersection code slightly re-worked:
>
> intersection{
> height_field {
> sys "Surface.bmp"
> smooth
> scale <1,.15,1>
> translate -.001*y // to eliminate any possible 'coincident surfaces' between
> // height_field and bottom plane. It puts the bottom of the water slightly
> // *below* the plane, but that's OK.
>  }
> box{
> -.1,.7 // this trims the height_field somewhat. And it's an easier way of
> // writing <-.1,-.1,-.1>, <.7,.7,.7>
>  }
>
>  texture
>     {
>         pigment {color rgbt <1, 1, 1, 1> } // or simply rgbt 1
>         finish
>         {
>             ambient 0.0
>             diffuse 0.0
>             reflection
>             {
>                 0.02, 1.0
>                 fresnel on
>             }
>             specular 1
>             roughness .003
>         }
>      }
> interior {ior 1.333}
> }

Thank you very much, but it still has problems , for the side faces of the
intersection object no refractions came out. The front and left face seem that
they don't exist, so we can directly see the bottom as if no water is here.

from http://www.f-lohmueller.de/pov_tut/all_shapes/shapes655e.htm,
I changed the sign of D,finally this can get a good result.What shocks me is
that the sign is very important. Only <D,-D,D> works well.


#declare D = 0.00001;

intersection{
height_field {
sys "Surface.bmp"
smooth

   translate<0,D,0>

 }
box{
 <D,-D,D>,<1+D,1+D,1+D>

 }
 texture
    {
        pigment {   color rgbf <1, 1, 1, 1> }
        finish
        {
            ambient 0.0
            diffuse 0.0  //
            reflection
            {
                0.02, 1.0
                fresnel on
            }
            specular 1
            roughness .03
        }
     }
interior {ior 1.33
//  dispersion  1.01

 }
}

Post a reply to this message

"Terry  Chen" <nwp### [at] gmailcom> wrote:
> I'm a rookie in pov-ray, and want to use height_map for water-simulation, I
> tried to use "intersecion" on the height_map,box objects, but caused strange
> artifacts, but I don't know how to solve it? Could someone help?

Meshes are not the best approach for water simulation (a height_field is a very
simple kind of a mesh). That does not mean that meshes are not suited
completelly to simulate water (see La Lument by Marc Lacquier, POV-Comp 2004,
who shows impressive results with meshes). Better suited are isosurfaces. Chris
Hormann has given an excellent tutorial about this issue:

http://www.imagico.de/pov/water/index.php?lang=de

Best regards,
Michael

Post a reply to this message

"MichaelJF" <mi-### [at] t-onlinede> wrote:
> "Terry  Chen" <nwp### [at] gmailcom> wrote:
> > I'm a rookie in pov-ray, and want to use height_map for water-simulation, I
> > tried to use "intersecion" on the height_map,box objects, but caused strange
> > artifacts, but I don't know how to solve it? Could someone help?
>
> Meshes are not the best approach for water simulation (a height_field is a very
> simple kind of a mesh). That does not mean that meshes are not suited
> completelly to simulate water (see La Lument by Marc Lacquier, POV-Comp 2004,
> who shows impressive results with meshes). Better suited are isosurfaces. Chris
> Hormann has given an excellent tutorial about this issue:
>
> http://www.imagico.de/pov/water/index.php?lang=de
>
> Best regards,
> Michael

Sorry, I must correct myself, Marc used an isosurface too.

Best regards,
Michael

Post a reply to this message

Michael
>
> Sorry, I must correct myself, Marc used an isosurface too.
>
> Best regards,
> Michael

But still impressive...

Post a reply to this message

On 05/01/2013 6:54 PM, MichaelJF wrote:
> Sorry, I must correct myself, Marc used an isosurface too

Isosurfaces can make good water but they are time consuming to render.
It might be an idea if Terry looked at Tim Nikias's No Lights site. Tim 
created a set of macros to simulate an animated liquid surface. 
http://www.nolights.de/downloads.html#lssm

It adds up to a complete system where the waves will reflect off 
boundaries or be created by raindrops, there might even be a "stomp" 
feature which starts the waves by simulating a shock to the boundaries. 
I am a bit vague because it is a long time ago that I did some testing 
for him. It creates a mesh (of a sort) for each frame, which can be 
converted to a PovRay Mesh by using his MMM Macros.
http://www.nolights.de/downloads.html#MMM

They are complicated but there are detailed help files.

Here is one of his examples:

http://youtu.be/QEzkFhQEk6g

-- 
Regards
     Stephen

Post a reply to this message

"Terry  Chen" <nwp### [at] gmailcom> wrote:

> Thank you very much, but it still has problems , for the side faces of the
> intersection object no refractions came out. The front and left face seem that
> they don't exist, so we can directly see the bottom as if no water is here.
>
> from http://www.f-lohmueller.de/pov_tut/all_shapes/shapes655e.htm,
> I changed the sign of D,finally this can get a good result.What shocks me is
> that the sign is very important. Only <D,-D,D> works well.
>

Oh, now I see what you are trying to do. (Sorry, I was confused about what your
problem was. Your link to Freidrich Lohmuller's page made it clear.)

His page actually has some small mistakes, in his use of D there. I had to work
that out too.

To get what you want, your box needs to be made *smaller* on all sides than the
height_field (*except* for the top and bottom surfaces of the box.) This is what
creates the solid 'sides' of the height_field, in an intersection. If the box is
made smaller on the TOP, it will cut away some of your water waves (but they
will still be solid.) If it is made smaller on the BOTTOM, the intersection may
not be solid in certain places there--it is just like using water_level. (The
'top' and 'bottom' of a height_field behave differently in an intersection.)

But here is something interesting, and useful to know: A height_field, by
nature, actually has an *infinite* depth in -y. It is invisible, but it is
there. Because of this, the bottom of your intersection box could have a large
NEGATIVE value for y, and the intersection will still be 'solid', way down in
-y.

Here is your code again. I have added a few things, to make it more useful for
you. Now, you can make your water any 'depth' that you want, and it will remain
solid on all sides. Note that the water depth and the height_field scale are two
separate things now.

#declare D = 0.00001;
#declare water_depth = .3; // any positive value
#declare HF_y_scale = 0.55; // for the scale of the 'top surface' of the
// water; any positive value

intersection{
height_field {
sys "Surface.bmp"
smooth
scale <1,HF_y_scale,1>
translate <0,water_depth,0>
 }

box{
 <D,-D,D>, // the bottom y-value can be anything now, + or -, but no higher
// than water_depth
<1-D,water_depth + HF_y_scale + D,1-D> // x and z are *smaller* than the
// height_field, not larger.
 }

 texture
    {
        pigment {color rgbf <1, 1, 1, 1>} // Here, rgbf does the same as rgbt
// because the water has no 'color.' Try changing it to rgbf <.85,.90,1,1>
        finish
        {
            ambient 0.0
            diffuse 0.0
            reflection
            {
                0.02, 1.0
                fresnel on
            }
            specular 1
            roughness .03
        }
     }
interior {ior 1.33}
}

Post a reply to this message

By the way, D = 0.00001  serves TWO purposes here: To make the intersection box
smaller, AND to eliminate any tiny 'floating-point errors' between the box and
the height_field. Floating point errors can make the flat sides of your
intersection look 'grainy', as I mentioned before. When two flat surfaces
exactly overlap, you may see such problems.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> If it is made smaller on the BOTTOM, the intersection may not be solid in
> certain places there--it is just like using water_level.

Sorry, I was mistaken about that. I will try to explain it better: If the image
you use to make your height_field has any pure black or very dark colors, then
those parts of the height_field will be at or very close to the bottom surface
(y = 0.) If the bottom of your intersection box cuts into the height_field
*above* that distance, it will create holes in the bottom of the
height_field/intersection at those places (although the remainder of the bottom
surface will still be solid.)

Post a reply to this message