Version: MegaPOV 0.5a
OS: Windows 95b
Hardware: P2-233, 96M

Problem:

Using a height_field with the pattern modifier I have a problem when using
"phase".  The height-field becomes very badly distorted.

An example .pov file can be found in the povray.binaries.scene-files under
the subject heading of "Re: Heightfield / Pattern bug?".

Try rendering with "phase 0" and everything works as expected.
Now try rendering with phase 0.5 and you will see the problem.  Instead of
the bozo pattern changing, it becomes badly distorted.
Bumps has the same behaviour and I believe the ripples pattern also exhibits
this problem.

Please feel free to contact me if I've omitted anything.

Thanks,
Lee Brown

--

lee### [at] prodigynet

Post a reply to this message

Lee Brown <lee### [at] prodigynet> wrote...
>
> Using a height_field with the pattern modifier I have a problem when using
> "phase".  The height-field becomes very badly distorted.
>

Lee,

This is not a bug.  What you are seeing is what you should expect.  Please
carefully read the section on "phase" in the POV documentation.  The phase
modifier essentially "rotates" your color_map.  When rotated, the 0.0=0.0
and 1.0=1.0 end up right next to each-other, so they create a discontinuity
in the function.  That discontinuity produces a vertical drop/rise in the
height-field.

If you change your color_map to the following, then things will look more
like what you'd expect.
    color_map {
      [0 rgb 0]
      [.5 rgb 1]
      [1 rgb 0]
    }

-Nathan

Post a reply to this message

"Nathan Kopp" <Nat### [at] Koppcom> wrote in message
news:394f63a5$1@news.povray.org...
|
| Lee Brown <lee### [at] prodigynet> wrote...
| >
| > Using a height_field with the pattern modifier I have a problem when using
| > "phase".  The height-field becomes very badly distorted.
|
| This is not a bug.  What you are seeing is what you should expect.  Please
| carefully read the section on "phase" in the POV documentation.  The phase
| modifier essentially "rotates" your color_map.  When rotated, the 0.0=0.0
| and 1.0=1.0 end up right next to each-other, so they create a discontinuity
| in the function.  That discontinuity produces a vertical drop/rise in the
| height-field.
|
| If you change your color_map to the following, then things will look more
| like what you'd expect.
|     color_map {
|       [0 rgb 0]
|       [.5 rgb 1]
|       [1 rgb 0]
|     }

I see now that I was looking at it wrong, I should have put a plane at y*0 to
be certain.  I thought surely it was going below 0 instead.  Wrong.  Sorry if
I mislead you Lee.

Bob

Post a reply to this message

> I see now that I was looking at it wrong, I should have put a plane at y*0
to
> be certain.  I thought surely it was going below 0 instead.  Wrong.  Sorry
if
> I mislead you Lee.
Hey it was an easy one to get confused with.  It certainly is
counter-intuitive when comparing phase with something like a normal which is
what I was likening it to.  With a normal (and no map) the phase keyword
acts like I was expecting it to.

Confusculating, but it all makes sense.  Now I can finish that little
animation I started a couple of weeks ago.  It's just a rod in wavy water,
but I'll put a link up when I've got it half-way decent.  MegaPov is
crashing when I try to get glass sides on the container I'm using, but I
think I'm getting some effect of csg randomly choosing one pigment over the
other, so I'll have to go over my csg differences before I get it working
properly.  My next door neighbors recently bought a fish tank ... isn't it
amazing how you look at things in terms of ior and photons when visiting
people!

Thanks people,
Lee
--
lee### [at] prodigynet

Post a reply to this message