In article <4278cb12@news.povray.org>, nospam-
new### [at] deletethispovrayorg says...
> Jim Henderson wrote:
> > Just out of curiosity, is there a plan for a beta of a Linux build?
> > 
> > Kinda itching to get my hands on it to start playing with it (particularly
> > interested in MP support). :-)
> 
> builds for other platforms will most likely wait until the core code settles
> down. the changes necessary to get POV to the state where we can support SMP
> properly (we didn't want to do a hack) are massive, as will become clear when
> the source code is released. apart from the internal re-structuring needed
> for threading we have both logically and physically separated the front and
> back ends (frontend being the UI, backend being the renderer), which has
> changed the way that the platform-specific code integrates. As this work is
> not yet complete, it's probably better that we get it all done to avoid
> duplication of effort before other platforms follow.
> 
Would this imply that it may then become possible to use a more simple 
front end or even create one as a module that could one Windows be an 
ActiveX control or a Python app on Linux, etc? In other words, strip off 
the existing front end and make one that can be tied into another 
application, as long as appropriate information is provided to state that 
the backend is in fact POVRay when its first loaded? I mean the plugin 
system that is available and programs like Moray use is nice, but I felt 
it always did leave a bit to be desired in some cases.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Patrick Elliott wrote:
> 
> Would this imply that it may then become possible to use a more simple 
> front end or even create one as a module that could one Windows be an 
> ActiveX control or a Python app on Linux, etc? In other words, strip off 
> the existing front end and make one that can be tied into another 
> application, as long as appropriate information is provided to state that 
> the backend is in fact POVRay when its first loaded? I mean the plugin 
> system that is available and programs like Moray use is nice, but I felt 
> it always did leave a bit to be desired in some cases.

First of all a dynamically linked frontend and a stripped-down backend 
would violate the spirit and the letter of the current license - this 
has been explaind in depth in the past including the lack of possibility 
to simply change the license.

Apart from that what you wrote does not mention what you think would be 
possible by dynamically linking the POV-Ray backend with a different app 
that is not possible to do via stdin and stdout of the official version. 
  Note i am not saying such things don't exist but you have not 
mentioned any.  One thing i could think of is the possibility to pause 
and resume a render (without stopping it) but this would be quite simple 
to add by having POV-Ray interpret pause and resume commands from stdin.

BTW i just announced a program in tools.general that demonstrates how 
you can integrate POV-Ray into another program using these means.

Christoph

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

Post a reply to this message

Patrick Elliott wrote:
> Would this imply that it may then become possible to use a more simple 
> front end or even create one as a module that could one Windows be an 
> ActiveX control or a Python app on Linux, etc? In other words, strip off 
> the existing front end and make one that can be tied into another 
> application, as long as appropriate information is provided to state that 
> the backend is in fact POVRay when its first loaded? I mean the plugin 
> system that is available and programs like Moray use is nice, but I felt 
> it always did leave a bit to be desired in some cases.

Well, it's always been *possible* to do this, assuming one was willing to
modify the source :). However, if you mean, "will it be easier to do this",
the answer is that if we decide to make this interface available it would
indeed be easier.

however at this point I can't comment further on our plans along these lines.

-- Chris

Post a reply to this message

In article <d5ckfr$2s5$1@chho.imagico.de>, chr### [at] gmxde says...
> Apart from that what you wrote does not mention what you think would be 
> possible by dynamically linking the POV-Ray backend with a different app 
> that is not possible to do via stdin and stdout of the official version. 
> 
Well. The one advantage having something closer to a library than a 
stdin/stdout system has is being able to easily drop it into another 
application. You don't need to know as much about how and why it works to 
use a library. At worst you might need a wrapper for the language you 
plan to use. Stdin and Stdout aren't as universal as they should be, if 
they where people wouldn't have developed DCOM, Corba or other 
implementations for a different method of linking stuff together.

Of course, most of the problem wasn't just having POVRay sitting 
someplace else chugging away in its own window, so much as the lack of 
anyone trying to find out what all of the interfaces where good for and 
my almost nonexistent skill in C. Yeah, its possible to create a wrapper, 
etc. for 'other' languages, but if you don't comprehend the way they work 
in C you are out of luck with the rest too. Decoupling the frontend and 
backend means the backend 'could' be more like a library than a full 
application, which makes the interface between them less complex, doesn't 
require complicated plugins to sit as intermediaries, etc. Sort of the 
computer equivalent of interchangeable parts + fewer moving ones that 
might break. But that may just be how clueless I am about how any of it 
works in the first place. ;)

> BTW i just announced a program in tools.general that demonstrates how 
> you can integrate POV-Ray into another program using these means.
> 
Hmm. Will take a look.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Patrick Elliott wrote:
> 
> Well. The one advantage having something closer to a library than a 
> stdin/stdout system has is being able to easily drop it into another 
> application. You don't need to know as much about how and why it works to 
> use a library. At worst you might need a wrapper for the language you 
> plan to use. Stdin and Stdout aren't as universal as they should be,

I don't see any concrete example.  Note currently communication of 
POV-Ray via stdin and stdout is essentially one-way - the only input it 
recognizes is to pause after the render when pause is on and wait for a 
keypress.  But this can be changed of course.

> if 
> they where people wouldn't have developed DCOM, Corba or other 
> implementations for a different method of linking stuff together.

In a lot of cases these techniques are simply abused, often simply to 
obfuscate the communication (so 3rd parties have difficulties to develop 
replacements for one side of the communication, often made waterproof by 
using patented techniques in the communication).  But again a concrete 
example would be necessary.

Christoph

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

Post a reply to this message

In article <d5f596$2sl$1@chho.imagico.de>, chr### [at] gmxde says...
> In a lot of cases these techniques are simply abused, often simply to 
> obfuscate the communication (so 3rd parties have difficulties to develop 
> replacements for one side of the communication, often made waterproof by 
> using patented techniques in the communication).  But again a concrete 
> example would be necessary.
> 
Well, I don't write a lot of stuff, but the only real example I can think 
of is what Adobe Acrobat Reader does with something like IE. Where just 
because the 'file' being viewed is not recognized by the application that 
loaded it, doesn't mean it has to show up in a separate application. Same 
with imbedded video, etc. It might be nice for instance to add dynamic 
graphics, though obviously not animation, to a MUD, by adding some way 
for the client to 'imbed' POVRay, not just wait for it to finish then 
display the result. This was in fact what I was trying to work out when I 
last looked are POVRay integration issues. The fact that the only 
existing example where all a) incomplete and didn't use the features I 
would need to make it work and b) it was in C, buried the idea. Now, with 
Dual-core support, faster machines, etc. its even more reasonable an 
idea. After all, a mud deals in text, it could feed a SDL with changes 
for time of day, weather, etc. that are part of includes for the MUD + 
the SDL for the room being seen to do almost anything. Not a full 3D 
environment, but a 'major' jump up from a fixed picture, or worse 
multiple pictures for time of days, season, etc. I would love to try it, 
but POVRay as it stood tended to make even trying inconvenient. With a 
clearer interface, the whole 'visible' part could be stuck into a Lua 
based plugin for something like Mushclient on Windows or as some similar 
plugin for a client under Linux. To do it currently seems more 
complicated than that, but I may simply have even less of a clue what I 
am looking at than I know I do. ;) lol

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message