In article <420ddedc@news.povray.org>, war### [at] tagpovrayorg says...

> > - - It won't remove the need for patches (New rendering features
> > couldn't go through such a mechanism, nor could existing rendering
> > features be extended easily), but it could provide some useful
> > modelling and texturing functionnalities.
> 
>   I think this is the most important realization of yours, and exactly
> my point.
> 
>   The only features you site in that paragraph as possible with plugins
> is something which will most probably be possible, in a much easier way,
> with the new scripting language of POV-Ray 4. It will probably be
> possible to do more with the scripting language than what you could
> do with a plugin feature like you described.
>   It shouldn't be necessary to list once again the advantages of having
> a "plugin" written in POV-Ray's own native scripting language as opposed
> to having a C++ patch (or C++ plugin).

Hmm.. On that thought... Such a system would be a bit like the plugin 
system for Mushclient. At one point it was realized that there where 
three *big* issues with having all your code in one file, even if you 
also used script functions to load some sort of .inc type file. The first 
issue is a non-issue with POV. Since multiple script languages where in 
use, the possibility existed that shared code would not work, since it 
would be in the wrong language. This obviously isn't a problem with POV-
Ray. The second issue was sharing things. If you wanted a plugin to keep 
track of potions, you could export a bunch of aliases, triggers, etc., 
shop out the needed code, hope you didn't miss anything and then have the 
user patch all of them into their client. By making a plugin system, all 
those things could be exported to a file with its own script, triggers, 
etc. The third issue was collisions. Situations where the script might 
contain the same variables or the same/similar aliases, triggers and such 
existed in more than one. By keeping them separate, even when in the same 
language as the 'master' script, there was no major issues with this. Oh, 
and it also allowed some plugins to be declared as 'global' to all 
worlds.

Seems to me that something like that in POV-Ray could kill the same two 
birds with one stone, allowing a 'plugin' to have its own functions and 
the like that won't collide with existing ones *and* make it possible to 
declare commonly used ones as 'global', so they are automatically 
available, without adding code to include them for every single scene 
that uses them. This also eliminates the issue of cross platform 
compatibility, since the 'plugins' are native SDL, just importer either 
as an object-like extension to a specific scene or as a global 'library'. 
The only real difference from the existing model would be how the engine 
'sees' certain types of includes. As a library, it would provide both the 
global option and automatic collision prevention. The only difference in 
the SDL itself might be a single directive, like <library "Blah">, which 
makes it treat the code in 'that' file as an object itself, called 
'Blah', instead of just imbedding it into the SDL as part of the global 
script. Any objects, variables, etc. would be accessed with Blah.Object, 
instead of just the name if referenced from the main SDL(s). Normal .inc 
files would still work as normal with no changes.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message