 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In <361### [at] home com> , 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just to follow up on my earlier message...
VScaleEq(xprime,1.0/Length) does Normalize xprime because Length is
the length of xprime. So the VScaleEq is ok as it is. And I've
verified that your patch does not fix the egg grove example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
