On Thu, 16 Nov 2000 16:34:16 +1000, Chris Colefax wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>> Or using a repeat warp, which is how I would have done it.
>
>This is the first suggestion I made (see my original reply), but if
>patterned pigments are used, a repeat warp will cause repeated sections of
>the child patterns to render.  The macro I posted avoids this, behaving
>instead like the internal checker and hexagon patterns.

Whoops.  I missed that.

This is why we added pigment_pattern to POV 3.5, for what it's worth.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker said:
> This is why we added pigment_pattern to POV 3.5, for what it's worth.

Would you elaborate? What will pigment_pattern do? (And should I not have
written a macro for doing arbitrary rectangular checkered patterns of
textures? [Yes, you should have, you learned a bunch by doing so.])

Post a reply to this message

"Chris Colefax" <chr### [at] tagpovrayorg> wrote in message
news:3a12305e@news.povray.org...
> The only thing to note is that the
> gradient pattern is symmetrical around the origin, so the tiling breaks
> along the x and y axes.  This is easily avoided by translating the pattern
> origin out of view.

What is the rationale for this symmetry?

Is there a way to create a gradient function with existing (or 3.5) Povray
commands that lacks this symmetry? More generally,  is there a nice way to
apply arbitrary functions for combining things? I'm dimly aware of
density_file, but that seems pretty extreme (even if it can be used).

Post a reply to this message

Rick Mabry <rma### [at] softdiskcom> wrote:
> What is the rationale for this symmetry?
>
> Is there a way to create a gradient function with existing (or 3.5) Povray
> commands that lacks this symmetry? More generally,  is there a nice way to
> apply arbitrary functions for combining things? I'm dimly aware of
> density_file, but that seems pretty extreme (even if it can be used).

I can't speak for the original coder of the gradient function, but I can
tell you that to calculate the pattern an fabs() function is used
(converting negatives to positives), which results in the symmetry.  It also
means that the gradient pattern in POV 3.1 and earlier does not work
properly for axes other than x, y, and z.

One solution, as suggested earlier in this thread by Peter, is to use a
ramp-wave'd marble pattern.  The only other option at the moment is to use a
patched version of POV-Ray, such as MegaPOV.  This would allow you to either
use the reset_children warp after a repeat warp (although the former will
not be available in POV 3.5), or, as Ron mentioned, the pigment pattern,
e.g. (this will work in MegaPOV and should work in 3.5):

#declare pigment_checker3 = pigment {pigment_pattern {
      gradient x
      color_map {[1/3 rgb 0] [1/3 rgb 0.5] [2/3 rgb 0.5] [2/3 rgb 1]}
      scale 3
      warp {repeat x*3} warp {repeat y offset x} repeat {z offset x}
      }

plane {z, 10
   pigment {pigment_checker3 pigment_map {
      [0 Pigment1] [0.5 Pigment2] [1 Pigment3]
   }}

As you can see, this new feature allows much more flexible and powerful
patterning.

Post a reply to this message

In article <3a14ce99$1@news.povray.org>, "Rick Mabry" 
<rma### [at] softdiskcom> wrote:

> More generally,  is there a nice way to apply arbitrary functions for 
> combining things? I'm dimly aware of density_file, but that seems 
> pretty extreme (even if it can be used).

In MegaPOV, you can supply a function that takes xyz coordinates and 
returns the pattern value, allowing you to specify almost any pattern. 
This is something that will make it into POV 3.5.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <3a14c610$1@news.povray.org>, "Rick Mabry" 
<rma### [at] softdiskcom> wrote:

> Would you elaborate? What will pigment_pattern do?

It lets you use a pigment as a pattern. The color of the pigment is 
calculated and converted to grayscale, then used as the result of the 
pattern.


> (And should I not have written a macro for doing arbitrary 
> rectangular checkered patterns of textures? [Yes, you should have, 
> you learned a bunch by doing so.])

If you learned by doing it, the time was not wasted...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote in message ...
> > Would you elaborate? What will pigment_pattern do?
> It lets you use a pigment as a pattern. The color of the pigment is
> calculated and converted to grayscale, then used as the result of the
> pattern.


converted to grayscale ?
hmmm, wait a minute
look below at my code used with my eschered patterns in p.b.i

    #local FunPig1=function{pigment{object{Obj1 color 0 color 1/3}}}
    #local FunPig2=function{pigment{object{Obj2 color 0 color 2/3}}}
    #local FunPig3=function{pigment{object{Obj3 color 0 color 1}}}

these values 1/3, 2/3 and 1 are in rgb space - each equal for red,
green, blue, right ?
but converted to grayscale they are not this values for gray, right ?
than if I want to simple attach this map to my pattern
texture_map{[0 T_Gold_3C][1/3 T_Grnt24][2/3 T_Wood33][1 T_Silver_3C]}
this is rather not what I want ?
than there should be also in POV function grayscale( color ) with
exactly the same algorithm

ABX

Post a reply to this message

In article <3a151e4a@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> these values 1/3, 2/3 and 1 are in rgb space - each equal for red,
> green, blue, right ?
> but converted to grayscale they are not this values for gray, right ?

I'm not sure which conversion is used. A simple average would make the 
most sense for this application, because it would leave gray colors 
untouched, but it might use the same function used to convert color 
images to grayscale(if it does, it should be changed to use the average, 
in my opinion). I will check this out later...


> than there should be also in POV function grayscale( color ) with
> exactly the same algorithm

I have been planning this function as part of the color conversion 
patch(I have convert_colors() done, I'm trying to work up some good demo 
scenes), but there is one small problem: POV doesn't always use the same 
conversion function.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Rick Mabry wrote:

> ABCABCABCABC
> BCABCABCABCA
> CABCABCABCAB
> ABCABCABCABC
> BCABCABCABCA

Eww, this is striped! If ya want three colors I'd say go with hexagon.

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

In article <chrishuff-9268FA.17205617112000@news.povray.org>, Chris 
Huff <chr### [at] maccom> wrote:

> I'm not sure which conversion is used... I will check this out later...

The GREY_SCALE() macro is used, which uses the function:
Gray = 0.297*R + 0.589*G + 0.114*B
I have changed this to use (R+G+B)/3 in my version.


> I have been planning this function as part of the color conversion 
> patch

And just finished doing it.


> POV doesn't always use the same conversion function.

I used the GREY_SCALE() macro mentioned above. You could also use the 
convert_color() function with HSL or HSV to get a grayscale 
representation...just extract the right channel.
BTW, I named the function "grayscale()", I suppose someone is going to 
want "greyscale()" to be added too...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message