3.5.beta.9.icl.win32, WinXp, 800MHz P3, 512MB

I looked around for some previous encounter or explanation of this and not
seeing anything I'm going ahead and posting about it.

filtered, transmitted colors are normal if between 0 and 1; however, if the
color value(s) are greater than 1 while filter and/or transmit is used it
produces a unexpected color (blue becomes red) instead of saturating
further.  Likewise, if the filter or transmit value by itself goes beyond
the 0 to 1 range.
A filter 2 added to a rgb 0.5 is okay, but filter 2 with a rgb 0.6
(multiplies out to 1.2) is not.  Of course I'm not at all sure if this was
intended earlier in a program change.

Looking in the Scene Help at section 6.1.5.5 Common Color Pitfalls and
elsewhere I don't see this mentioned.

bob h

Post a reply to this message

"bob h" <omn### [at] charternet> wrote in news:3c4210f3$1@news.povray.org:

> A filter 2 added to a rgb 0.5 is okay, but filter 2 with a rgb 0.6
> (multiplies out to 1.2) is not.

I was unable to duplicate any unusual behavior with the following test 
scene.


plane {z, 3 hollow pigment {checker rgb <1,0,0>, rgb <0,1,0> scale 0.5} 
finish {ambient 1}}

box {<-1,-1,0> <1,1,1> pigment {rgb 0.6 filter 2}}

camera {location z*-3 look_at 0}


I will try to confirm your bug if you can post a scene which demonstrates 
what you are talking about.

Post a reply to this message

"Coridon Henshaw" <che### [at] sympaticoca> wrote in message
news:Xns### [at] 204213191226...
> "bob h" <omn### [at] charternet> wrote in news:3c4210f3$1@news.povray.org:
>
> > A filter 2 added to a rgb 0.5 is okay, but filter 2 with a rgb 0.6
> > (multiplies out to 1.2) is not.
>
> I was unable to duplicate any unusual behavior with the following test
> scene.
>
> plane {z, 3 hollow pigment {checker rgb <1,0,0>, rgb <0,1,0> scale 0.5}
> finish {ambient 1}}
>
> box {<-1,-1,0> <1,1,1> pigment {rgb 0.6 filter 2}}
>
> camera {location z*-3 look_at 0}
>
>
> I will try to confirm your bug if you can post a scene which demonstrates
> what you are talking about.

Thanks Coridon.
It is eluding me at the moment.  I had it doing so again once I put a light
source in with your script but using the text object I was finding it happen
with before.  Not only text objects though, I first noticed it when I
checked on making a sphere and box CSG transparent as a different test.
Wish I had grabbed a screen shot of the rather wildly wrong look to it when
I had the chance.  Trying with your simpler scene and that box it wouldn't
make itself shown, and now I can only get a slight yellowing of the text
object I was using too.
I know Thorsten keeps saying this stuff can't change on it's own but this
wouldn't be the first time such an experience has occured.
Anyway, I'll get back with anything I have once it shows itself again.

bob h

Post a reply to this message

"Coridon Henshaw" <che### [at] sympaticoca> wrote in message
news:Xns### [at] 204213191226...
> "bob h" <omn### [at] charternet> wrote in news:3c4210f3$1@news.povray.org:
>
> > A filter 2 added to a rgb 0.5 is okay, but filter 2 with a rgb 0.6
> > (multiplies out to 1.2) is not.
>
> I will try to confirm your bug if you can post a scene which demonstrates
> what you are talking about.

First of all, thanks for the offer.
I was too hasty before thinking it was filter and color alone causing it,
cursed complex scene files :-)   At least I know I have narrowed it down to
the following script.

/* transparency plus fresnel reflection and exponent causes unexpected
colors */

camera {perspective location <0,0,-4> angle 45 look_at 0}
light_source {-10*z, color rgb 1}

text {
        ttf "timrom.ttf" "FILTER 1+",1,0
        pigment {
                rgbft
                <1,1,1,1.01,0> // filter greater than 1
                }
        finish {
                reflection {
                        0.01,1  // min needs to be greater than zero
                         fresnel
                         exponent 0.50001  // lower to 0.5 and effect
disappears
                        }
                }
 translate <-2,0,0>
}


This shows it to be a combination of things, although the culprit seems to
be fresnel and exponent.  If you or anybody else can check further into it
maybe there's more or less to this.
Beta 10 does the same as what i saw in beta 9, the 3.5.beta.10.icl.w32 to be
exact.

bob h

Post a reply to this message

bob h schrieb in Nachricht <3c4676a3@news.povray.org>...
>
>/* transparency plus fresnel reflection and exponent causes unexpected
>colors */
>
>camera {perspective location <0,0,-4> angle 45 look_at 0}
>light_source {-10*z, color rgb 1}
>
>text {
>        ttf "timrom.ttf" "FILTER 1+",1,0
>        pigment {
>                rgbft
>                <1,1,1,1.01,0> // filter greater than 1
>                }
>        finish {
>                reflection {
>                        0.01,1  // min needs to be greater than zero
>                         fresnel
>                         exponent 0.50001  // lower to 0.5 and effect
>disappears
>                        }
>                }
> translate <-2,0,0>
>}
>


I can partially confirm this. I get a red text with your code instead of an
transparent one. Lowering exponent to 0.40001 didn't change that. Lowering
filter to 1 or removing the finish-statement made the the text transparent.

Marc-Hendrik

PII450, 128 MB, Win 98, Pov 3.5 beta 10

Post a reply to this message

Wasn't it bob h who wrote:
>/* transparency plus fresnel reflection and exponent causes unexpected
>colors */
>
>camera {perspective location <0,0,-4> angle 45 look_at 0}
>light_source {-10*z, color rgb 1}
>
>text {
>        ttf "timrom.ttf" "FILTER 1+",1,0
>        pigment {
>                rgbft
>                <1,1,1,1.01,0> // filter greater than 1
>                }
>        finish {
>                reflection {
>                        0.01,1  // min needs to be greater than zero
>                         fresnel
>                         exponent 0.50001  // lower to 0.5 and effect
>disappears
>                        }
>                }
> translate <-2,0,0>
>}

Hasn't it always been the case that POV is not guaranteed to behave in
any sort of "expected" manner if you specify out-of-range values? The
range checking in POV is kept weak, so that if someone happens to find
that things like lights with negative brightness are useful in a
particular scene then they can use them. If out-of-range values don't
achieve anything useful, then don't use them.

Filter values greater than 1 happen to behave rather strangely but the
odd effects are usually not apparent when the filter is so close to 1.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Mike Williams" <mik### [at] nospamplease> wrote in message
news:6mY### [at] econymdemoncouk...
>
> Hasn't it always been the case that POV is not guaranteed to behave in
> any sort of "expected" manner if you specify out-of-range values? The
> range checking in POV is kept weak, so that if someone happens to find
> that things like lights with negative brightness are useful in a
> particular scene then they can use them. If out-of-range values don't
> achieve anything useful, then don't use them.
>
> Filter values greater than 1 happen to behave rather strangely but the
> odd effects are usually not apparent when the filter is so close to 1.

Yes, I agree to that logic.  Just that I often use numbers beyond their
original intention and I usually don't see such extreme fluxuation like that
example shows.  Led me to believe the behavior has only recently changed
somehow.  That being to do with what Rune was working on quite a while back,
concerning transarency clipping or "correctness".  I always expected there
to be a smooth transition either way and yet this obviously is anything but.

Just so some of you check it out for yourselves and offer your own opinions,
that's all I care about.  I can't ask that the program adhere to
unconventional methods after all.

  ;-)

bob h

Post a reply to this message