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

Don't mind. Just kidding.

"Ron Parker" <ron### [at] povrayorg> ha scritto nel messaggio
news:slr### [at] fwicom...
> 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

On Mon, 24 Sep 2001 19:33:30 +0200, JRG wrote:
>Don't mind. Just kidding.

I know.  So was I.

-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message

GIMP has cross-platform plug-ins.

Regards

Disnel

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

Post a reply to this message

On Wed, 03 Oct 2001 14:15:08 +0200, Disnel wrote:
>
>GIMP has cross-platform plug-ins.

Written in an interpreted (or maybe p-code) language.  Not fast enough for 
raytracing by a long shot.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C)bicubic_patch{type 1u_steps 6
v_steps 6R(1)R(3)R(5)R(7)translate 9*z-2pigment{rgb z}}#end#macro _(Y)#local X=
asc(substr(C,Y,1))-65;<mod(X,4)div(X,4)>#end#local O=union{Q("ABEFUQWS")Q(// RON
"WSXTLOJN")}Q("JNKLCGCD")union{O}union{O translate 3*x}light_source{x 1}//PARKER

Post a reply to this message

Ron Parker wrote:

> On Wed, 03 Oct 2001 14:15:08 +0200, Disnel wrote:
> >
> >GIMP has cross-platform plug-ins.
>
> Written in an interpreted (or maybe p-code) language.  Not fast enough for
> raytracing by a long shot.

And still not ready for primtime on Win32

--
Jon A. Cruz
http://www.geocities.com/joncruz/action.html

Post a reply to this message

> 
> Written in an interpreted (or maybe p-code) language.  Not fast enough for 
> raytracing by a long shot.
> 


???? My option is, that GIMP plug-in is a piece of C code, which is 
compiled on target platform with gimptool, so it is not interpreted...

>

Post a reply to this message

>>
> 
> And still not ready for primtime on Win32


But GIMP for Win32 exists?? OK, I don't tried it, I don't use this M$ 
thing..

> 
> --

Post a reply to this message

On Thu, 04 Oct 2001 12:06:53 +0200, Disnel wrote:
>> 
>> Written in an interpreted (or maybe p-code) language.  Not fast enough for 
>> raytracing by a long shot.
>> 
>
>
>???? My option is, that GIMP plug-in is a piece of C code, which is 
>compiled on target platform with gimptool, so it is not interpreted...

I'm pretty sure that most plugins for the GIMP are written in Scheme, but
I suppose I could be misremembering.

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

>
> 
> I'm pretty sure that most plugins for the GIMP are written in Scheme, but
> I suppose I could be misremembering.


Yes, a lot of plugins are in scheme, but there is also possibility to 
create compiled plugin (for example gimpprint plugin)

> 
>

Post a reply to this message

On Thu, 04 Oct 2001 17:06:30 +0200, Disnel wrote:
>>
>> 
>> I'm pretty sure that most plugins for the GIMP are written in Scheme, but
>> I suppose I could be misremembering.
>
>
>Yes, a lot of plugins are in scheme, but there is also possibility to 
>create compiled plugin (for example gimpprint plugin)

But then we come back to the problem of requiring anyone who wants to use
POV to have access to a compiler of some sort, or of creating our own compiler
for plugins.  The first is, IMHO, an unfair expectation given the nature of
most POV users.  The second is a lot of work.  That's not to say it will never
happen, because we are moving in that direction slowly with things like the 
new function evaluation engine in POV 3.5 (here I'm thinking of features of 
the function engine that haven't been made public yet, so you'll have to take
my word for it) but it's not going to happen overnight.

In any case, it turns out that there aren't that many primitives that are
just begging to be added.  Most of the patches collected in MegaPOV fall 
into three categories: 
 - general, widespread changes to the rendering engine (photons, dispersion, 
   light groups, UV mapping) 
 - parser-only changes (most of mine: #ifdef(A[i]), trace, min/max_extent)
 - new textures or variations on old textures (object pattern, crackle)

The only really new primitives are the isosurface and the parametric 
object, and I can't envision trying to implement either of them as a
plugin even if the mechanism for doing so existed.  I certainly can't see
being able to make the changes necessary to make pigment functions if
isosurfaces *were* implemented as a plugin.

Recently, the most-requested features have been more texture-oriented 
things (lighting models, subsurface scattering, blurred reflection) and
more widespread changes (tesselation).  I haven't heard a lot of people
asking for new primitives.

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

Ron Parker wrote:

> On Thu, 04 Oct 2001 17:06:30 +0200, Disnel wrote:

> But then we come back to the problem of requiring anyone who wants to use
> POV to have access to a compiler of some sort, or of creating our own compiler
> for plugins.  The first is, IMHO, an unfair expectation given the nature of
> most POV users.


OK this is true. I have slightly different point of view, because I'am 
using only linux and there I have always compiler.

> The second is a lot of work.  That's not to say it will never
> happen, because we are moving in that direction slowly with things like the 
> new function evaluation engine in POV 3.5 (here I'm thinking of features of 
> the function engine that haven't been made public yet, so you'll have to take
> my word for it) but it's not going to happen overnight.


I think, that this is nearly impossible to create "unviersal compiler" 
for all processors and systems.

> 
> In any case, it turns out that there aren't that many primitives that are
> just begging to be added.  Most of the patches collected in MegaPOV fall 
> into three categories: 
>  - general, widespread changes to the rendering engine (photons, dispersion, 
>    light groups, UV mapping) 
>  - parser-only changes (most of mine: #ifdef(A[i]), trace, min/max_extent)
>  - new textures or variations on old textures (object pattern, crackle)
> 
> The only really new primitives are the isosurface and the parametric 
> object, and I can't envision trying to implement either of them as a
> plugin even if the mechanism for doing so existed.  I certainly can't see
> being able to make the changes necessary to make pigment functions if
> isosurfaces *were* implemented as a plugin.

> 
> Recently, the most-requested features have been more texture-oriented 
> things (lighting models, subsurface scattering, blurred reflection) and
> more widespread changes (tesselation).  I haven't heard a lot of people
> asking for new primitives.


This all is true, again, but plugins may be used not only for new 
primitives..

But maybe sufficient solution will be new C++ design of POV4 with 
possibility to add new things as childrens of some POV classes, I only 
like idea of plugins, which I can download and add to my local copy of 
POV without recompilation of whole package....

> 
>

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Thu, 04 Oct 2001 17:06:30 +0200, Disnel wrote:
> >>
[snip]
> In any case, it turns out that there aren't that many primitives that are
> just begging to be added.

    Well, now that you bring it up -- heh,heh -- Has anyone checked out Softy3D?
There is a link to it on povray links pages. I think blob-able splines would be
cool. And like that program, if blobs in general had grouping capabilities
(similiar to light groups) that would be super-cool. :D

>Most of the patches collected in MegaPOV fall
> into three categories:
>  - general, widespread changes to the rendering engine (photons, dispersion, >
light groups, UV mapping)
>  - parser-only changes (most of mine: #ifdef(A[i]), trace, min/max_extent)
>  - new textures or variations on old textures (object pattern, crackle)
>

    Speaking of textures. . . I noticed some odd, but not unexpected (after some
consideration) behavior while experimenting with cutaway textures and uv_mapped
boxes. It led me to implement a generic box-mapping function. The process wasn't
too difficult and it works well on several arbitrary shapes(objects that taper
too much need a little work though, but I think it can be done without too much
more effort).

Given your relatively strong mathematical skills and programming prowess,(not to
mention those of the other programming team members as well) I have to wonder
"What were map_types 3&4 ("still under development" since at least 2.2) supposed
to be?" And, "Why isn't one of them a box-mapping type?" And, "What about a
box-mapping warp type?"

I don't suppose any necessity for these implementations of box-mapping now with
the pigment functions. It's just one of those things that make me go
"Hmmmmmmmmm."

--
Batronyx ^"^
bat### [at] cadronhsacom //old & going away
bat### [at] alliancecablenet new & active now.
http://www.batronyx.com

Post a reply to this message

POV is a get-it-and-shut-up thing.

If you like it, use it.
If you can live with its limits, work around them.
In any other case, shut up and look somewhere else.

There is no point in asking for changes.

Alessandro Coppo
a.c### [at] iolit

P.S.: there is also another route, but this requires rolling up sleeves 
and writing code...

Post a reply to this message

Alessandro Coppo schrieb in Nachricht <3BC### [at] iolit>...
>POV is a get-it-and-shut-up thing.

[...]
>There is no point in asking for changes.


I can't agree with you here. I once mentioned a pattern-type feature that
would be cool. It did not take long (days, not weeks) and someone had
written the code for something similar. It was not the same I asked for, but
one would have been able to achieve similar results with it. Okay, that
patch was never published, but that did not matter that much, as I went on
and was already at another project. And the author was willing to send a
copy to me.

I'm sure, this is not a one-time-event. Those programmers here do really
listen to things people ask for. Try the same with multi $ products. They
will take your money, but they won't incorporate your wishes. The Pov-Team
won't take your money and if you are able to convince them, that your way is
the better one (including necessary programming time and conception) - I
can't imagine, that they were not at least interested. And don't forget:
It's their program not ours. It's their time which they are willing to spend
to produce something which becomes even better all the time.

They even share the code with the community, so you don't even have to
convince one of the Pov-Team programmers to incorporate your wishes.
Everyone with knowledge of C(++) and a compiler can do it for you.

So where is the point in complaining? What do you want to achieve by that?

Just my two "only-user" Groschen,

Marc-Hendrik

Post a reply to this message

In article <3BB### [at] hlavacek-partnercz> , Disnel 
<dis### [at] hlavacek-partnercz>  wrote:

> I think, that this is nearly impossible to create "unviersal compiler"
> for all processors and systems.

No, not really.  It is very simple but has one catch: The compiler will not
deliver optimal code.  Still, you get at least 10 to 20 times the speed of a
purely emulated virtual machine.

But as Ron mentioned, writing a just-in-time compiler is no trivial task at
all and takes a lot of time...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message