I like Hugo Asm am by no means a C or C++ programmer.  I can however write
programs in other languages.  I came here to the programming forum to
second Hugo's request for some extensions to the #read directive in SDL.
Namely I was going to request the addition of some of the standerd file
reading functions:

get current byte position in an open file
set current byte position in an open file
return a string containing all data until the next newline charicture (get
line)

But while reading the replies to the post made by Hugo it occured to me that
no matter how many new directives are added to sdl it will never satisfy
everyone's needs.  What Povray needs is a plug-ins API...

Amazing work has been done in the form of patchs like MegaPov, MLPov,
SlimePov etc.  And in the case of MegaPov many patches have been brought
together to form the most advanced Pov pre 3.5.  Each of these is seperate
though, they do not work together, and a scene writen for one will not
neccisarily work with another.  Would it not make more sense to have a
standard method for writing plug-ins to extend Povrays capabilities?  So
that the user would be able to chose which patches or features he or she
needs at any one time, and so that the user could use different patches
together in the same scene without needing to create a custom compile
themselves?

It would be difficult... In fact I don't think any one person could write a
standardized API to the Povray render engine.  It would take a team of
programmers working together.  But having a direct interface would allow
other programers to write useful utilities, extensions, objects and more
without spending months or years studying the Povray modules and how they
work together.

I cannot say how this could or should be done, I am just an artist.  I can
program enough to make little utilities and tools for the work I do.  I
have seen the source for Povray, and I cannot believe anyone can create
such a huge and amazing program.  What I do know is that the current patch
system is limiting the number of people who can contribute to Povrays
abilities, and that a scriptable or programable interface could allow
greater versitility to this alread powerful tool.

Perhapse though this should be a feature for the next version of Povray, let
everyone start with an official unpatched version and build from there.
Wish I could help more on the implimentation of this, I really think it
would be a useful addition...

Post a reply to this message

On Sun, 11 May 2003 22:52:44 EDT, "Kitsune_e" <kit### [at] hotmailcom> wrote:
> What Povray needs is a plug-ins API...

They are called "patches" here. And the initial API is at
http://megapov.inetart.net/manual/internals.html :-)

ABX

Post a reply to this message

In article <web.3ebf0c7ca214be38a7ab6a390@news.povray.org> , "Kitsune_e" 
<kit### [at] hotmailcom> wrote:
> I like Hugo Asm am by no means a C or C++ programmer.  I can however write
> programs in other languages.  I came here to the programming forum to
> second Hugo's request for some extensions to the #read directive in SDL.
> Namely I was going to request the addition of some of the standerd file
> reading functions:

Before I respond to your "idea", I would like to make clear for everyone:
This group is not meant for *any* kind of feature requests by *users*.  It
is for, and only for "Programming related discussion (i.e. source code
etc.)" of POV-Ray by *programmers* knowing or having (specific) questions
about the POV-Ray source code.  So, please do not clutter this group with
unrelated discussion.  The extreme noise level in this group by people who
got lost (due to the many groups) has always been a big problem in this
group, but *please* lets not make it worse!

> But while reading the replies to the post made by Hugo it occured to me that
> no matter how many new directives are added to sdl it will never satisfy
> everyone's needs.  What Povray needs is a plug-ins API...

No, it does not and will not get such *nonsense* for good reasons that
should be really obvious to a programmer.  If not, just look back at the
previous replies to this "plugin idea", usually coming up about once a
year...

    Thorsten

(Note: While an official POV-Team response would find nicer words, the point
would remain the same.)

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Lets go to the advanced-users group and continue the talk.
I just posted there, still on the thread: Extending the #read directive

http://news.povray.org/3ebf5a59$1@news.povray.org

Thank you.

Post a reply to this message

Kitsune_e <kit### [at] hotmailcom> wrote:
> What Povray needs is a plug-ins API...

  You are free to suggest a way of implementing this so that it will work
in all systems POV-Ray is used (which includes, among others, Windows, MacOS,
Linux, Solaris, RiscOS, etc).

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

Post a reply to this message

> It
> is for, and only for "Programming related discussion (i.e. source code
> etc.)" of POV-Ray by *programmers* knowing or having (specific) questions
> about the POV-Ray source code.

	Is this too late to change "programming" to something else ? Maybe
"p.source-code" or "p.engine-internals" or much better ? With "programming"
those who think ("using the SDL" == "programming POV") end up in here...

Post a reply to this message

Nicolas Calimet wrote:
> 
> > It
> > is for, and only for "Programming related discussion (i.e. source code
> > etc.)" of POV-Ray by *programmers* knowing or having (specific) questions
> > about the POV-Ray source code.
> 
>         Is this too late to change "programming" to something else ? Maybe
> "p.source-code" or "p.engine-internals" or much better ? With "programming"
> those who think ("using the SDL" == "programming POV") end up in here...

You will probably have noticed that from the last 6 threads in this group
there was none 'off-topic because only SDL-related'.  Still 4 should
better have been started in a different group.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

ABX wrote:
>On Sun, 11 May 2003 22:52:44 EDT, "Kitsune_e" <kit### [at] hotmailcom> wrote:
>> What Povray needs is a plug-ins API...
>
>They are called "patches" here. And the initial API is at
>http://megapov.inetart.net/manual/internals.html :-)
>
>ABX
>

I obviously know about patches since I mention several in my post, and I
already knew that there was a programers referance in the Megapov docs.
This is not what I am discussing.

Post a reply to this message

>Before I respond to your "idea", I would like to make clear for everyone:
>This group is not meant for *any* kind of feature requests by *users*.  It
>is for, and only for "Programming related discussion (i.e. source code
>etc.)" of POV-Ray by *programmers* knowing or having (specific) questions
>about the POV-Ray source code.  So, please do not clutter this group with
>unrelated discussion.  The extreme noise level in this group by people who
>got lost (due to the many groups) has always been a big problem in this
>group, but *please* lets not make it worse!
>
>> But while reading the replies to the post made by Hugo it occured to me that
>> no matter how many new directives are added to sdl it will never satisfy
>> everyone's needs.  What Povray needs is a plug-ins API...
>
>No, it does not and will not get such *nonsense* for good reasons that
>should be really obvious to a programmer.  If not, just look back at the
>previous replies to this "plugin idea", usually coming up about once a
>year...
>

I would not have posted here except that it was requested that I post here
by Hugo.  Also I attempted to shift the discusion into a more programming
oriented direction.

As for non-sense I do not understand why how giving other programs access to
Povray's internal data is non-sense, or why it cannot be made portable
among machines with similar architecture?

Post a reply to this message

Warp wrote:
>Kitsune_e <kit### [at] hotmailcom> wrote:
>> What Povray needs is a plug-ins API...
>
>  You are free to suggest a way of implementing this so that it will work
>in all systems POV-Ray is used (which includes, among others, Windows, MacOS,
>Linux, Solaris, RiscOS, etc).
>
>#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
>N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
>N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -
>

I have read no articles on building plug-ins, I do not know specific
methods.  It occures to me that C has generaly the same data structures
accrossed multiple platforms (string int double etc).  C is ment to be
portable, the compiler should handle any non-system specific code on any
system.  I do not know if that is the case in practice though.

Post a reply to this message

Nicolas Calimet wrote:
>> It
>> is for, and only for "Programming related discussion (i.e. source code
>> etc.)" of POV-Ray by *programmers* knowing or having (specific) questions
>> about the POV-Ray source code.
>
> Is this too late to change "programming" to something else ? Maybe
>"p.source-code" or "p.engine-internals" or much better ? With "programming"
>those who think ("using the SDL" == "programming POV") end up in here...
>

It might be a waste of space, but why not expand .programming to its own
section:

povray.programming.engine .general .patches etc.

just to make it more clear.

Post a reply to this message

On Tue, 13 May 2003 10:50:10 EDT, "Kitsune_e" <kit### [at] hotmailcom> wrote:
> It occures to me that C has generaly the same data structures
> accrossed multiple platforms (string int double etc).

It occures to me that POV has the same data structures accrossed multiple
platforms (string, float, color objects pigments etc).

>  C is ment to be portable,

So and POV-Ray

> the compiler should handle any non-system specific code on any
> system.  I do not know if that is the case in practice though.

Of course not. How many portable C compilers have plugin feature ?
How many C compilers opens its own _internal_ structure for other apps ?

ABX

Post a reply to this message

On Tue, 13 May 2003 10:40:56 EDT, "Kitsune_e" <kit### [at] hotmailcom> wrote:
> > > What Povray needs is a plug-ins API...
> >
> > They are called "patches" here. And the initial API is at
> > http://megapov.inetart.net/manual/internals.html :-)
>
> This is not what I am discussing.

But that's the only possible discussion which can be continued from your feature
request (and then in povray.unofficial.patches).

ABX

Post a reply to this message

Kitsune_e wrote:

Well, I attemted to give an intelligent sugestion instead of the "Please add
feature" I was ment to request, and I have been stoned and humiliated by
people whom I respected.  I don't think my request was foolish, I do think
it was rediculesly difficult to impliment.  Of course so would be creating
a raytracing render engine which could successfuly re-create real world
phenomena...

I knew this idea would most likely be met by opposition, I just wish more of
the comments I had recieved had been useful feedback instead of flame.  I
found here an elitist attitude I had not expected to find in the Povray
community.  I will not be asking any more questions on this forum... your
sanctum is safe.  Please go on about your buisness.  You select few have
given many powerful features to Povray.  I have no doubts that you could
extend the Povray engine.

Post a reply to this message

On Tue, 13 May 2003 11:06:22 EDT, "Kitsune_e" <kit### [at] hotmailcom> wrote:
> I have been stoned and humiliated

I will try to list general 'mistakes' you made:

1. You proposed feature (plugin) which comes here very often and which was many
times refused with clear explanation.
2. You proposed feature (plugin) which is impossible to implement in portable
way (or if possible then over skills of people here).
3. You are saying it is possible to implement it and at the same time you say
you do not know how to do it.

I'm really under impression of your art work but this does not change that it is
irritating to repeat the same discussion again and again. Personally I see a lot
of benefits from plugin idea but much more I do not want features dedicated to
one operating system becouse nobody made plugin for other platform or used OS
specific features. The amount of work for coding algorithm in C++ is the same
for patch and for plugin so is there anything what can't be done with patch but
can be done with plugin based architecture ?

ABX

Post a reply to this message

Kitsune_e <kit### [at] hotmailcom> wrote:
> C is ment to be
> portable, the compiler should handle any non-system specific code on any
> system.

  What do you think all the patches out there are doing? Exactly this.

  The problem is, of course, that this is not a plug-in system. You need
to compile the C source code with a compiler.

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

Post a reply to this message

In article <web.3ec109ee2a3b3a27f73ed81b0@news.povray.org> , "Kitsune_e" 
<kit### [at] hotmailcom> wrote:

> I knew this idea would most likely be met by opposition, I just wish more of
> the comments I had recieved had been useful feedback instead of flame.
> I found here an elitist attitude I had not expected to find in the Povray
> community.

You have to realize that developing a program and its logic is a very
difficult task that requires a good understanding of computer science.  Also
you can learn "programming" in school these days, this has very little to do
with computer science.

This is no different from, say, being a car mechanic.  Sure you (not "you"
personally, this is in the general sense of "you") know something about
cars; and you can even detect if something like the exhaust is broken.  But
would you go to your car mechanic and tell him what to fix and how to fix
it, maybe bring a new exhaust with you already even you don't know anything
about the old one?  Unlikely, and if you did, what do you think he would
say?  Or if you wanted to add a spoiler, would you discuss with the car
mechanic how to add it, or tell him you saw the same spoiler on another car
model, and ask him _why_ that one doesn't fit your car?  I suppose no
because you know by doing so you would most likely make a fool out of
yourself.

And this is essentially what you did with your question.  You said: Here is
a spoiler, why can't one mount it on this car if it fits so well on another?
Just like owning a car doesn't make you a car mechanic, owning a computer
doesn't make you a computer scientist.  That is not elitist.  It is reality.

    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

Kitsune_e wrote:
> 
> Kitsune_e wrote:
> 
> Well, I attemted to give an intelligent sugestion instead of the "Please add
> feature" I was ment to request, and I have been stoned and humiliated by
> people whom I respected.

No.

Considering the fact that the matters discussed in this thread are - as
explained - off-topic here and also considering that the main topic of
your posting - the 'plugin' idea - has been covered in depth in previous
discussions all replies you got were relatively friendly and trying to
explain things as much as possible.  Your posting is the first getting a
touch of personal insults which is not appropriate.

As you write yourself:

> As for non-sense I do not understand why how giving other programs access to
> Povray's internal data is non-sense, or why it cannot be made portable
> among machines with similar architecture?

you don't understand why the idea of plugins is not so trivial for
POV-Ray.  If you want an explanation for this you should ask for one in
the appropriate group or even better read up where this has been covered
before, for example in:

http://news.povray.org/povray.programming/28666/
http://news.povray.org/povray.general/2743/
http://news.povray.org/povray.programming/17195/
http://news.povray.org/povray.programming/20476/

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Thorsten Froehlich wrote:
>In article <web.3ec109ee2a3b3a27f73ed81b0[at]news.povray.org> , "Kitsune_e"
><kit### [at] hotmailcom> wrote:
>
>This is no different from, say, being a car mechanic.  Sure you (not "you"
>personally, this is in the general sense of "you") know something about
>cars; and you can even detect if something like the exhaust is broken.  But
>would you go to your car mechanic and tell him what to fix and how to fix
>it, maybe bring a new exhaust with you already even you don't know anything
>about the old one?  Unlikely, and if you did, what do you think he would
>say?  Or if you wanted to add a spoiler, would you discuss with the car
>mechanic how to add it, or tell him you saw the same spoiler on another car
>model, and ask him _why_ that one doesn't fit your car?  I suppose no
>because you know by doing so you would most likely make a fool out of
>yourself.
>
>And this is essentially what you did with your question.  You said: Here is
>a spoiler, why can't one mount it on this car if it fits so well on another?
>Just like owning a car doesn't make you a car mechanic, owning a computer
>doesn't make you a computer scientist.  That is not elitist.  It is reality.
>
>    Thorsten

Thankyou,
this response is a much better answer then the unqualified "_no_" which I
recieved before.  I do understand why my comment recieved such negitive
responses, this is why I attempted to make my comments more of a topic for
intelligent discussion of the possability then a features request.  It
appears though that no one is currently open to or interested in discussing
this possability.

It is true that it would be arrogant to suggest in ignorance to the mechanic
how to do his or her job.  this stupid topic is taking up to much of my
time and yours.  The things done so far in Povray are amazing, and I am
certain greater things are planned in the future.  I would appreciate it if
no one else would reply to this post, and would continue on instead with
more important matters.

Post a reply to this message

In article <web.3ec106c02a3b3a27f73ed81b0@news.povray.org>,
 "Kitsune_e" <kit### [at] hotmailcom> wrote:

> It might be a waste of space, but why not expand .programming to its own
> section:
> 
> povray.programming.engine .general .patches etc.
> 
> just to make it more clear.

The group gets relatively little traffic as it is...spreading it out 
over more would not make sense, and would not make anything clearer.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <web.3ec106212a3b3a27f73ed81b0@news.povray.org>,
 "Kitsune_e" <kit### [at] hotmailcom> wrote:

> I have read no articles on building plug-ins, I do not know specific
> methods.  It occures to me that C has generaly the same data structures
> accrossed multiple platforms (string int double etc).  C is ment to be
> portable, the compiler should handle any non-system specific code on any
> system.  I do not know if that is the case in practice though.

C source code is portable unless it uses something specific to a 
platform. Binary data structures and compiled code are not portable. And 
there is no standard way to dynamically load compiled code in the form 
of plugins, this requires platform-specific code. This is why patches 
are used instead of some plugin system...the plugin system would have to 
be rewritten for each platform. The plugins themselves would be a 
nightmare for support, with people trying to use plugins compiled for 
the wrong systems and potential for conflicts between plugins.

One possible compromise would be to use a platform-independant bytecode 
format, similar to Java class files. However, this has a speed penalty 
because the bytecode has to be interpreted instead of directly running 
machine code, and it would be easier to just load the files from the 
source code as is now done with include files. So, one form of plugin is 
impossible, the other is slower than the alternatives.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message