![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Trevor G Quayle" <Tin### [at] hotmail com> wrote:
> "Kenneth" <kdw### [at] earthlink net> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Kenneth" <kdw### [at] earthlink net> wrote:
> "Trevor G Quayle" <Tin### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Kenneth" <kdw### [at] earthlink net> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Trevor G Quayle" <Tin### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christian Walther <cwa### [at] gmx ch> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Trevor G Quayle" <Tin### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Trevor G Quayle" <Tin### [at] hotmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |