POV-Ray : Newsgroups : povray.general : slope pattern bug? Server Time
1 Aug 2024 12:26:31 EDT (-0400)
  slope pattern bug? (Message 4 to 13 of 13)  
<<< Previous 3 Messages Goto Initial 10 Messages
From: Kenneth
Subject: Re: slope pattern bug?
Date: 17 Jan 2006 23:25:00
Message: <web.43cdc300e7742b9117cd4fde0@news.povray.org>
> Hash: SHA1
>

> >
>  Have you tried adding the "ramp_wave" keyword to your pigment
> definition? http://www.povray.org/documentation/view/3.6.1/404/
>
>   Jerome

Actually, no. But I do see now what the various waveform types do.  Thanks.
But the "problem" (for me) is still there, with the repeating patterns. I
was hoping the slope pattern would do what I had wanted, but my conception
of it seems to be wrong.

Ken


Post a reply to this message

From: Kenneth
Subject: Re: slope pattern bug?
Date: 17 Jan 2006 23:50:00
Message: <web.43cdc878e7742b9117cd4fde0@news.povray.org>
"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote in message

>
> You seem to be misinterpreting the way lo_slope and hi_slope work...

Yes, it does seem so. But I've re-read the slope pattern definition a bunch
of times, and still keeping coming up with  my *own* (wrong) conclusion
about how it operates.  :-[

> If, as I understand it, you want a texture only on the top half,
> you wouldn't use the hi_slope and lo_slope, instead, in the slope map, you
> would have no texture from index 0 to 0.5, and texture from 0.5 to 1.0.

Yes, I agree, that does work beautifully. That's exactly the way I finally
textured my object. But what I as *hoping* was that I could "restrict" the
full color_map colors to only a portion of the object...based on the
object's normals (using a sphere as a simple example.) Alas, no.

Your tip about the <0,-1,0> mistake in the docs has me scratching my
head...I thought I fairly well understood it as written! Egads, time to go
back over the docs once again....

Thanks for your response.


Post a reply to this message

From: Kenneth
Subject: Re: slope pattern bug?
Date: 18 Jan 2006 02:15:01
Message: <web.43cde912e7742b911f99adeb0@news.povray.org>
"Kenneth" <kdw### [at] earthlinknet> wrote:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:

> > If, as I understand it, you want a texture only on the top half,
> > you wouldn't use the hi_slope and lo_slope, instead, in the slope map, you
> > would have no texture from index 0 to 0.5, and texture from 0.5 to 1.0.
>
> Yes, I agree, that does work beautifully....
>

I should qualify that: It worked beautifully, because I applied the slope
map pattern over a previous texture. But used by itself (as the only
texture), strange things happen, as I've since discovered.

Can someone p*l*e*a*s*e explain why the following two examples show
different slope pattern results? I have some theories, but they're all pure
wacky guesswork.

The first example shows the way the slope pattern worked succesfully for me
(and it makes sense) :  The pattern is applied over a previous (white)
texture, and its red color fades to transparency as it reaches the opposite
side of the sphere.  Just what I wanted! But the second example--using the
slope pattern alone--shows the red color appearing on BOTH sides of the
sphere. Why so?

Help!!!

FIRST EXAMPLE:
sphere {0, 1
// 1st texture
 texture{pigment{color rgb 1} // WHITE
     finish{
    ambient .3
    diffuse .7
               }
             }

// 2nd texture
  texture {
    pigment {
        slope {<1,0,0>}
       color_map {
                        [0 color rgb <1,0,0>] // RED
                        [.2 color rgb <1,0,0>]
                        [.5 color rgbt 1]
                        [1 color rgbt 1] // TRANSPARENT
                            }
                    }
       finish{
          ambient .3
          diffuse .7
                 }
               }
           } // end of sphere


2nd EXAMPLE:
sphere {0, 1
  texture {
    pigment {
        slope {<1,0,0>}
       color_map {
                        [0 color rgb <1,0,0>] // RED
                        [.2 color rgb <1,0,0>]
                        [.5 color rgbt 1]
                        [1 color rgbt 1] // TRANSPARENT
                            }
                    }
       finish{
         ambient .3
         diffuse .7
                }
               }
              } // end of sphere


Post a reply to this message

From: Christian Walther
Subject: Re: slope pattern bug?
Date: 18 Jan 2006 05:08:06
Message: <43ce1386$1@news.povray.org>
Kenneth wrote:
> Can someone p*l*e*a*s*e explain why the following two examples show
> different slope pattern results? I have some theories, but they're all pure
> wacky guesswork.
> 
> The first example shows the way the slope pattern worked succesfully for me
> (and it makes sense) :  The pattern is applied over a previous (white)
> texture, and its red color fades to transparency as it reaches the opposite
> side of the sphere.  Just what I wanted! But the second example--using the
> slope pattern alone--shows the red color appearing on BOTH sides of the
> sphere. Why so?

What you're seeing on the right side in the second scene is the back 
surface of the sphere (through the transparent front surface). Its 
normal points inward, and therefore the slope pattern value is between 0 
and 0.5. Try replacing your sphere { 0, 1 } by a difference { sphere { 
0, 1 } plane { -z, 0 } }.

  -Christian


Post a reply to this message

From: Trevor G Quayle
Subject: Re: slope pattern bug?
Date: 18 Jan 2006 08:35:00
Message: <web.43ce43dce7742b916c4803960@news.povray.org>
>
> Yes, I agree, that does work beautifully. That's exactly the way I finally
> textured my object. But what I as *hoping* was that I could "restrict" the
> full color_map colors to only a portion of the object...based on the
> object's normals (using a sphere as a simple example.) Alas, no.



>
> Your tip about the <0,-1,0> mistake in the docs has me scratching my
> head...I thought I fairly well understood it as written! Egads, time to go
> back over the docs once again....
>

I didn't mean this was an actual mistake in the docs.  The docs makes sense
if you remember that they are using <0,-1,0>.  If you assume (as I did the
first time I went through) that "up" is <0,1,0>, then the docs seem wrong.
Hope I didn't confuse you any more than necessary...



-tgq


Post a reply to this message

From: Trevor G Quayle
Subject: Re: slope pattern bug?
Date: 18 Jan 2006 08:50:00
Message: <web.43ce46b3e7742b916c4803960@news.povray.org>
"Kenneth" <kdw### [at] earthlinknet> wrote:
> I should qualify that: It worked beautifully, because I applied the slope
> map pattern over a previous texture. But used by itself (as the only
> texture), strange things happen, as I've since discovered.
>
> Can someone p*l*e*a*s*e explain why the following two examples show
> different slope pattern results? I have some theories, but they're all pure
> wacky guesswork.
>
> The first example shows the way the slope pattern worked succesfully for me
> (and it makes sense) :  The pattern is applied over a previous (white)
> texture, and its red color fades to transparency as it reaches the opposite
> side of the sphere.  Just what I wanted! But the second example--using the
> slope pattern alone--shows the red color appearing on BOTH sides of the
> sphere. Why so?
>

That is a bit of a conundrum.  What happens is that as the rays hit the
sphere, they evaluate the slope and apply the pigment.  Now in areas where
the sphere is transparent or partially transparent, the rays continue
through and hit the back of the sphere from the *inside* and evaluate the
slope of the normal of this surface which gives opposite results of the
front surface. So the extra pigment you see is actually on the inside of
the opposite surface of the sphere as seen through the transparent texture
on the front surface.
Now how to get around this may be a tad more complex, I'll have to think
about that.

-tgq


Post a reply to this message

From: Trevor G Quayle
Subject: Re: slope pattern bug?
Date: 18 Jan 2006 09:00:00
Message: <web.43ce4926e7742b916c4803960@news.povray.org>
"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Now how to get around this may be a tad more complex, I'll have to think
> about that.

Ah, figured something out.  You can use interior_texture, which applies a
different texture to the interior of the object.  For the slope map
texture, you need it to basically be opposite the exterior texture as the
mormals of the inside are opposite.  Do this by using the same slope
pattern inside, but reverse the slope normal (ie, <1,0,0> becomes <-1,0,0>)


//START
sphere {0, 1
  texture{
    pigment{slope {<1,0,0>}
       color_map {[0.0 color rgb <1,0,0>] // RED
                  [0.2 color rgb <1,0,0>]
                  [0.5 color rgbt 1]
                  [1.0 color rgbt 1] // TRANSPARENT
        }
    }
    finish{ambient .3 diffuse .7}
  }
  interior_texture{
    pigment{slope {<-1,0,0>}
       color_map {[0.0 color rgb <1,0,0>] // RED
                  [0.2 color rgb <1,0,0>]
                  [0.5 color rgbt 1]
                  [1.0 color rgbt 1] // TRANSPARENT
        }
    }
    finish{ambient .3 diffuse .7}
  }
} // end of sphere
//END


-tgq


Post a reply to this message

From: Kenneth
Subject: Re: slope pattern bug?
Date: 19 Jan 2006 02:35:00
Message: <web.43cf40a6e7742b91dbcfc3c90@news.povray.org>
Christian Walther <cwa### [at] gmxch> wrote:

> What you're seeing on the right side in the second scene is the back
> surface of the sphere (through the transparent front surface). Its
> normal points inward, and therefore the slope pattern value is between 0
> and 0.5. Try replacing your sphere { 0, 1 } by a difference { sphere {
> 0, 1 } plane { -z, 0 } }.
>
>   -Christian

Thanks.  I have to confess, in my wacky theorizing I never thought of the
normals on the INSIDE surface being used.  But it makes perfect sense.
Right now, I can't for the life of me think of a use for that particular
"feature"...but give me time!!!

And it didn't occur to me to simply "wipe out" the offending part of the
sphere. A perfect solution. HOWEVER... if I change the index values of my
color map to, say,

[0.0 color rgb <1,0,0>]
[0.7 color rgb <1,0,0>]
[0.8 color rgbt 1]
[1.0 color rgbt 1]

then the offending part can't be truncated--because along with the normals
on the OUTER surface applying red to the sphere about 70% of the way from
left to right, the INNER normals are covering the surface 70% of the way
from right to left!  So it looks like a solid sphere, no transparency
anywhere.

I wonder if this was forseen when the slope pattern was conceived or
written. A solution, off the top of my head, would be to eliminate the use
of normals on the inside of an object. Though that may leave others WANTING
that feature; or may have other unintended consequences.

Ken




Ken


Post a reply to this message

From: Kenneth
Subject: Re: slope pattern bug?
Date: 19 Jan 2006 04:10:00
Message: <web.43cf56b1e7742b91dbcfc3c90@news.povray.org>
"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> >

>
> I didn't mean this was an actual mistake in the docs.  The docs makes sense
> if you remember that they are using <0,-1,0>.  If you assume (as I did the
> first time I went through) that "up" is <0,1,0>, then the docs seem wrong.
> Hope I didn't confuse you any more than necessary...
>

Thanks.  What a relief! ;-)

Yeah, I had to reorient my own thinking about "slopes" when I first read the
slope pattern docs. My school math classes all those years ago drilled into
me that a slope of 0 was, so to speak,  "horizontal", and a slope of +1 was
45-deg. upward. (And a slope approaching vertical had a value approaching
infinity!) Yet it makes sense why POV treats "slope" differently, confining
its value between 0 and 1 to represent object normals varying between +1
and -1.  (You math folks, please correct me if I'm out of my depth here.) I
guess the only really "confusing" thing is that the slope pattern is called
that...though I can't think of a more appropriate term.

Ken


Post a reply to this message

From: Kenneth
Subject: Re: slope pattern bug?
Date: 19 Jan 2006 05:45:01
Message: <web.43cf6c9ae7742b91dbcfc3c90@news.povray.org>
"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:

>
> Ah, figured something out.  You can use interior_texture, which applies a
> different texture to the interior of the object....

That's really brilliant!  It works as advertised. THANKS!

I'm attempting to use this trick to see if I can get my original, hoped-for
results. (So far, no luck.) But it's worth experimenting with.

Ken


Post a reply to this message

<<< Previous 3 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.