guy### [at] charternet wrote:
> But I also have to agree, an easy ocx patch between vb and povray
> would be super awesome.

Second that
--
Rick

Kitty5 NewMedia http://Kitty5.co.uk
POV-Ray News & Resources http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

On Tue, 18 Mar 2003 08:35:55 -0000, Rick [Kitty5] wrote:

> guy### [at] charternet wrote:
>> But I also have to agree, an easy ocx patch between vb and povray
>> would be super awesome.
> 
> Second that

I can't stand visual basic but I still think it's a good idea. It could 
allow for "POV-Ray consoles" in other programs and web sites. If you're 
afraid about licensing issues you could add a watermark or something.

-- 
light_source#macro G(E)sphere{z+E*y*5e-3.04rotate-z*E*6pigment{rgbt#end{
20*y-10#local n=162;1}#while(n)#local n=n-.3;G(n)x}}G(-n).7}}#end//GregE

Post a reply to this message

What's the licensing problem?  I thought the POV-Ray license was quite
liberal in what you could do with it, as long as you distribute the source
to your special version.

"Greg Edwards" <edw### [at] hotmailcomremovethis> wrote in message
news:1prjy30hra8ck$.83kdilais87b$.dlg@40tude.net...
> On Tue, 18 Mar 2003 08:35:55 -0000, Rick [Kitty5] wrote:
>
> > guy### [at] charternet wrote:
> >> But I also have to agree, an easy ocx patch between vb and povray
> >> would be super awesome.
> >
> > Second that
>
> I can't stand visual basic but I still think it's a good idea. It could
> allow for "POV-Ray consoles" in other programs and web sites. If you're
> afraid about licensing issues you could add a watermark or something.
>
> --
> light_source#macro G(E)sphere{z+E*y*5e-3.04rotate-z*E*6pigment{rgbt#end{
> 20*y-10#local n=162;1}#while(n)#local n=n-.3;G(n)x}}G(-n).7}}#end//GregE

Post a reply to this message

On Thu, 20 Mar 2003 08:35:53 -0500, Rick Gutleber wrote:

> What's the licensing problem?  I thought the POV-Ray license was quite
> liberal in what you could do with it, as long as you distribute the source
> to your special version.
> 
> "Greg Edwards" <edw### [at] hotmailcomremovethis> wrote in message
> news:1prjy30hra8ck$.83kdilais87b$.dlg@40tude.net...
>> On Tue, 18 Mar 2003 08:35:55 -0000, Rick [Kitty5] wrote:
>>
>>> guy### [at] charternet wrote:
>>>> But I also have to agree, an easy ocx patch between vb and povray
>>>> would be super awesome.
>>>
>>> Second that
>>
>> I can't stand visual basic but I still think it's a good idea. It could
>> allow for "POV-Ray consoles" in other programs and web sites. If you're
>> afraid about licensing issues you could add a watermark or something.
>>
>> --
>> light_source#macro G(E)sphere{z+E*y*5e-3.04rotate-z*E*6pigment{rgbt#end{
>> 20*y-10#local n=162;1}#while(n)#local n=n-.3;G(n)x}}G(-n).7}}#end//GregE

By my understanding, if you call POV from an external program, you have to 
make it obvious that POV is being called. If you made a POV-Ray ActiveX 
control, you could silently slip a mini-POV-Ray into your program without 
mentioning it. This could enable users to steal the POV-Ray engine and call 
it their own super 3d program and not even admit that it was POV-Ray they 
were using. Very few people would take notice to an obscurely named OCX 
file that happens to be drifting in the directory.

-- 
light_source#macro G(E)sphere{z+E*y*5e-3.04rotate-z*E*6pigment{rgbt#end{
20*y-10#local n=162;1}#while(n)#local n=n-.3;G(n)x}}G(-n).7}}#end//GregE

Post a reply to this message

What would be really cool is, if the POV-Ray engine were a COM object, and
you fed it interfaces to other COM objects to render.  That way my script
parser and CAD software would simply expose shape and texture interfaces to
the engine, allowing me to embed the POV-Ray Engine anywhere, even a
WebPage.  This model should be flexible enough to allow me to aggregate
custom shapes and textures through the script parser or CAD software.  I
could even have a local Open-GL engine or remote renderer (using DCOM) ,
that I could hot-swap in my client App.

If you're interested and like to know details, email me.  I'd be more than
willing to join the group to do this.

Post a reply to this message

On Fri, 30 Oct 1998 22:10:52 -0500, "J. M. Rowlett"
<row### [at] andrewcmuedu> wrote:

>What would be really cool is, if the POV-Ray engine were a COM object, and
>you fed it interfaces to other COM objects to render.  

[snip]

Here's a relevant excerpt from the new POVLEGAL:

All executables, documentation, modified files and descriptions of
the same must clearly identify themselves as a modified and
unofficial version of POV-Ray. Any attempt to obscure the fact
that the user is running POV-Ray or to obscure that this is an
unofficial version expressly prohibited.

POV-Ray may not be linked into other software either at compile-
time using an object code linker nor at run-time as a DLL,
ActiveX, or other system. Such linkage can tend to blur the end-
user's perception of which program provides which functions and
thus qualifies as an attempt to obscure what is running.

To allow POV-Ray to communicate with outside programs, the official
versions of POV-Ray include several internal communication "hooks" 
for it to call other tasks, often called an Application Programming 
Interface, or API. For example: the generic part of POV-Ray provides
operating system shell-out API commands. The Windows version has a 
GUI-extension API and the ability to replace the text editor.
Modification to these APIs or other officially supported
communication mechanisms to increase functionality beyond that of 
the official version IS EXPRESSLY PROHIBITED.

Post a reply to this message

"J. M. Rowlett" <row### [at] andrewcmuedu> writes:

> What would be really cool is, if the POV-Ray engine were a COM object, and
> you fed it interfaces to other COM objects to render.  That way my script
> parser and CAD software would simply expose shape and texture interfaces to
> the engine, allowing me to embed the POV-Ray Engine anywhere, even a
> WebPage.  This model should be flexible enough to allow me to aggregate
> custom shapes and textures through the script parser or CAD software.  I
> could even have a local Open-GL engine or remote renderer (using DCOM) ,
> that I could hot-swap in my client App.

Man, you can already do this, quite simply really:
script-generator | povray -i- -o- | image-processor-or-whatever

Roland.
-- 
Les francophones m'appellent Roland Mas,
English speakers call me Rowlannd' Mass,
Nihongode hanasu hitoha [Lolando Masu] to iimasu.
Choisissez ! Take your pick ! Erande kudasai !

Post a reply to this message