-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Hormann wrote:
| I find it odd that seemingly some people posting in this thread want to
| discuss the topic of plugins just for the sake of 'having plugins'
| without having any idea what they can seriously be used for and insist
| on doing so in a theoretical way refusing to seriously answer the very
| practical questions asked by Warp and others.
|
	Well, let's take a shot at it then:

* "It's useless" *
	Let's assume that I want to use Renderman-like shaders and hdri
output. How do I do that with the current system? Megapov has hdri but
no shaders, and povman has shaders but no hdri. This is something that
will crop up every time two people implement some great new features
independently. If there was a plugin system they could simply each
write a plugin and the user could then combine the capabilities of
both plugins without having to wait for someone to (maybe) integrate
both into a unified patch.


* "SDL code would not be portable depending on what plugin ar
installed on a specific platform" *
	That's also true with unofficial patches.


* "People would complain about pov bugs when in fact it is the plugin
that causes the problem" *
	That's the only valid long term objection I've heard (well, "we don't
want do do it" is valid too as far as official povray is concerned,
but this one also applies for an unofficial patch). OTOH it would make
for shorter discussions if all you had to say was "Ask the plugin
writer" instead of what's happening in the current thread ;)


* "It's not possible in a portable way" *
	I didn't know it was possible in a portable way to display the image
on the screen while it's rendering, or to output to a system specific
(!) format. Yet pov does both.
	Of course, plugins would require some platform specific code, but not
that much (a loadPlugin function taking a string and returning a
handle and a closePlugin function taking a handle and returning void,
that's all. Plugins could be made to not require any system specific
code at all).


* "Not everybody has a C/C++ compiler if they can't find a binary for
their platform" *
	That's also true for unofficial patches. If you can't find a binary
for your platform and can't compile one yourself, then you can't use
it but you're no worse of than if it had been implemented as a patch
that you couldn't have used either.


* "How would you deal with compiler compatibility issues" *
	See the above point. The feature would only be available to
compatible compilers. If your compiler isn't compatible with the
official build then you'd need to rebuild pov from source (no big deal
since you're already willing to compile your plugins anyway).

* "What functionnality would it implement?" *
	Upon being loaded, the plugin would register itself with the parser,
so that when 'such and such' keywords are encountered, then 'such and
such' function needs to be called to do the actual parsing (not that
different from the current parser, except that it uses dynamic tables
instead of hardcoded functions).
	The plugin would have access to the same functions as the parser so
that it could create predefined objects/textures/... and access such
functionnality as the 'trace' function (this would allow 'clothsim' to
be implemented as a plugin for example: use 'trace' on predefined
objects and output a mesh).
	Moreover the plugin would be able to create objects and patterns that
would call a function inside the plugin when they need to be evaluated
(trivial to do in C++ with polymorphism and not that difficult in C).


* "How would it be connected with the povray core?" *
	I think that the povray core would have to be split in two parts:
- - a library that contains all the core functionnality and exports all
the necessary functions so that a plugin linked against this library
would have access to the functions I talked about in the previous point;
- - and a small executable that would link against this library and call
it to do the work.
	In fact, the split could probably be done by putting all platform
independant code in the library and all platform dependant code in the
executable.


* "The povray license doesn't allow this" *
	I thought one of the effects of the complete code rewrite with pov
4.0 is supposed to be a possible change of license? I know we're not
supposed to talk about pov 4.0, but if that is the case, it might
become possible to write such a plugin system then (as an unofficial
patch of course) without licensing issues.


	So as a conclusion:
- - I don't see it as practical with the 3.x code base (especially if it
needs to be completely rewritten along with the rest when we shift to
4.0);
- - I've understood and taken note that the current pov team won't do
it, ever. Of course, the current team isn't the same as ten years ago,
so maybe ten years in the future the official position may change.
- - Provided that the future license allows it, it shouldn't be too
difficult to implement.
- - 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.

	Just my 2 cents,
		Jerome

- --
******************************
*      Jerome M. Berger      *
* mailto:jbe### [at] ifrancecom *
*  http://jeberger.free.fr/  *
******************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCDcknqIYJdJhyixIRAjvGAJ0cO7yxDwKXDVTzYjXPKlocoHhVTwCfY2v9
K9EGxSu2Qjdyn9xnqRdhWBk=
=fG89
-----END PGP SIGNATURE-----

Post a reply to this message