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