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

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

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

Ken <tyl### [at] pacbellnet> 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

Ron Parker wrote:

> 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?

There is nothing wrong with the portable way per se (Ah peotry). I have
however have become inspired by Chris Young's proposal to incorporate
patches into the official version and if people rely on only the portable
coding methods he may never get an itch to add similar patterns in the
future. For that matter are there not a handful of custom patterns in
the SP simply because they tickled someones fancy ?
 
> >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.

We commend you for your efforts in this regard and encourage you to continue
to do so but how many of the total number of Pov users are you really reaching
with these generous donations ? Again on my little soap box if you at least
posted the code for these unique patterns that you develope in one of the
scene-files groups with an appropriate header you would probably reach a
greater number of users with them. Buried in a reply to a thread like this
few will ever be able to find your code again even with a good search routine.
 
> >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.

Actually that was more of a dig in Warps direction Papa "leather neck" 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

Nieminen Juha wrote:

>   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 ;)

Again let me say that what is easy for you to figure out may be an
impossibilty for someone with lesser abilities than your own. You
have an university education, some programming abilities, and your
grasp of math is on orders better than my own. This puts you in an
enviable position that not every user can acheive even with the best
of intentions. I am also not advocating adding "every" pattern written
but some of the more trick patterns that are developed would make
welcome additions to the program barring any problems with breaking
an existing function.

-- 
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

On Wed, 01 Sep 1999 07:56:43 -0700, Ken wrote:

>There is nothing wrong with the portable way per se (Ah peotry). I have
>however have become inspired by Chris Young's proposal to incorporate
>patches into the official version and if people rely on only the portable
>coding methods he may never get an itch to add similar patterns in the
>future. For that matter are there not a handful of custom patterns in
>the SP simply because they tickled someones fancy ?

The only pigment mods I can think of in the SP are the new crackle stuff 
(because they tickled my fancy, specifically, and couldn't be done any other 
way) and the function-based pigments from the isosurface patch.  It's an 
area that hasn't really been explored to the extent that it probably should
be.  Again, let me be the first to say that I have nothing against patches 
in general, and I'll even incorporate this patch into the superpatch if the 
author so desires. I just like to provide an alternative where possible for 
those people who, like the previously-unenlightened Ken, refuse to use or 
just simply can't use custom patches.  Besides, writing that kind of ugly
POV script is actually FUN.

Actually, there is a difference between both of the POV-script-only 
solutions and the patch solution, which is probably important to most
people.  When used with arbitrary pigments, the POV-script-only versions
repeat the same part of the pigment over and over.  In the case of my
hextiles and triangle versions, they also have reflective symmetry in 
odd places.  I assume the patch versions do not.

>Again on my little soap box if you at least
>posted the code for these unique patterns that you develope in one of the
>scene-files groups with an appropriate header you would probably reach a
>greater number of users with them. Buried in a reply to a thread like this
>few will ever be able to find your code again even with a good search routine.

True.  I should probably do that.  Usually, I put these little gems on
Twyst's macroscope if there's a positive response to them, but I must admit 
that I haven't done that with the hex tiles pattern either.  Maybe I'll 
polish up my collection of patterns (stars, hextiles, triangles, square 
tiles, and the unwritten-but-obvious triangle tiles) and put them online 
somewhere.  I suspect if I did that before releasing the next superpatch, 
though, I'd probably be lynched for wasting that valuable spare time. :)

Post a reply to this message

I will hurry up and send my unfinished patch work to you, if you want.
The transparency patch isn't fully implemented, only the blurring
portion, but everything else should work. I haven't done much work on it
lately...I need to get back to it.

Post a reply to this message

On Wed, 01 Sep 1999 13:04:23 -0500, Chris Huff wrote:
>I will hurry up and send my unfinished patch work to you, if you want.
>The transparency patch isn't fully implemented, only the blurring
>portion, but everything else should work. I haven't done much work on it
>lately...I need to get back to it.

There's no rush; there's always another superpatch around the corner.
I prefer complete patches due to the difficulty of merging multiple
versions of the same patch.  Maybe when I start using version control
that will change.

Post a reply to this message

Ron Parker wrote:

> On Wed, 01 Sep 1999 13:04:23 -0500, Chris Huff wrote:
> >I will hurry up and send my unfinished patch work to you, if you want.
> >The transparency patch isn't fully implemented, only the blurring
> >portion, but everything else should work. I haven't done much work on it
> >lately...I need to get back to it.
>
> There's no rush; there's always another superpatch around the corner.
> I prefer complete patches due to the difficulty of merging multiple
> versions of the same patch.  Maybe when I start using version control
> that will change.

What? You're not on things yet?
I thought you had gotten going on CVS, so I laid off of you regarding using
RCS. Guess I have to crack the whip a little :-)

Source control: just use it.

:-)

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message