To all,

My name is Kevin Odhner (some of you may have seen my Pocketwatch in the
POV-ray Hall of Fame at www.povray.org).

I am looking for a volunteer to recompile POV_ray 3.1 MSDOS source code
for me in order to test a bug fix in the bump_map section of the code.
Chris Young has confirmed the bugs exist and Chris Cason has agreed to
release a patch with my changes when he releases the PovWin source.
Chris recommended I check here for a volunteer to test the changes
first, and I too would feel much better if I could test these changes
before giving them to the POV Team. 
Anyone willing?

The bug I've found is caused by several errors in the bump_map code of
POV_ray which have been hiding there undiscovered since the DKB Trace
days. This bug is what caused Robert Mickelson's tiles to be inverted in
"sundae.pov" ("Never on a Sundae", which features Haagendas icecream, a
scoop and a sundae on a tiled counter.) This famous 'mistake' was not a
mistake afterall, but a POV_ray programming error. Robert doesn't even
know that I've vindicated him yet.<g>

I think the reason this error has gone so long undiscovered is that with
multiple light sources, the brain tends to justify the appearance by
assuming that the lights are positioned where they would have to be to
produce the highlights and shadows it sees.

The results of using a bump_map are usually much worse than a mere
inversion, which can be easily reversed by simply using an inverted
image. In many cases, parts of the map are inverted and others not,
which makes it impossible to fix. There is also a twist which places
highlights and shadows at the wrong angles. The distortions vary
depending on the rotation of the object in space, which should have no
effect at all.

I have attached a zipped file "badbump.zip" which has a sample scene,
bump_map, rendered image and a text file with a full verbal explanation
as well as the offending piece of code and the required corrections.
Reviewing this material will convince you how messed up the bump_map
feature is.

While the errors are significant, the changes required to the code are
simple and few.

If anyone is in a position to compile the source with these changes, I
would much appreciate it, since I am not set up to do so. I am confident
that my corrections will solve most if not all of the distortions, and
I'm certain that this part of the code is not at risk for causing
problems elsewhere.  However, I'd still rather test them before
submitting them to the POV Team, just in case the solution requires some
minor tweaking.

I do hope someone responds quickly to this, since I don't want to miss
the opportunity Chris has offerred me to get a patch released by the POV
Team.

Thanks,

Kevin

Please be so kind as to respond by email at jko### [at] homecom

Post a reply to this message

Attachments:
Download 'badbump.zip' (34 KB)

In <361### [at] homecom> , jko <jko### [at] homecom>  wrote:
>I do hope someone responds quickly to this, since I don't want to miss
>the opportunity Chris has offerred me to get a patch released by the POV
>Team.
>
>Thanks,
>
>Kevin
>
>Please be so kind as to respond by email at jko### [at] homecom


I have applied the patch (all four), the image is posted in
povray.binaries.programming as "bump_map test"


Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany

Post a reply to this message

>In <361### [at] homecom> , jko <jko### [at] homecom>  wrote:
>I do hope someone responds quickly to this, since I don't want to miss
>the opportunity Chris has offerred me to get a patch released by the POV

I forgot: Wow!!! You and your brother seem to have fixed it without ever trying the
code! If it is really right (I am not that kind of expert on things like that) this is
a masterpiece!


    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany

Post a reply to this message

>Chris Young has confirmed the bugs exist and Chris Cason has agreed to
>release a patch with my changes when he releases the PovWin source.

I'll clarify this : the offer was to release an internal patch within the
team, after the POVWIN source was released. This is not the same as a public
patch as the above seems to imply. There is no telling when this will make
it to the full release.

Post a reply to this message

Is this the same bug which appears when a normal map is inside an average
statement, or is it another one?

-- 
                                                           - Warp. -

Post a reply to this message

In <3616e0da.0@news.povray.org> , "Thorsten Froehlich" <fro### [at] charliecnsiitedu>
wrote:

>I have applied the patch (all four), the image is posted in
povray.binaries.programming as "bump_map test"<

My damn e-mail and news client (Outlookk Express on Macintosh) did not encode the
first file as base64 (also I told it to do so :-(  So there is a second try and it
works now. Sorry!


Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany

Post a reply to this message

Nieminen Mika <war### [at] assaricctutfi> wrote:

>  Is this the same bug which appears when a normal map is inside an average
>statement, or is it another one?

don't ask us ... ask the persons who did the patch.

Post a reply to this message

On 4 Oct 1998 08:04:19 -0500, Nieminen Mika <war### [at] assaricctutfi>
wrote:

>  Is this the same bug which appears when a normal map is inside an average
>statement, or is it another one?

That's a different problem.  I'm still investigating if the proposed
patch for normal average has unwanted side-effects.
	Chris Young POV-Team Coordinator

Post a reply to this message

On Sat, 03 Oct 1998 13:33:50 -0400, jko <jko### [at] homecom> wrote:

>To all,
>
>The bug I've found is caused by several errors in the bump_map code of
>POV_ray which have been hiding there undiscovered since the DKB Trace
>days. 

>There is also a twist which places
>highlights and shadows at the wrong angles. The distortions vary
>depending on the rotation of the object in space, which should have no
>effect at all.

I've looked at Thorsten's test image and it doesn't appear to fix all
the problems.  Even if it fixes the bumptest scene you posted here in
the newsgroup, I'm not sure it'll fix the egg image you posted on
compuserve.

The problem with the   x  x  vs.    xx
                                      x            x

seems to be a real bug.  The extra normalization looks like a good
idea too.

The real problem (I think) is that we transform the evaluation point
into the pattern's space but we don't transform the normal.  So if the
pattern is rotated, it perturbs the normal the wrong direction.  My
original design for wood, bozo, gradient, etc. normals had the same
problem when I wrote that part of 3.0.  I found an alternative way to
purturb the normal in 3d instead of 2d but the results aren't as
acurate as they should be.  The artifacts in brick normal are a result
of this 3d compromise.  I need to do a big rewrite to transform the
normal.  We'll have to search the warp chain and lots of other messy
things.  We'll also have to find out if it slows things down and can
we only transform the normal as needed.  I'm not sure how hard this
will be.

I could be wrong.  Maybe a slight tweak of your fix really will fix it
but I don't think so.
	Chris Young, POV-Team Coordinator

Post a reply to this message

On Sat, 03 Oct 1998 13:33:50 -0400, jko <jko### [at] homecom> wrote:

>To all,
>
>The bug I've found is caused by several errors in the bump_map code of
>POV_ray which have been hiding there undiscovered since the DKB Trace
>days. 

>There is also a twist which places
>highlights and shadows at the wrong angles. The distortions vary
>depending on the rotation of the object in space, which should have no
>effect at all.

I've looked at Thorsten's test image and it doesn't appear to fix all
the problems.  Even if it fixes the bumptest scene you posted here in
the newsgroup, I'm not sure it'll fix the egg image you posted on
compuserve.

The problem with the   x  x  vs.    xx
                                      x            x

seems to be a real bug.  The extra normalization looks like a good
idea too.

The real problem (I think) is that we transform the evaluation point
into the pattern's space but we don't transform the normal.  So if the
pattern is rotated, it perturbs the normal the wrong direction.  My
original design for wood, bozo, gradient, etc. normals had the same
problem when I wrote that part of 3.0.  I found an alternative way to
purturb the normal in 3d instead of 2d but the results aren't as
acurate as they should be.  The artifacts in brick normal are a result
of this 3d compromise.  I need to do a big rewrite to transform the
normal.  We'll have to search the warp chain and lots of other messy
things.  We'll also have to find out if it slows things down and can
we only transform the normal as needed.  I'm not sure how hard this
will be.

I could be wrong.  Maybe a slight tweak of your fix really will fix it
but I don't think so.
	Chris Young, POV-Team Coordinator

Post a reply to this message