Ronald L. Parker wrote:
  <lots of good stuff clipped>
> 
> your system.  Again, though, any work of this sort couldn't be
> distributed under the terms of the current POVLegal, unless you
> succeeded in getting it into an official version, and the POV-Team has
> already weighed in fairly negatively on the subject of plugins, as
> well as on the subject of Java.  

The problem with DLL plugins is that they aren't platform independent.
The problem with java is that it is changing too rapidly... no real
standard that is guaranteed to still be around next year (or month, for
that matter).

Also, adding a Java VM to POV could bloat it quite a bit.

I don't think the POV-Team is against the concept of plugins... I just
think that a top priority is platform independence, and if plugins don't
mix well with that, then they are out.

Overall, I do think we need kind of plug-in ability, though.
Unfortunately, I don't have a solution.

-Nathan

Post a reply to this message

Ken wrote in message <37097246.CEB5F0E3@pacbell.net>...
>
>  The photon patch by Nathan Kopp has a uv texturing scheme that is showing
>some serious promise. You seem to have pretty good control of what is
>happening where and at what level in Leveller and the two might find some
>sort of harmonious exsistance.
>
>Take a look at Nathan's Photon Patch page at:
>
>http://nathan.kopp.com/patched.htm
>
>
Thanks, I'll take a look at that and at SuperPatch
as well.

In regards to Ron's DLL comments, I agree that
portability is important. I don't know why
there would be a licencing issue with DLLs
per se -- if developers provide the source code
to their DLLs, just like they do for patches,
then what's the problem? In fact, I was going
to do my changes as a patch, but wanted to
use DLLs just to avoid bloating pvengine.exe.

Granted, people could abuse the DLL system,
and start distributing binaries only. I can
see that being at cross purposes to POV's
normal distribution.

Ray

Post a reply to this message

Nathan Kopp wrote in message <37098AFE.EF824E2D@Kopp.com>...

>
>Overall, I do think we need kind of plug-in ability, though.
>Unfortunately, I don't have a solution.


Why not just add a simple C compiler to
POV's parser? The technology's been
around for eons.

Ray

Post a reply to this message

On Tue, 6 Apr 1999 10:11:40 -0700, Ray Gardener <ray### [at] daylongraphicscom> wrote:
>Ken wrote in message <37097246.CEB5F0E3@pacbell.net>...
>>
>>  The photon patch by Nathan Kopp has a uv texturing scheme that is showing
>>some serious promise. You seem to have pretty good control of what is
>>happening where and at what level in Leveller and the two might find some
>>sort of harmonious exsistance.
>>
>>Take a look at Nathan's Photon Patch page at:
>>
>>http://nathan.kopp.com/patched.htm
>>
>>
>Thanks, I'll take a look at that and at SuperPatch
>as well.
>
>In regards to Ron's DLL comments, I agree that
>portability is important. I don't know why
>there would be a licencing issue with DLLs
>per se

Previous to version 3.1, there were no licensing issues with DLLs.  With 
version 3.1, the Team added a clause to POVLEGAL forbidding adding 
additional APIs to the code.  The primary motivation, as I understand it,
was as a preemptive strike against those who would embed the POV code in
an ActiveX control or OLE server or whatnot.  The Team doesn't want to
see POV being integrated too tightly with commercial code, to the extent 
that it's not obvious to the end user that it's POV doing the work.  The
restriction is intended to keep that from happening, but the end result
is that it keeps things like plugins from happening too.

Post a reply to this message

On Tue, 6 Apr 1999 10:16:44 -0700, Ray Gardener <ray### [at] daylongraphicscom> wrote:
>
>Nathan Kopp wrote in message <37098AFE.EF824E2D@Kopp.com>...
>
>>
>>Overall, I do think we need kind of plug-in ability, though.
>>Unfortunately, I don't have a solution.
>
>
>Why not just add a simple C compiler to
>POV's parser? The technology's been
>around for eons.

What would it compile to?  Bytecode?  Machine language?  If to machine 
language, you'll need some kind of loader to get the code in a place where 
it's executable, and you'd have to be able to generate code for any processor
POV is to run on - including x86, 680x0, Sparc, Alpha, and PPC architectures.  
If to bytecode, why not just integrate the Java VM and get the JIT stuff too?
Now those who know me know that I'm not a Java zealot. In fact, I've come out
against Java many times in the past few years. But I think this is exactly 
what Java was made to do.

I originally thought about embedding a Perl interpreter for the purposes of 
doing programmable shaders and primitives. The process for doing so is 
well-documented, the nature of Perl sorta requires that source to the plugin
be available (though the nature of Perl also allows for it to be completely
unreadable), and it compiles to bytecode and runs pretty quickly.  I don't 
know offhand whether the Artistic License is compatible with POVLEGAL or not, 
but that's easy enough to check.  I don't know whether such a thing would 
fall under the "new api" clause, though, so you'd still have to run it by 
the POV-Team before distributing it.  There is some overhead involved - the 
Perl DLL on win32 is about half a meg.  Still, that's probably pretty small 
compared to a Java VM.

Post a reply to this message

Ron Parker wrote in message <370a4845.0@news.povray.org>...
>On Tue, 6 Apr 1999 10:16:44 -0700, Ray Gardener <ray### [at] daylongraphicscom>
wrote:
>>
>>Why not just add a simple C compiler to
>>POV's parser? The technology's been
>>around for eons.
>
>What would it compile to?  Bytecode?  Machine language?  If to machine
>language, you'll need some kind of loader to get the code in a place where
>it's executable, and... [snip]

Agreed, supporting all those CPUs is bothersome. But
gcc does it, the templates are mature, and we can tweak
for MMX, 3DNow and the PPC's multiply+add and the like. Besides,
it's not like there are new instruction sets coming out every week.
Maybe we can borrow gcc's code here -- it's all open source, right?
As for the loader, just compile down into a temp DLL (if on Windows)
and then use LoadLibrary() to run it.

As for Java, Perl, and any other interpretation system:
I have to pass. No interpreter is fast enough; I need
every last machine cycle available, when you consider that
the code may need to be called for every pixel on the
rendered image.

Read the stuff about 'slope' in the SuperPatch docs.
Pretty heavy; it may do everything I need. So when
does this great stuff get merged into the offical POV?

Ray

Post a reply to this message

>...The Team doesn't want to
>see POV being integrated too tightly with commercial code, to the extent
>that it's not obvious to the end user that it's POV doing the work.  The
>restriction is intended to keep that from happening, but the end result
>is that it keeps things like plugins from happening too.


I can understand that. With the latest round of work
being done on POV-Ray, however, it's becoming obvious
that POV-Ray is being taken seriously and people are
trying to make it do very serious work, and likewise
the POV-Team should start taking that into account
(if they haven't already).

Good programs never stagnate; they either get better
or get eclipsed by something else. POV-Ray is maturing
into what will (hopefully) be true production class,
and that's a different environment than a bunch of
people writing raytracing code for fun. You don't
see Linus Torvalds getting upset when some commercial
enterprise makes money off Linux, because he's
happy just to have created it, regardless of
what happens after. He'd be upset if someone were to
wind up owning Linux, but the protections have
already been put into place to prevent that, I think.

Ray

Post a reply to this message

On Tue, 6 Apr 1999 17:09:48 -0700, "Ray Gardener"
<ray### [at] daylongraphicscom> wrote:

>Maybe we can borrow gcc's code here -- it's all open source, right?

GCC is GPL.  GPL is not compatible with the POV license.  In fact,
the POV license isn't even technically open source.

>As for Java, Perl, and any other interpretation system:
>I have to pass. No interpreter is fast enough; I need
>every last machine cycle available, when you consider that
>the code may need to be called for every pixel on the
>rendered image.

Java is nearly as fast as compiled code if you have a JIT.
Neither system is interpreted, though; they're both p-code
systems, just like older Visual Basic stuff.  

>Read the stuff about 'slope' in the SuperPatch docs.
>Pretty heavy; it may do everything I need. So when
>does this great stuff get merged into the offical POV?

I don't know which parts will be added, but a bunch of the
stuff in the superpatch will make it into version 3.5.

Post a reply to this message

On Tue, 6 Apr 1999 17:27:56 -0700, "Ray Gardener"
<ray### [at] daylongraphicscom> wrote:

>Good programs never stagnate; they either get better
>or get eclipsed by something else. POV-Ray is maturing
>into what will (hopefully) be true production class,
>and that's a different environment than a bunch of
>people writing raytracing code for fun. You don't
>see Linus Torvalds getting upset when some commercial
>enterprise makes money off Linux, because he's
>happy just to have created it, regardless of
>what happens after. He'd be upset if someone were to
>wind up owning Linux, but the protections have
>already been put into place to prevent that, I think.

There's nothing wrong with using POV for production work. The thing
they're trying to prevent is someone taking the POV renderer and using
it as the core of a commercial program.  It's sorta the same idea that
lies behind the GPL: this code was developed by lots of people over a
very long time, and many of the people involved donated their work for
the good of the community.  For that work to instead be used to line
the pockets of some unscrupulous person of corporation is anathema.

Now, I happen to think the GPL would do just as good a job of
protecting that investment as would the current license, except for
the clauses that prohibit specific parties from distributing POV.  But
it's not my program, so I don't get to decide that.

Post a reply to this message

Ray Gardener wrote:
> 
> Agreed, supporting all those CPUs is bothersome. But
> gcc does it, the templates are mature, and we can tweak

Does gcc support EVERY cpu?  The core of POV is supposted to be completely
platform independent (only the interface parts need to be changed to port
it to another system).  If someone invents a new CPU next week and they
make an ANSI C compiler for it, we could have a command-line version of
POV running on it in very little time.

Therefore any bytecode interpreter that is part of the core must also be
platform independent... JIT compilers could be extra for each system...
but the functionality would still exist for EVERY system.

-Nathan

Post a reply to this message