In article <f0f6fg$esa$1@chho.imagico.de>, chr### [at] gmxde says...
> Warp wrote:
> > Gerolf Ziegenhain <nomail@nomail> wrote:
> >> Is it possible to use povray as some kind of library? Such that it cou
ld
> >> directly be used from within a C program (whithout writing a text file
 with
> >> the scene ;). I want to use it for visualizing atomistic simulations.
> > 
> >   You can't link POV-Ray into your program directly, as the usage licen
se
> > expressly prohibits that.
> 
> Actually that's not precisely true, you cannot *distribute* a POV-Ray 
> version modified this way, nothing prevents you from doing this just for
 
> yourself (except that it will be a lot of work(*) and you would not gain
 
> anything from it).
> 
> (*) remember that the input file need to be searchable, therefore you 
> would have to create an internal buffer for it and modify the file 
> access functions to use this buffer instead.
> 
And as I fumbled around with a while back, its not infeasible, with the 
right constraints added, that you could "sort of" link it in, in the 
same way you might add a script engine. The requirements are that a) it 
can work as is, and b) that the fact you are using it isn't hidden. The 
only reason that linking it in isn't allowed is that it breaks one or 
both of those rules. But its not the only way you can link something. 
Mono or ActiveX could allow you to link it like a plugin, while still 
letting it run as a stand alone instance that works "as normal". That 
only breaks one of the rules then, that you can hide it. And as I 
pointed out in the other thread, if you force the developer to display, 
and prevent them hiding, the render window could be used to display the 
needed info on what is being actually being used.

Hmm. Lets use an example. There is IE and there is the "browser" object 
that lies at the core of I.E. Both use the same display, both conform to 
the same rules, can run the same script, etc. They are functionally 
identical to each other, save that one has its own window, and one lets 
you glue it to *your* window. You need on to use the other, so they are 
tightly bound to each other. Nothing the original does is effected or 
altered in any way by you using the simpler interface in the "browser" 
object to handle web pages. Why not do that with POVRay? Because, it 
breaks the, "show the license", rule. Now.. Lets say that the "browser" 
object, when it loaded, forced itself to stay visible for x seconds and 
auto loaded a page, built into the IE core, that showed the version 
number, the license and the copyright information. You couldn't avoid 
it. **Any** application using the object would have to display the 
information for x seconds, before it could go to a new page, or anything 
else, but it would only need to do it *once*, when you first initialized 
the object. Now it conforms to "both" rules. Its possible to run it as 
is, none of the functionality has changed at all *and* it shows the 
needed license information, etc., while "still" being embeddable.

How am I wrong? Other than that no one considered such a thing when 
stating that its not allowed?

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message