 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
here's another one that someone postet over there on c.g.r.r:
The following scene consists of an opaque, reflective plane with
a normal applied to it. The underlying plane with a checker
pigment seems to come through the upper plane.
camera { location <-1,20,-20> look_at <0,12,0> }
light_source {
<300,500,100>
color rgb <1,1,1>
}
background { color rgb <0,1,0> }
plane {
y, 0
texture {
pigment { color rgb<.5,.5,.5> }
normal { wood 0.5 scale 10 }
finish { reflection 1}
}
}
plane{
y,-1
texture {
pigment {
checker
color rgb<1,0,0>
color rgb<0,1,0>
}
scale 10
}
finish { ambient 1 }
}
//----------------- cut here ----------------------
Markus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was able to produce a fix for this bug. I submit it here to the
POV-Ray team. If you'd like a copy of my LIGHTING.C file, just let
me know and I'll send it.
-Nathan Kopp
=================
The cause of the bug is kind of tricky. Imagine a bumpy surface:
_______
/ \
| | <--- these don't have to be exactly vertical
______/ \________ (object X)
In POV, the faked bump really looks like this:
______/|/_____\|\________ (object Y)
A B
Reflecting rays don't have much of a problem unless they hit the
parts where the slope is almost perpendicular to un-perturbed normal
(for example, points A or B). In this case, if you have a faked
normal, rays coming straight down towards the object just "fall
through the cracks." In real life, they would really get reflected
two (or more) times:
__ ray in
##\ /
##| /
##|/ ray out (if the surface was shaped like this)
##|\ /
##| \ /
###\_\/_______
##############
##############
With a faked normal, you don't get the second intersection:
ray in
/
/
__\|\________
\
\
\ ray out
So here's how I fixed it. The bug occurs when the direction of the
reflection ray is going the opposite direction of the non-perturbed (raw)
normal. (Note that this version of the raw normal has been flipped to point
towards the camera.)
So when this situation arises, I reflect the ray's direction across
the non-perturbed surface of the object.
===============
Here are the changes (all are in LIGHTING.C):
These changes HAVE been tested. (Of course, only to a limited extent.)
First, I fixed some redundant and buggy code in compute_lighted_texture()
The code
------------------
/* If the surface normal points away, flip its direction. */
VDot(Normal_Direction, RawNormal, Ray->Direction);
if (Normal_Direction > 0.0)
{
VScaleEq(RawNormal, -1.0);
}
------------------
appears in some radiosity-related stuff at the beginning of the funciton,
and then again (in a slightly different form) when the normals are being
perturbed. I simply consolidated this code and moved it to the beginning
of the function (outside of all if statements) so that it always gets
executed.
Now that I was sure that RawNormal had been properly flipped in all
situations, I added a vector parameter "Raw_Normal" to both Reflect()
and Refract(), passed the "RawNormal" variable to it. When Refract()
calls Reflect(), it just passes on the same "Raw_Normal" that it recieved.
Then, right after the line
------------------
VLinComb2(NRay.Direction, n, Normal, 1.0, Ray->Direction);
------------------
in Reflect(), I added:
------------------
/* NK 1998 - Reflection bugfix
if the new ray is going the same direction as raw normal, we
reflect it across the un-perturbed surface. */
VDot(NRay_Direction, NRay.Direction, Raw_Normal);
if (NRay_Direction < 0.0)
{
/* subtract twice the projection of NRay.Direction onto Raw_Normal
from Raw_Normal */
DBL Proj;
Proj = NRay_Direction * -2;
VAddScaledEq(NRay.Direction, Proj, Raw_Normal);
}
/* NK ---- */
------------------
This should fix the problem, and should not cause any un-wanted side
effects. Of course, it needs further testing.
-Nathan Kopp
Markus Becker wrote:
>
> Hello,
>
> here's another one that someone postet over there on c.g.r.r:
>
> The following scene consists of an opaque, reflective plane with
> a normal applied to it. The underlying plane with a checker
> pigment seems to come through the upper plane.
>
> camera { location <-1,20,-20> look_at <0,12,0> }
>
> light_source {
> <300,500,100>
> color rgb <1,1,1>
> }
>
> background { color rgb <0,1,0> }
>
> plane {
> y, 0
> texture {
> pigment { color rgb<.5,.5,.5> }
> normal { wood 0.5 scale 10 }
> finish { reflection 1}
> }
> }
>
> plane{
> y,-1
> texture {
> pigment {
> checker
> color rgb<1,0,0>
> color rgb<0,1,0>
> }
> scale 10
> }
> finish { ambient 1 }
> }
>
> //----------------- cut here ----------------------
>
> Markus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> /* subtract twice the projection of NRay.Direction onto Raw_Normal
> from Raw_Normal */
This comment should be:
/* subtract twice the projection of NRay.Direction onto Raw_Normal
from NRay.Direction */
-Nathan Kopp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I posted a modified version of this code which (makes the bug obvious) in the
povray.text.scene-files group. Rendered images from that file can be found in
povray.binaries.images.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Say, uh, Nathan?
You may not like what I'm about to say after all the work you've put into that
reflection bug-fix there, but... well, um, you see it's like this.
If the 'inverse' keyword is put at the end of a texture statement containing a
reflection finish, there is no problem. The reflection works as it should,
same as what your fixed code does apparently.
I knew there was something amiss about this thing too though after someone
(Buk### [at] aol com) mentioned "missing" reflection when 3.1 was being beta'd.
I don't understand why it would work this way. Seems obvious the correct way
would be *without* the keyword inverse, and used if you wanted a change from
default. Sounds about right huh?
So, maybe it should still be called a bug of sorts.
Message <366413CF.67C36788@Kopp.com>, Nathan Kopp typed...
>
>I posted a modified version of this code which (makes the bug obvious) in the
>povray.text.scene-files group. Rendered images from that file can be found in
>povray.binaries.images.
>
>-Nathan
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/POVring.html
=Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The inverse keyword does seem to make a difference, but it doesn't fix the
problem. I assume that you mean 'inverse' in the object (it is a syntax error
if you put it inside the finish or inside the texture). Also, on a plane,
inverse has the same effect as switching the direction of the normal vector.
Go grab my test scene (in the povray.text.scene-files group) and render it.
Then add 'inverse' to the plane. The problem is still there. At least it was
on my machine. Actually, 'inverse' has a really weird effect that I didn't
expect... maybe I'll look into that...
Thanks for telling me about the 'inverse' keyword, though. Even if it had made
my bugfix null & void, it would be good to know! :-)
-Nathan Kopp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just looked again. Yep, right about the inverse, I could have sworn I had it
working within texture{}, turns out I had failed at putting it elsewhere
(finish{} etc.) and thought I succeeded at putting it there in texture. I
mistakenly read the braces of course.
I've looked at reflecting planes more and found a "wrong look" to the thing,
partly mirrored and partly not at all, about like your test images but it has
to do with filter or transmit and if they're used or not.
I was trying ior and it makes a lot of difference in the look, however, it
comes down to the fact that reflection fades with increasing transparency. A
known fact of the sort that causes 'finish' to fade away until none exists if
filter or transmit is 1, otherwise no "invisible" container objects could be
made since default diffuse, etc. would prevent them from being possible.
Except that reflection does not allow 100% disappearence in case of 100%
transparency, and refraction makes it all look further intertwined.
All in all I think the reflection_exponent is something to look into. You can
set it to zero and get a transparency-based reflection it seems unless
refraction is on, instead of the other way around (whatever).
I'm going to get your test file and try it too, btw.
So anyway, to review:
filter [0...1] and/or transmit [0...1]
reflection [0..1] and/or reflection_exponent [0..1]
ior [1...?]
inverse (or not)
These all seem to be doing a strange thing together; like I even need to say
that.
Message <3664BA3F.DC68E210@Kopp.com>, Nathan Kopp typed...
>
>The inverse keyword does seem to make a difference, but it doesn't fix the
>problem. I assume that you mean 'inverse' in the object (it is a syntax
error
>if you put it inside the finish or inside the texture). Also, on a plane,
>inverse has the same effect as switching the direction of the normal vector.
>
>Go grab my test scene (in the povray.text.scene-files group) and render it.
>Then add 'inverse' to the plane. The problem is still there. At least it
was
>on my machine. Actually, 'inverse' has a really weird effect that I didn't
>expect... maybe I'll look into that...
>
>Thanks for telling me about the 'inverse' keyword, though. Even if it had
made
>my bugfix null & void, it would be good to know! :-)
>
>-Nathan Kopp
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/POVring.html
=Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
>
> on my machine. Actually, 'inverse' has a really weird effect that I didn't
> expect... maybe I'll look into that...
>
I take this comment back. ;-) I should have expected the 'weird effect'.
It is simply total-internal-reflection.
-Nathan Kopp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
