On Fri, 11 Feb 2005 20:11:32 -0600, Thorsten Froehlich wrote:

> This topic is just a dead end discussion as you
> won't get plug-ins in any official POV-Ray

Please pardon my butting in here, all due respect to you and the POV-Ray
team (been a user of the software for years, like many here I remember
DKBTrace and the running the early releases of POV on a 386 - in fact, I
bought a 387 coprocessor specifically for running POV), but just because
the feature won't appear in an official POV-Ray build, is there any harm
in those who are interested discussing the possibilities for an unofficial
build?

And if they managed to pull it off somehow, isn't there at least the
potential that at that time someone from the POV-Ray team might consider
it a valuable addition to the existing code?

I don't have all the history on the discussions on the topic in the past,
but I really don't understand why there is such apparent hostility towards
even the idea of discussing the possibility of how such an extension might
be accomplished.

If anything, for those who are either not familiar with
cross-platform coding practices and those not as familiar with the POV-Ray
code as you are certainly could learn a lot from the exercise of examining
this aspect of the code.

Just MHO, of course.

Jim

Post a reply to this message

Jim Henderson wrote:
> the feature won't appear in an official POV-Ray build, is there any harm
> in those who are interested discussing the possibilities for an unofficial
> build?

It is not up to me or anybody else how others waste their time, you just 
have to face the fact that it will never be added to an official version and 
as such it is a waste of time.  You are also free to write your own 
ray-tracer or whatever else you like doing during your free time.

> And if they managed to pull it off somehow,

This will not happen.  All you will ever get is some hack.  In fact such a 
hack has existed before in some ancient isosurface code.  The fact that 
nobody supports it any more should tell you something.

 > isn't there at least the
> potential that at that time someone from the POV-Ray team might consider
> it a valuable addition to the existing code?

No, it is certainly not going to be considered for all he reasons outlined 
so many times in the past and for the millionth time in this thread.

	Thorsten

____________________________________________________
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

Warp wrote:
>   Now, would you care to explain how this basically simple plugin
> ideology could be embedded into POV-Ray?

Isn't that what macros are for?  O.o;

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

On Fri, 11 Feb 2005 20:49:27 -0600, Thorsten Froehlich wrote:

> Jim Henderson wrote:
>> the feature won't appear in an official POV-Ray build, is there any harm
>> in those who are interested discussing the possibilities for an
>> unofficial build?
> 
> It is not up to me or anybody else how others waste their time, 

Again all due respect, but those people considering how to do it may well
not consider it a waste of time.  Your point of view is not the only point
of view.

> you just
> have to face the fact that it will never be added to an official version
> and as such it is a waste of time.  

Well, again, those who are considering what it might take probably don't
consider it a waste of time, but a valuable learning experience,
regardless of whether it is added to the official version or not.  Just
like the post-processing features in MegaPOV probably would never be added
to the official build, yet MegaPOV is quite popular, from what I've seen.

>> And if they managed to pull it off somehow,
> 
> This will not happen.  All you will ever get is some hack.  In fact such a
> hack has existed before in some ancient isosurface code.  The fact that
> nobody supports it any more should tell you something.

That maybe that implementation was sub-optimal.  I personally think it's
foolish to think that something can *never* be accomplished, if everyone
thought that way, we wouldn't have technology to the state it's in now.

>  > isn't there at least the
>> potential that at that time someone from the POV-Ray team might consider
>> it a valuable addition to the existing code?
> 
> No, it is certainly not going to be considered for all he reasons outlined
> so many times in the past and for the millionth time in this thread.

Well, that's your opinion.  I will grant that as you're a member of the
POV-Ray team, your opinion probably counts for more, but again, that's
just one point of view, and there are many others as evidenced by the
amount of discussion this has generated.  Personally, I find it a very
interesting bit of cognitive dissonance to be closed-minded about
something relating to what is for all intents and purposes an open-source
project.

All the time I've worked in the technology field (and that's a
considerable amount of time), the one thing I've learned is never to
assume you know everything about anything, because next week, that can
change.

Jim

Post a reply to this message

On Fri, 11 Feb 2005 19:24:06 -0800, Darren New wrote:

> I also find it odd that members of the Official POV-Ray Team would be
> trying to basically shout down discussion on the POV-Ray news server about
> POV-Ray features, but that's another thing.

You're not the only one.  As I mentioned in what I just wrote to Thorsten,
I see it as just so much cognitive dissonance to be closed-minded about
potential features in what is for all intents and purposes an open-source
project.

Sure, someone's got to decide what goes in and what doesn't, and maybe
these external functions don't belong in the official builds, but that
doesn't invalidate the discussion or possibility for a fork in the code to
support the desired functionality in an unofficial build.  It's not like
there haven't been unofficial builds of POV-Ray that added functionality
above what's in the official build.

Personally, I find the discussion here fascinating, because I deal with
technology that is cross-platform and in fact is implemented through the
use of shared libraries on different platforms - on Linux, using shared
libraries, on Windows using DLLs, on the NetWare platform using
NLMs, and on other Unix platforms using the same type of shared libraries
as on Linux.

The base functionality runs from the standpoint of a common codebase, with
a variety of techniques used to port the shared library functionality
between different platforms.  I don't pretend to know very much about how
it is technically achieved, since I'm not a software engineer (though I do
code a fair bit), but having seen technology implemented in the
closed-source world that implements precisely what Thorsten is saying is a
bad idea, I can state unequivocally that it is in fact possible and not a
bad idea, because it allows code reuse on a much greater scale.

That said, I don't know the internals of POV-Ray as well as Thorsten
undoubtably does, so it's definitely possible that he knows something
about the architecture of POV-Ray that I don't and maybe there is
something inherent in the POV-Ray code that prevents something like this
happening.

I can say that portability of shared libraries in a cross-platform
environment helps the company I work for port things between multiple
platforms by increasing code reuse without building monolithic products
using unique code on each platform - and if it wasn't possible or was
technically very difficult and cumbersome, we wouldn't design software to
run on Windows, NetWare, Linux, AIX, and HP-UX because it just wouldn't be
economically feasable.

Jim

Post a reply to this message

nomail@nomail news:web.420b7c34c551b3d17485eb850@news.povray.org

> I'd like to call Library-Functions from SDL. Is there already an
> extension to POV-Ray that enables declaration of external user-defined
> functions? 
> 

I think it would be a greate idea. Hmm how about soemthing like this - 
extent funcitons so that could work as a plugins for doing most things, not 
only pattern functions (in density, pigment, and so on), but also while 
shooting rays for camera and in other places.

Now extent macro language. Would it be very hard to implement minimalistic 
C-like language interpreter? Then, on some platforms such funcitons could 
be compiled using gcc before rendering to speed it up (someone done this 
patch already, AFAIK it was mostnly for isosurfaces on Linux?). On other 
platforms - it would be interpreted.

It would work like:


#function Vector3 ShootRay(float x, float y) { 
  Vector3 r;
  r.x = x/2 + sin(y);   
  //...
  return r;
}

#funcion Color Pigment1(float x, float y, float z) {
  return ...... ;
}

camera { use { ShootRay } }

sphere { 0 1 pigment { use { Pigment1 } }


 
-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

tho### [at] trfde news:420d12db$1@news.povray.org

> and I would really wish people would just for once not argue over
> something they so obviously do not understand.  After having had the
> same discussion for the 10th time in five years, it is only annoying,
> nothing else 

All other modern renderers can be extended rapidly by own shaders, plugins, 
and so on. Why There is no such thing for PovRAY? 

Yes, the problem with working on all platforms, I agree. 
But how about extending macro/functions parser into minimal C parser (just 
basic statement, few build-in types and thats all).

Then it could be interpreted on all platforms.

And - in addition - some could have possibility to nativly compile code and 
use it to drasticly speed up rendering with advanced "shaders".

About compilation, PovRAY could go over each function, parse it manualy 
(that is - check it syntax) and save result into

fun_pigment1.c   fun_mynormal.c  and so on, then it would call make to 
rebuild thoes functions and some  call_external_function.c, and will link 
it with rest of povray - it would take some time but it should be usefull 
for big projects.

There are so many additional benefits and ways to explore such approach to 
extending PovRAY functionality, I realy hope You would find it a thing tht 
might be worth a try some day.

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

Darren New wrote:
> 
> I also find it odd that members of the Official POV-Ray Team would be 
> trying to basically shout down discussion on the POV-Ray news server 
> about POV-Ray features, but that's another thing.

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.

The original poster probably was just having the misguided impression 
that a plugin system would be the best solution for his problem.  But 
until now he did not explain what he really wants to do so no one had 
the chance to show him a practicable solution.

And in addition to what others have said: there will never be a feature 
in POV-Ray that allows you to create custom extensions of POV-Ray (or 
'plugins' if you want so) that are published as platform specific 
binaries and are not licensed under the POV-Ray license (simply because 
it violates the letter and the spirit of the license).

Christoph

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

Post a reply to this message

On Sat, 12 Feb 2005 08:05:24 +0100, Christoph Hormann wrote:

> that are published as platform specific binaries
> and are not licensed under the POV-Ray license (simply because it violates
> the letter and the spirit of the license).

I was going to start out by saying something to the effect that I didn't
remember anyone suggesting that such plugins would/should be binary-only,
and then it suddenly hit me as to why this seems like a bad idea to those
with more experience than I.

If such extensions were to be published in source form, then why would
there be a need for a plugin?  Why not just add the code to the POV-Ray
codebase directly in source format?  If the proposed extension were such a
good idea, then linking as a library actually *doesn't* make sense,
because that would complicate the code unnecessarily when the SDL language
could be extended directly (either in an official build or an unofficial
build) to add the new object type.

Consider the lightbulb turned on here - and thank you for mentioning the
"letter and spirit of the license" in your post.  *That* makes perfect
sense, rather than the approach others have taken in just
essentially saying "this is the way it is, deal with it."

Jim

Post a reply to this message

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