![](/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) |
"J. Grimbert" wrote:
>
> I finally made my first patch in POV:
> I added two patterns similar to the HEXAGON/CHECKER
> one that fills the x-y plane with squares, alterning four "colours"
> and another that fills the x-y plane with triangle, using six "colours".
>
> From the mathematical point of view, I felt they were missing from the
> very beginning
> (at least since HEXAGON has been added).
>
> The patch can be retrieved at:
> http://www.altern.org/grimbert/pov/index.html
>
> --
> J. Grimbert
> http://www.altern.org/grimbert/
Despite the comments from the other two skeptics in this thread I like the
idea of these two new patterns. I have one question though about the third
image on your page. If you look at the triangle pattern you can see visible
"cracking" in some places. Is this simply a matter of not enough AA when
you rendered the image or perhaps a jpg problem ?
--
Ken Tyler
See my 850+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
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) |
Ron Parker wrote:
> #include "colors.inc"
> #macro TriTiles( PigArray )
> #local hexBlock=pigment { radial pigment_map{
> #local i=0; #while (i<6)[i/6 PigArray[i]]
> [(i+1)/6 PigArray[i]] #local i=i+1; #end}}
> radial pigment_map {#local i=1; #while (i<3)
> [i/3 hexBlock translate vrotate(x,(120*i-60)*y)]
> [i/3 hexBlock translate vrotate(x,(120*i+60)*y)]
> #local i=i+1; #end } warp {repeat x flip x }
> warp {repeat sqrt(3)*z} scale .5
> #end
Now that is what I call perfectly indented Pov script.
Hooray Mr. Parker !!!
--
Ken Tyler
See my 850+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
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) |
On Tue, 31 Aug 1999 03:18:37 -0700, Ken wrote:
>Now that is what I call perfectly indented Pov script.
>
>Hooray Mr. Parker !!!
The original version of this code even had comments that said
something about "Tyler Syndrome" and mused about whether it
might be contagious. :)
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) |
Ken wrote:
>
>
> Despite the comments from the other two skeptics in this thread I like the
> idea of these two new patterns. I have one question though about the third
> image on your page. If you look at the triangle pattern you can see visible
> "cracking" in some places. Is this simply a matter of not enough AA when
> you rendered the image or perhaps a jpg problem ?
>
Alas, none of these. The current images in the page were made with PSP.
(after the generation of the hexagon with a vector program...). Then a
copy with
transparent paper was done around the initial. The crack is due to the
my bad
precision of the hexagon... The square was easier to do...
I should update the images in a day or two with real povray rendered
pictures,
but my tests image were really too much bigger for anything worth.
Thanks for the interest.
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) |
J. Grimbert wrote in message <37CB67A5.A06CDF98@atos-group.com>...
<snip>
>Taking your argument to extrem, you should remove the sphere and box
>objects, as they
>are specialisation of the superellipsoid, and it also seems that the
>cone can be removed
>as also a specialisation of some quadric or quartic (or was it a more
>complex polynomial
>equation ...).
>
>My motto is: KISS (Keep It Simple...)
Please, let's not have this conversation again (see 'A modest proposal' in
p.p)
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) |
"J. Grimbert" wrote:
>
> Ken wrote:
> >
>
> >
> > Despite the comments from the other two skeptics in this thread I like the
> > idea of these two new patterns. I have one question though about the third
> > image on your page. If you look at the triangle pattern you can see visible
> > "cracking" in some places. Is this simply a matter of not enough AA when
> > you rendered the image or perhaps a jpg problem ?
> >
>
> Alas, none of these. The current images in the page were made with PSP.
> (after the generation of the hexagon with a vector program...). Then a
> copy with
> transparent paper was done around the initial. The crack is due to the
> my bad
> precision of the hexagon... The square was easier to do...
>
> I should update the images in a day or two with real povray rendered
> pictures,
This is done now.
In the meantime I also correct a small bug in the new triangular which
was drawing a visible line at x=0... Now it works perfectly, and quicker
than
the complicated _map ( 18 s instead of 26 s, without AA ).
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) |
On Tue, 31 Aug 1999 03:12:35 -0700, Ken wrote:
>Despite the comments from the other two skeptics in this thread I like the
>idea of these two new patterns.
As you all should know by now, I love custom patches. I also understand
why one would implement a new pattern as a patch instead of as a macro,
because it will invariably render more quickly. But when you do that,
you sacrifice portability you didn't have to sacrifice in the name of a
relatively small increase in speed.
By the way, Warp, the squares could also be done with a repeat warp,
which would eliminate the problem that happens with the gradient version
near zero.
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) |
Ron Parker wrote:
>
> On Tue, 31 Aug 1999 03:12:35 -0700, Ken wrote:
>
> >Despite the comments from the other two skeptics in this thread I like the
> >idea of these two new patterns.
>
> As you all should know by now, I love custom patches. I also understand
> why one would implement a new pattern as a patch instead of as a macro,
> because it will invariably render more quickly. But when you do that,
> you sacrifice portability you didn't have to sacrifice in the name of a
> relatively small increase in speed.
Why should portability be sacrificed if it is written in the same language
at the core program is ? I could see it an issue if it was written for the
Mac or one of the other hard to port to systems like UNIX's but for a simple
C language patch it should be no problem. ( I am guilty of not verifying
that this particular patch was written in C but bear in mind your comment
sounded like a blanket statement).
Regardless the fact the you and Warp, both advanced users, can figure out
a somewhat complicated method of rendering this pattern, does not make
it intuitively obvious to others and I doubt less than 10% of all Pov
users could do it themselves. Patches are for more than mere convenience
of parsing speed and memory effeciency.
> By the way, Warp, the squares could also be done with a repeat warp,
> which would eliminate the problem that happens with the gradient version
> near zero.
Yeah warp listen to papa :)
--
Ken Tyler
See my 850+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
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) |
On Wed, 01 Sep 1999 07:02:39 -0700, Ken wrote:
>Why should portability be sacrificed if it is written in the same language
>at the core program is ?
For the same reason that John VanSickle won't put UV support in the
subdivision suite until it's provided in an official version: a scene
file that uses that pattern won't work in the official POV. If it's
an effect that can be accomplished by other means, and if you plan to
share your scene file, why not use the portable way?
>Regardless the fact the you and Warp, both advanced users, can figure out
>a somewhat complicated method of rendering this pattern, does not make
>it intuitively obvious to others and I doubt less than 10% of all Pov
>users could do it themselves.
True. Which is why instead of saying "It can be done" I actually spent
a few minutes to do it and share it with the world, as did Warp.
>Yeah warp listen to papa :)
Does that make me Papa Parker, Unka Ken? Others might have felt this
comment was just a bit patronizing; fortunately, I'm rather thick-skinned.
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) |
Ken <tyl### [at] pacbell net> wrote:
: Regardless the fact the you and Warp, both advanced users, can figure out
: a somewhat complicated method of rendering this pattern, does not make
: it intuitively obvious to others and I doubt less than 10% of all Pov
: users could do it themselves. Patches are for more than mere convenience
: of parsing speed and memory effeciency.
If we add a patch to povray every time someone wants his own pattern
type, povray would grow wildly and there would be a lot more maintenance
problems.
If someone doesn't know how to get the desired pattern, he sould learn
how to use povray ;)
:> By the way, Warp, the squares could also be done with a repeat warp,
:> which would eliminate the problem that happens with the gradient version
:> near zero.
: Yeah warp listen to papa :)
Ok, here it is. This should be faster than the gradient-version:
#macro Squares(p1,p2,p3,p4)
checker
pigment
{ checker pigment { p1 }, pigment { p2 }
scale <.5,1,1>
}
pigment
{ checker pigment { p4 }, pigment { p3 }
scale <.5,1,1>
}
scale <1,.5,1>*2
warp { repeat 2*x }
#end
#declare P1=pigment { rgb x }
#declare P2=pigment { wood turbulence .5 scale .4 }
#declare P3=pigment { granite scale .5 }
#declare P4=pigment { rgb z }
camera { location -z*7 look_at 0 }
plane
{ -z,0 pigment { Squares(P1,P2,P3,P4) }
finish { ambient 1 }
}
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |