OK, so this is the patched POV newsgroup.  But let me share my vision
anyway...

  The great thing about POV is that so many people can contribute to it's
making.  I do 3D professionaly, and I know that if there's some feature that
I want but POV doesn't support, I have the possibility of just making my own
patch.  Total control.

   An outgrowth of this outlook is an idea that I had for the POV 4 rewrite:
instead of hard-coding all the routines for the different objects (box,
mesh, whatever) why not instead give it the capability to work with
dynamically loaded plugins?   The final release would consist of core
packages, plus a set of standard plugins.  Basic geometric shapes would be
box.dll/box.o, sphere.dll/sphere.o, plane.dll/plane.o, and so on.  If
someone came out with a new object (nurbs, for example), they wouldn't have
to patch the entire POV code.  Just drop nurbs.dll into the appropriate
directory, and *bam* it's there.  This would be _so_ cool.  So _very_ cool.


Joseph



--
------------------------------------------------------------------
WilTech IT Services - www.wiltech.net - (541) 929-7637

"God did this so that men would seek him and perhaps reach
 out for him and find him, though he is not far from each one
of us. 'For in him we live and move and have our being.' "

Post a reply to this message

On Thu, 20 Sep 2001 11:43:21 -0700, Joseph Sullivan wrote:
>OK, so this is the patched POV newsgroup.  But let me share my vision
>anyway...
>
>  The great thing about POV is that so many people can contribute to it's
>making.  I do 3D professionaly, and I know that if there's some feature that
>I want but POV doesn't support, I have the possibility of just making my own
>patch.  Total control.
>
>   An outgrowth of this outlook is an idea that I had for the POV 4 rewrite:
>instead of hard-coding all the routines for the different objects (box,
>mesh, whatever) why not instead give it the capability to work with
>dynamically loaded plugins?   The final release would consist of core
>packages, plus a set of standard plugins.  Basic geometric shapes would be
>box.dll/box.o, sphere.dll/sphere.o, plane.dll/plane.o, and so on.  If
>someone came out with a new object (nurbs, for example), they wouldn't have
>to patch the entire POV code.  Just drop nurbs.dll into the appropriate
>directory, and *bam* it's there.  This would be _so_ cool.  So _very_ cool.

Also very hard to make cross-platform.  But we're getting there.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Also very hard to make cross-platform.  But we're getting there.

  As you say, it's not possible to make it cross-platform. Not that *AND*
being efficient at the same time.
  A platform-independent solution would be inevitably a lot slower than
having highly optimized code for the platform.

  One of the main fundamental requisites of a raytracer is speed. Let's not
start compromising that.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Ron Parker wrote:

> Also very hard to make cross-platform.  But we're getting there.

How many plaforms are you going to support? Anything Windows related has 
.dll's, anything UNIX related has .so's and I think that anything Mac 
related has similar mechanisms. By the way, VMS had shared libraries in 
the late 1980's... The ONLY platform I know for sure that has nothing 
like these tools is MS-DOS!

Bye

Alessandro Coppo

Post a reply to this message

Alessandro Coppo <a.c### [at] iolit> wrote:
: anything UNIX related has .so's

  But there are several computers out there which use unix. An .so file for
one system can't be used in another. There should be pre-compiled dynamic
libraries for Windows, PC Linux, Sparc Linux, Alpha Linux, Mac Linux, FreeBSD,
NetBSD, OpenBSD, MacOS (many different versions), Sparc Solaris, PC Solaris,
Digital Unix, OS/2... The list is endless.

  And what's the point anyways? I really don't see such a big advantage of
this. It just introduces really big maintenance and incompatibility problems.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

On Fri, 21 Sep 2001 09:25:15 +0200, Alessandro Coppo wrote:
>Ron Parker wrote:
>
>> Also very hard to make cross-platform.  But we're getting there.
>
>How many plaforms are you going to support? Anything Windows related has 
>.dll's, anything UNIX related has .so's and I think that anything Mac 
>related has similar mechanisms. By the way, VMS had shared libraries in 
>the late 1980's... The ONLY platform I know for sure that has nothing 
>like these tools is MS-DOS!

The problem isn't how many platforms we're going to support, it's how to
make sure that every plugin is available for every platform when the
plugins are being developed and distributed by random people on the 'net.
It's not much good to be able to use POV on your Mac if you can't get
the newest whiz-bang plugin that's needed to render every tenth scene
in povray.text.scene-files.  That leads to fragmentation of the language
and eventually something that looks a lot like forking into lots of little
OS-dependent versions of POV.

Don't get me wrong.  I like the plugin idea.  I used to be all for it.  But
then someone told me what I'm telling you (though probably more eloquently)
and I changed my mind about the whole thing.  After that, I got dragged 
kicking and screaming into managing the Unix port while our Unix guy deals
with an extreme bout of Real Life, and I became even more convinced that
if we added plugins, the only plugins you'd ever see would be distributed
as binary-only Windows DLLs that only work on a Pentium IV running at 2GHz
or higher.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

Warp wrote:
> 
> Alessandro Coppo <a.c### [at] iolit> wrote:
> : anything UNIX related has .so's
> 
>   But there are several computers out there which use unix. An .so file for
> one system can't be used in another. There should be pre-compiled dynamic
> libraries for Windows, PC Linux, Sparc Linux, Alpha Linux, Mac Linux, FreeBSD,
> NetBSD, OpenBSD, MacOS (many different versions), Sparc Solaris, PC Solaris,
> Digital Unix, OS/2... The list is endless.
> 
>   And what's the point anyways? I really don't see such a big advantage of
> this. It just introduces really big maintenance and incompatibility problems.
> 
First, I must say that I agree with Warp.
But the distribution might be on source, not binary.
The only trouble is that the syntax sugar to generate a .so differs
greatly from one unix to another. (Including between version of the same
unix-provider). And then every user must get access to a C++ compiler, 
instead of using directly. 
Moreover, it is usually required that the .so to be in a special place which
required root priviledge to install...
I really feel this approach should be avoided.

Maybe what really need the first requester was a simpler way to add 
object/pattern/.. so that instead of having to always patch the same 
common file (parse.*, tokenize.*, whatever) and then a set of separate
files for the new thing, all could be simplified to just one single file
to patch (with only a simple #include ... ?) and the new set of files 
for the new thing.

IMNSHO, We are not ready for 4.0 yet. Let's play first with 3.5, then having
some super/mega/giga/hyperpatch. Then maybe, some people will start thinging
how to waste more CPU cycles with a 4.0 and a complete redesign.
But probably not before 3 or 5 years.

Post a reply to this message

"Alessandro Coppo" <a.c### [at] iolit> wrote:

> The ONLY platform I know for sure that has nothing
> like these tools is MS-DOS!

DOS had Overlay-files (*.OVL) ... they were loaded at runtime ...

But maybe this could only be code, that was known/created at compiletime...

--
Jan Walzer <jan### [at] lzernet>

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> ha scritto nel messaggio
news:slr### [at] fwicom...

> plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip
x}rotate
> z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red
1rotate 60
> *z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb
z}text{ttf"arial.ttf"
> "RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron
Parker

Hey, *RP*!! Who could imagine?
;)

Post a reply to this message

On Mon, 24 Sep 2001 19:08:31 +0200, JRG wrote:
>
>z}text{ttf"arial.ttf"
>> "RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron
>Parker
>
>Hey, *RP*!! Who could imagine?

Oh yeah, wise guy?  Well, what's this one do then?  No fair rendering it 
until after you give up.  :D

The point of the other one was the interesting tiled pattern in the 
background, really.  The RP was just so it was useful as a signature.

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message