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/

Post a reply to this message

J. Grimbert <jgr### [at] atos-groupcom> 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"

  At least this one is easy to achieve without needing to patch povray.
Something like:

#macro SquarePattern(pigm1,pigm2,pigm3,pigm4)
  #local Row1=
    pigment
    { gradient x pigment_map
      { [0 pigm1]
        [.5 pigm1]
        [.5 pigm2]
        [1 pigm2]
      }
    }
  #local Row2=
    pigment
    { gradient x pigment_map
      { [0 pigm3]
        [.5 pigm3]
        [.5 pigm4]
        [1 pigm4]
      }
    }
  gradient y pigment_map
  { [0 Row1]
    [.5 Row1]
    [.5 Row2]
    [1 Row2]
  }
  scale 2
#end

#declare P1=pigment { rgb z }
#declare P2=pigment { marble turbulence .5 scale .3 }
#declare P3=pigment { granite scale .2 }
#declare P4=pigment { rgb y }
camera { location -z*5 look_at 0 }
plane
{ -z,0
  pigment { SquarePattern(P1,P2,P3,P4) translate -10 }
  finish { ambient 1 }
}


  My motto is: Why do something with an external program or patching
povray, if you can do it with povray itself without noticeable performance
loss?

: and another that fills the x-y plane with triangle, using six "colours".

  This one is not as trivial as the previous one, but I'm sure it's also
possible with pigment_maps.

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

On 30 Aug 1999 11:18:50 -0400, Nieminen Juha wrote:
>: and another that fills the x-y plane with triangle, using six "colours".
>
>  This one is not as trivial as the previous one, but I'm sure it's also
>possible with pigment_maps.

Here's one implementation, derived from my previous hexagons-with-mortar 
pattern:

#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
                              
#declare MyPigArray=array[6] {
  pigment {color Red}
  pigment {color Yellow}
  pigment {color Green}
  pigment {color Cyan}
  pigment {color Blue}
  pigment {color Magenta}
}                              
                              
plane { y,0 pigment {TriTiles(MyPigArray)}}         
camera { location 12*y sky z look_at 0 }
light_source { 6*y rgb 1}

Post a reply to this message

Nieminen Juha wrote:
> 
> J. Grimbert <jgr### [at] atos-groupcom> 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"
> 

Well, in fact it is rather the x-z plane (but that does not change a lot
of thing)

>   At least this one is easy to achieve without needing to patch povray.
> Something like:
> 

Well, your code is bogus for infinite plane: just step the camera back a 
little step (-50 instead of -5) and you will see the mirrorring of
gradient !

> 
>   My motto is: Why do something with an external program or patching
> povray, if you can do it with povray itself without noticeable performance
> loss?

Agreed, that's why I usually refute evolution asking for #for and other
syntaxic
sugar.
Nevertheless, a point for me: The rendering of with your code take (with
AA=0.3) 
235 s while mine only 161 s (sample per pixel was 2.49 for your, 2.64
for mine, 
with simple pigments rgb<1,0,0>,rgb<1,1,0>, rgb<0,1,1> and rgb<0,0,1>)
The memory consumption was also less with my code, about 1.5k over 92k
The image were not identical because of the gradient mirroring and the
ordering of 
pigments (which may explain the different sample/pixels).

Either way you take it, as a 45% more time or 31% quicker, I do not
think the difference
is small. 

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

--

Post a reply to this message

"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

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

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

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

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

"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

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

On Wed, 01 Sep 1999 11:48:56 -0700, Jon A. Cruz wrote:
>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 :-)

Eh, well, my Linux box that was going to run the CVS server died, then the 
network card had problems... I'll likely give it another try this weekend.
CVS is obviously a better answer than RCS for this specific application,
because of all the branching that's going on.

Post a reply to this message

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

  Man, you are making me to be ashamed of myself...

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

Nieminen Juha wrote:
>   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 }
> }
>

I won't continue the competition for speed nor really test this,
 but it seems to me that checker is a 3D pattern, moving
in the three axes... 
Or I just misinterpret the warp... I think  you would need more
warp statement for y and z !
I'm far too incompetent with patterns included in other patterns
(I'm at a complete loose to understand where to apply correctly
a translate or scale to a pattern to do exactly what I think),
but does the warp repetition only apply to the outside pattern or
also at the computation of the internal pattern ?
If the second, then a paving of wood tiles would really be boring
and unrealistic. (but there is also this reset_child thing to look
at)....

For my patch, it is available and everybody is free to take it.
I would be please to see it in SP (or even better in the official!),
but I do not want to bother anyone and delay any releases...
(I would dreams simply of a 3.1g based SP with all the UV and photon,
and iso things...)

Post a reply to this message

Nieminen Juha wrote:
> 
> Ken <tyl### [at] pacbellnet> wrote:
> : 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.
> 
>   Man, you are making me to be ashamed of myself...

:)

  Fortunately what I lack in formal education I make up for with dogged
determination and persistence. The uneducated may seem inherently stupid
but they are clever and resourceful and bear considerable watching.

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

Well, this reminds me recent discussion in c.g.r.r., where discussion
about hard-coded textures vs. "coded shaders" took place. Perhaps
someone could create patch for texture plugins: user creates it's own
texture with script, then specifies it as object texture and renders.
Best would be, if texture is in Renderman format (i.e. Renderman
shader). Any takers?

Post a reply to this message

Vahur Krouverk wrote:

> Well, this reminds me recent discussion in c.g.r.r., where discussion
> about hard-coded textures vs. "coded shaders" took place. Perhaps
> someone could create patch for texture plugins: user creates it's own
> texture with script, then specifies it as object texture and renders.
> Best would be, if texture is in Renderman format (i.e. Renderman
> shader). Any takers?

http://www.cinenet.net/~mercier/bigpict.html

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

Ken wrote:
> 
> Vahur Krouverk wrote:
> 
> > Well, this reminds me recent discussion in c.g.r.r., where discussion
> > about hard-coded textures vs. "coded shaders" took place. Perhaps
> > someone could create patch for texture plugins: user creates it's own
> > texture with script, then specifies it as object texture and renders.
> > Best would be, if texture is in Renderman format (i.e. Renderman
> > shader). Any takers?
> 
> http://www.cinenet.net/~mercier/bigpict.html
> 

Well, indeed it is done already, but this page seems to be really old
and seems like he haven't published source code. Does anyone have
contact with him? 
At least this page shows, that shaders in POVRay are possible...

Post a reply to this message

Vahur Krouverk wrote:

> Well, indeed it is done already, but this page seems to be really old
> and seems like he haven't published source code. Does anyone have
> contact with him?
> At least this page shows, that shaders in POVRay are possible...

I have no more data than what I provided. Did you search the site ?
This was allegedly accomplished with a Pov v2.2 patch and the source
should be available somewhere.

-- 
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 Thu, 02 Sep 1999 09:50:26 -0700, Ken wrote:
>
>
>Vahur Krouverk wrote:
>
>> Well, indeed it is done already, but this page seems to be really old
>> and seems like he haven't published source code. Does anyone have
>> contact with him?
>> At least this page shows, that shaders in POVRay are possible...
>
>I have no more data than what I provided. Did you search the site ?
>This was allegedly accomplished with a Pov v2.2 patch and the source
>should be available somewhere.

The source was on the old ftp.povray.org, and is still on ftp.cdrom.com
in /pub/povray somewhere.  Nobody's ever gotten it to compile and run
properly, and it's not been ported to 3.x.  It's also got some severe
limitations, among them the fact that it doesn't support uv mapping and
the derivative stuff from SL.  Those things are both fairly vital, so
the average SL texture from the net wouldn't be usable.

However, with Nathan's UV patch (especially if we all pitched in and
extended it to the objects that still need it) and the information in
the '99 SIGGRAPH paper on tracing Ray Differentials, it could almost
work.  It's still a lot of work, and you'd probably want to ignore
POVMAN and just start over.

Other suggestions have included creating a plugin interface that
allows for compiled shaders in shared libraries, or in Java classes.
Unfortunately, neither of those solutions scales to every platform
POV supports (DOS has no Java, apparently, and definitely no shared
library support.)  In addition, of course, such an interface would
violate POVLEGAL so it couldn't be distributed unofficially.

Post a reply to this message

Ron Parker wrote:
> 
> Other suggestions have included creating a plugin interface that
> allows for compiled shaders in shared libraries, or in Java classes.
> Unfortunately, neither of those solutions scales to every platform
> POV supports (DOS has no Java, apparently, and definitely no shared
> library support.)  In addition, of course, such an interface would
> violate POVLEGAL so it couldn't be distributed unofficially.

Well, about compiled shaders: from the c.g.r.r. thread it could be seen,
that compiled shaders are 25% faster than "interpreted shaders". Of
course this result comes from folks in Pixar, but I don't think that it
will be much lower, when mere mortals try to implement it. Seems
negotiable to me.

Post a reply to this message

Ron Parker <par### [at] fwicom> wrote:
: Other suggestions have included creating a plugin interface that
: allows for compiled shaders in shared libraries, or in Java classes.
: Unfortunately, neither of those solutions scales to every platform
: POV supports (DOS has no Java, apparently, and definitely no shared
: library support.)

  Also shared libraries (which I suppose is compiled code) of one platform
will not work in another.

  The programmable shaders are an interesting feature, though. There still
are things that are impossible, or at least extremely hard and/or slow to
make with the current textures. The solution so far has been to add more
and more pattern types to the povray core. This is not a very good solution
in the long run.
  This effect can be seen in Moray. Since it lacks a scripting language,
each time you want to do something not directly supported you have to
make/download a plugin that does it. If you want to do something slightly
different you have to make a new plugin or modify an existing plugin.
This results in megabytes and more megabytes of plugins in a chaotic
jungle of little files. If this continues enough, Moray and all its plugins
will take Gigabytes of space with all the resource and maintenance problems.
  A powerful scripting language would take some tens of kilobytes of code
and no amount of plugins would be enough to achieve the same functionality.

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

Nieminen Juha wrote:
> 
> Ron Parker <par### [at] fwicom> wrote:
> : Other suggestions have included creating a plugin interface that
> : allows for compiled shaders in shared libraries, or in Java classes.
> : Unfortunately, neither of those solutions scales to every platform
> : POV supports (DOS has no Java, apparently, and definitely no shared
> : library support.)
> 
>   Also shared libraries (which I suppose is compiled code) of one platform
> will not work in another.
> 
Yes, it is compiled, but it is more like Java's bytecode or some
assembler. So portability will not be an issue.

Post a reply to this message

Ron Parker wrote:
> 
> On Thu, 02 Sep 1999 09:50:26 -0700, Ken wrote:
> >
> >
> >Vahur Krouverk wrote:
> >
> >> Well, indeed it is done already, but this page seems to be really old
> >> and seems like he haven't published source code. Does anyone have
> >> contact with him?
> >> At least this page shows, that shaders in POVRay are possible...
> >
> >I have no more data than what I provided. Did you search the site ?
> >This was allegedly accomplished with a Pov v2.2 patch and the source
> >should be available somewhere.
> 
> The source was on the old ftp.povray.org, and is still on ftp.cdrom.com
> in /pub/povray somewhere.  Nobody's ever gotten it to compile and run
> properly, and it's not been ported to 3.x.  It's also got some severe
> limitations, among them the fact that it doesn't support uv mapping and
> the derivative stuff from SL.  Those things are both fairly vital, so
> the average SL texture from the net wouldn't be usable.
> 
> However, with Nathan's UV patch (especially if we all pitched in and
> extended it to the objects that still need it) and the information in
> the '99 SIGGRAPH paper on tracing Ray Differentials, it could almost
> work.  It's still a lot of work, and you'd probably want to ignore
> POVMAN and just start over.
> 
Can you point out, in which paper it was? How can I see it? Can You send
me a copy or if it is not possible (due to copyright), then how can I
purchase this paper (preferably online, assuming that it does not cost
me arm and leg). I'm not saying, that I will start implementing of
shader, I'm just curious. Although...

Post a reply to this message

On Thu, 14 Oct 1999 21:31:39 +0300, Vahur Krouverk wrote:
>Ron Parker wrote:
>> However, with Nathan's UV patch (especially if we all pitched in and
>> extended it to the objects that still need it) and the information in
>> the '99 SIGGRAPH paper on tracing Ray Differentials, it could almost
>> work.  It's still a lot of work, and you'd probably want to ignore
>> POVMAN and just start over.
>> 
>Can you point out, in which paper it was? How can I see it? Can You send
>me a copy or if it is not possible (due to copyright), then how can I
>purchase this paper (preferably online, assuming that it does not cost
>me arm and leg). I'm not saying, that I will start implementing of
>shader, I'm just curious. Although...

http://www-graphics.stanford.edu/papers/trd/

Post a reply to this message