On Wed, 15 Nov 2000 12:00:24 -0500, Rick Mabry wrote:
>Thanks for the macro suggestions. They both worked great for color pigments.
>I am trying to modify them to allow for image_maps --- at present they do
>not seem to accomodate these (due to stretching and such).

In that case, try the modification below.  Make your image maps fit in the
square from <0,0,0> to <1,1,0>.  (If you do that and make them tiled, you can
remove the translates in the macro below as well.)

>>  #macro checker_pigment (Pigment1, Pigment2, Pigment3)
>>          gradient x pigment_map {
>>             [1/3 Pigment1] [1/3 Pigment2] [2/3 Pigment2] [2/3 Pigment3]}

Replace this line with

  [1/3 Pigment1 scale <1/3,1,1>]
  [1/3 Pigment2 translate x scale <1/3,1,1>]
  [2/3 Pigment2 translate x scale <1/3,1,1>]
  [2/3 Pigment3 translate 2*x scale <1/3,1,1>]
  }

>>          warp {repeat x}
>>          warp {repeat y offset 1/3*x}
>>          scale <3,1,1>
>>    #end


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

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...

> On Wed, 15 Nov 2000 12:00:24 -0500, Rick Mabry wrote:
> >Thanks for the macro suggestions. They both worked great for color
pigments.
> >I am trying to modify them to allow for image_maps --- at present they do
> >not seem to accomodate these (due to stretching and such).

> In that case, try the modification below [snip]

Thanks, that worked nicely for the ABC/BCA/CAB version. I also modified the
macro from Chris by sprinkling some instances of "scale 1/3", after which it
worked well for image_maps.

Gratefully yours,

Rick Mabry

Post a reply to this message

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.

Post a reply to this message

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