 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The checker pattern gives:
ABABABAB
BABABABA
ABABABAB
BABABABA
But what is the best way to obtain
ABCABCABCABC
BCABCABCABCA
CABCABCABCAB
ABCABCABCABC
BCABCABCABCA
and other general checker patterns? Must these be done "by hand" using
loops?
Thanks,
Rick Mabry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rick Mabry <rma### [at] softdisk com> wrote:
> The checker pattern gives:
>
> ABABABAB
> BABABABA
> ABABABAB
> BABABABA
>
> But what is the best way to obtain
>
> ABCABCABCABC
> BCABCABCABCA
> CABCABCABCAB
> ABCABCABCABC
> BCABCABCABCA
>
> and other general checker patterns? Must these be done "by hand" using
> loops?
POV-Ray includes the hexagon pattern, which tiles three colours, pigments,
textures, etc. using (duh!) hexagons. If you want other tiled patterns you
should be able to use repeat warps (best for flat colours) and/or nested
patterns, e.g. a macro to create the tiling pattern you've shown above:
#macro checker_pigment (Pigment1, Pigment2, Pigment3)
gradient y pigment_map {
[1/3 gradient x pigment_map {
[1/3 Pigment1] [1/3 Pigment2] [2/3 Pigment2] [2/3 Pigment3]}
]
[1/3 gradient x pigment_map {
[1/3 Pigment3] [1/3 Pigment1] [2/3 Pigment1] [2/3 Pigment2]}
]
[2/3 gradient x pigment_map {
[1/3 Pigment3] [1/3 Pigment1] [2/3 Pigment1] [2/3 Pigment2]}
]
[2/3 gradient x pigment_map {
[1/3 Pigment2] [1/3 Pigment3] [2/3 Pigment3] [2/3 Pigment1]}
]
}
scale 3
#end
plane {z, 20
pigment {checker_pigment (rgb x, rgb y, rgb z) translate -100}
finish {ambient 1 diffuse 0}
}
This macro can be easily modified for tiling complete textures, and extended
into the third dimension (z) if needed. 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 15 Nov 2000 16:42:06 +1000, "Chris Colefax"
<chr### [at] tagpovrayorg> wrote:
>This macro can be easily modified for tiling complete textures, and extended
>into the third dimension (z) if needed. 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.
How about using marble with ramp_wave?
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 15 Nov 2000 16:42:06 +1000, Chris Colefax wrote:
>This macro can be easily modified for tiling complete textures, and extended
>into the third dimension (z) if needed. 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.
Or using a repeat warp, which is how I would have done it.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 15 Nov 2000 09:32:07 -0500, Ron Parker wrote:
>On Wed, 15 Nov 2000 16:42:06 +1000, Chris Colefax wrote:
>>This macro can be easily modified for tiling complete textures, and extended
>>into the third dimension (z) if needed. 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.
>
>Or using a repeat warp, which is how I would have done it.
That is,
#macro checker_pigment (Pigment1, Pigment2, Pigment3)
gradient x pigment_map {
[1/3 Pigment1] [1/3 Pigment2] [2/3 Pigment2] [2/3 Pigment3]}
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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).
Rick
"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On 15 Nov 2000 09:32:07 -0500, Ron Parker wrote:
> >On Wed, 15 Nov 2000 16:42:06 +1000, Chris Colefax wrote:
> >>This macro can be easily modified for tiling complete textures, and
extended
> >>into the third dimension (z) if needed. 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.
> >
> >Or using a repeat warp, which is how I would have done it.
>
> That is,
>
> #macro checker_pigment (Pigment1, Pigment2, Pigment3)
> gradient x pigment_map {
> [1/3 Pigment1] [1/3 Pigment2] [2/3 Pigment2] [2/3 Pigment3]}
> warp {repeat x}
> warp {repeat y offset 1/3*x}
> scale <3,1,1>
> #end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Something seems strange in the documentation. In the section "Pigment Maps
and Pigment Lists," there is the statement:
`You may not use pigment_map or individual pigments with an image_map. See
section "Texture Maps" for an alternative way to do this.'
Even though image_maps didn't give me just what I wanted (yet), an image was
rendered using the image_maps I provided.
Rick.
"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> #macro checker_pigment (Pigment1, Pigment2, Pigment3)
> gradient x pigment_map {
> [1/3 Pigment1] [1/3 Pigment2] [2/3 Pigment2] [2/3 Pigment3]}
> warp {repeat x}
> warp {repeat y offset 1/3*x}
> scale <3,1,1>
> #end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Chris Colefax
Subject: Re: gradient symmetry (was checkered passed)
Date: 17 Nov 2000 02:18:02
Message: <3a14dbaa@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A15BCBE.762D9840@faricy.net>, David Fontaine
<dav### [at] faricynet> wrote:
> Rick Mabry wrote:
>
> > ABCABCABCABC
> > BCABCABCABCA
> > CABCABCABCAB
> > ABCABCABCABC
> > BCABCABCABCA
>
> Eww, this is striped! If ya want three colors I'd say go with hexagon.
Umm, hexagon is, well, hexagonal. And both hexagon and the ordinary
checkers are "striped". It is very possible he *wants* a striped pattern
of squares with more than one color.
BTW, I have been thinking about some possible new patterns:
random_checkers, random_hexagons, etc...they would take a list of any
number of items and choose one of them for each tile. Also, replace the
old "tiles" pattern(which isn't used any more) with a new one that lets
you specify any number of items and the offset for each row.
What do you think?
--
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:
> Umm, hexagon is, well, hexagonal. And both hexagon and the ordinary
> checkers are "striped". It is very possible he *wants* a striped pattern
> of squares with more than one color.
Yes it is. I was just saying eww IMHO. :)
Hexagon has no two cells of the same color touching, even just by a corner.
As for regular checker, it sort of has diagonal stripes, but those stripes
are not isolated so they don't stick out. :)
> BTW, I have been thinking about some possible new patterns:
> random_checkers, random_hexagons, etc...they would take a list of any
> number of items and choose one of them for each tile. Also, replace the
> old "tiles" pattern(which isn't used any more) with a new one that lets
> you specify any number of items and the offset for each row.
> What do you think?
Sure
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote in message ...
> > [ grayscale problem ]
> I have changed this to use (R+G+B)/3 in my version.
> > [ function request ]
> And just finished doing it.
> > [ discusion from p.u-p ]
> You could also use the convert_color()
thanks for your effort :-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 17 Nov 2000 18:40:42 -0500, Chris Huff wrote:
>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.
For pure grayscale values (R==G==B) the results are identical.
E.g.:
0.33*0.297 + 0.33*0.589 + 0.33*0.114 == 0.33
(0.33+0.33+0.33)/3 = 0.33
I suggest leaving GREY_SCALE() as it is.
hp
--
_ | Peter J. Holzer | Perl ist der geglückte Versuch, einen
|_|_) | Sysadmin WSR | braindump direkt ausführbar zu machen.
| | | hjp### [at] wsracat | -- Lutz Donnerhacke in dasr.
__/ | http://www.hjp.at/ |
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] tealhhjpat>,
hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:
> For pure grayscale values (R==G==B) the results are identical.
> E.g.:
>
> 0.33*0.297 + 0.33*0.589 + 0.33*0.114 == 0.33
Correct, but I think people will expect rgb < 0.5, 0, 0> to have the
same effect as rgb < 0, 0.5, 0>...
However, I will change it back and just leave my code in there in case
someone wants to use it later.
> I suggest leaving GREY_SCALE() as it is.
GREY_SCALE() was not modified, only the pigment_pattern() 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 19 Nov 2000 18:00:20 -0500, Chris Huff wrote:
>In article <slr### [at] tealhhjpat>,
>hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:
>
>> For pure grayscale values (R==G==B) the results are identical.
>> E.g.:
>>
>> 0.33*0.297 + 0.33*0.589 + 0.33*0.114 == 0.33
>
>Correct, but I think people will expect rgb < 0.5, 0, 0> to have the
>same effect as rgb < 0, 0.5, 0>...
I wouldn't. But maybe I have used a greyscale monitor too long.
hp
--
_ | Peter J. Holzer | Perl ist der geglückte Versuch, einen
|_|_) | Sysadmin WSR | braindump direkt ausführbar zu machen.
| | | hjp### [at] wsracat | -- Lutz Donnerhacke in dasr.
__/ | http://www.hjp.at/ |
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
> On Fri, 17 Nov 2000 18:40:42 -0500, Chris Huff wrote:
>>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.
> For pure grayscale values (R==G==B) the results are identical.
> E.g.:
> 0.33*0.297 + 0.33*0.589 + 0.33*0.114 == 0.33
> (0.33+0.33+0.33)/3 = 0.33
This is because the coefficients sum to 1. Any set of coefficients that sum
to 1 will work if you're using the same value for R, G, and B. It's when
they're not that you need something else. Consider colors <1,1,0> and
<1,0,1> By 1/3rds these are the same grey (.667), but by the GREY_SCALE()
macro, they're not. I prefer the latter, because Yellow (the first color)
and Magenta (the second) aren't quite the same in Grey (Yellow is brighter.
This is because of how our eyes perceive colors and light)
I'm assuming the values of the macro were chosen based on some real world
testing, but I could be wrong. In any case, they give good results.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
