 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gerolf Ziegenhain <nomail@nomail> wrote:
> Is it possible to use povray as some kind of library? Such that it could
> 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 license
expressly prohibits that.
In Windows you can call POV-Ray using its extension mechanism (for
example Moray does that). In other systems I don't think there's much
choice.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Gerolf Ziegenhain <nomail@nomail> wrote:
>> Is it possible to use povray as some kind of library? Such that it could
>> 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 license
> 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.
Christoph
--
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <f0f6fg$esa$1@chho.imagico.de>, chr### [at] gmx de 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I would suggest to use megapov (command line version on windows).
You launch it from your program with no input file, but with the "-"
option in place of the input file. The you can feed it on the standard
input with the scene description.
You still have to generate the scene in SDL, but you save all the stuff
with temporary files.
I hope this helps.
Frederic
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
frfo wrote:
>
> I would suggest to use megapov (command line version on windows).
> You launch it from your program with no input file, but with the "-"
> option in place of the input file. The you can feed it on the standard
> input with the scene description.
That does not work. POV-Ray cannot read scenes from std input because std
input is not random access capable.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> writes:
> frfo wrote:
>>
>> I would suggest to use megapov (command line version on windows).
>> You launch it from your program with no input file, but with the "-"
>> option in place of the input file. The you can feed it on the standard
>> input with the scene description.
>
> That does not work. POV-Ray cannot read scenes from std input because std
> input is not random access capable.
>
> Thorsten
From the man page:
Parsing options:
I<input_file_name> or Input_File_Name=file
Specifies the input file to use. If the input file name is '-',
the scene description will be read from the standard
input. The
Odd that it cuts off like that, but there you go.
Ryan.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
EinarDogfin wrote:
> Thorsten Froehlich <tho### [at] trfde> writes:
>
>> frfo wrote:
>>> I would suggest to use megapov (command line version on windows).
>>> You launch it from your program with no input file, but with the "-"
>>> option in place of the input file. The you can feed it on the standard
>>> input with the scene description.
>> That does not work. POV-Ray cannot read scenes from std input because std
>> input is not random access capable.
>>
>> Thorsten
>
> From the man page:
>
> Parsing options:
> I<input_file_name> or Input_File_Name=file
> Specifies the input file to use. If the input file name is '-',
> the scene description will be read from the standard
> input. The
>
> Odd that it cuts off like that, but there you go.
The man page is simply outdated.
Thorsten, POV-Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> EinarDogfin wrote:
>> Thorsten Froehlich <tho### [at] trfde> writes:
>>
>>> frfo wrote:
>>>> I would suggest to use megapov (command line version on windows).
>>>> You launch it from your program with no input file, but with the "-"
>>>> option in place of the input file. The you can feed it on the standard
>>>> input with the scene description.
>>> That does not work. POV-Ray cannot read scenes from std input because std
>>> input is not random access capable.
>>>
>>> Thorsten
>> From the man page:
>>
>> Parsing options:
>> I<input_file_name> or Input_File_Name=file
>> Specifies the input file to use. If the input file name is '-',
>> the scene description will be read from the standard
>> input. The
>>
>> Odd that it cuts off like that, but there you go.
>
> The man page is simply outdated.
>
> Thorsten, POV-Team
It does work with simple scenes. It fails with scenes with macro.
I haven't experimented to find out the exact limit, but if the scene is
generated it should be possible to use only basic SDL (no macro, no
declare, ...). The parser would not need random acces and it would do
the trick.
I have a small ongoing project using this hack, but I've not spent
enough time on it to be able to be definitive on the subject.
Let me know if you try it.
BTW, Thorsten, please, don't remove this in the next version, even with
strong limitations is can be usefull.
Frederic
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
frfo wrote:
> It does work with simple scenes. It fails with scenes with macro.
Yes, it will fail with any scene where POV-Ray has to move around in the
input file.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> frfo wrote:
>> It does work with simple scenes. It fails with scenes with macro.
>
> Yes, it will fail with any scene where POV-Ray has to move around in the
> input file.
>
> Thorsten
Sorry to jump into an old thread, but it happens to fall in my interests!
I have been planning for a long time (and never put efforts to it) on making a
library to help make povray scenes.
My idea, to comply perfectly with the licence, was that the library(and its
executable) would generate the code and all files needed for the render,
including the .ini and would then call povray with a system() call(if this raise
too much problems, it can be omited so user will render manually); this way the
program assumes the user has installed povray in compliance to its license and
the program using povray would in the legal reality have no link with povray.
(And the website would just have a link to povray.org for downloading povray!)
This way the two projects are separate, and files are written to disk, can be
backed-up, version control, etc...
Back to the library, I was hoping to make something highly OO, in which you
would inherit and polymorph objects. My "big-cube" is a "scalable-cube" kindof.
What stopped me from working on this is that I started having maniac thoughts of
having it seemlessly compatible with opengl !! =)
This said, i have not much time & efforts to spend on hobbies, but if this
library is starting up then I'd really like to give a hand!
Simon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
