POV-Ray : Newsgroups : povray.programming : ** Visual Basic ** Server Time
30 Jul 2024 02:26:28 EDT (-0400)
  ** Visual Basic ** (Message 18 to 27 of 27)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: DreamChaser
Subject: Re: ** Visual Basic **
Date: 15 Jul 1998 08:50:39
Message: <35ac978f.0@news.povray.org>
Wonder if it would work in Borland C++Builder?


Justin Rogers wrote in message <35a330d1.0@news.povray.org>...
>I have a Microsoft DevStudio Add-In that does POV-Ray...  Command
>highlighting and all the bells and whistles associated with VC5, VInterdev,
>and VJ++...
>
>--
>_____________________________________
>Justin Rogers, CEO DigiTec Web Consultants
>Personal Programmer and Web Consultant
>Email:  dig### [at] 3nnet
>DreamChaser wrote in message <3599e609.0@news.povray.org>...
>>Another thought.  Since POV files are just plain text files, you could
>write
>>your own editor.  save the file then load and render in POV, or call POV
>>(ShellExecute()) with the proper command line switches.  True this is not
>>what you (or I) would really want, but if your just learning VB then that
>>might be the best route.
>>
>>DC :)
>>
>>p.s.  I've worked with VB for a long time and I've just changed over to
>>Borlands C++ Builder.  If you are just learning programming, you might
look
>>into that.  BCB is based on the Delphi VCL (Visual Component Library) and
>>has done to C++ windows programming what VB did for BASIC windows
>>programming.
>>
>>p.s.s.  I've been playing with the idea of porting POV to BCB and made the
>>UI in about 2~3 hours.  I'm looking for the POV source code to see how to
>>merge the two.  Any thoughts about new UI options would be appreciated.
>>
>>
>
>
>


Post a reply to this message

From: Qman
Subject: Re: ** Visual Basic **
Date: 6 Dec 1998 19:44:46
Message: <366b24fe.0@news.povray.org>
Yea How about a object tree for easy editing of scene files.

>>>p.s.s.  I've been playing with the idea of porting POV to BCB and made
the
>>>UI in about 2~3 hours.  I'm looking for the POV source code to see how to
>>>merge the two.  Any thoughts about new UI options would be appreciated.
>>>
>>>
>>
>>
>>
>
>


Post a reply to this message

From: guygies
Subject: Re: ** Visual Basic **
Date: 18 Mar 2003 01:12:44
Message: <3e76b8dc$1@news.povray.org>
I've done this exact sort of thing before, having failed to find a quick
and efficient way to interface my VB programs to pov-ray( i.e. without
rewriting the source code in VC++ to operate as an ocx, which I'm not sure
would be cool with their licensing...)
	And I have to say that although it isn't a perfect solution, calling a
	shell on pov-ray isn't a total pain. Plus you can use the API to catch the
	window handle and send signals that way.  I always just stuck to writing a
	batch file and calling pov-ray with the right command line switches. It
	worked fine for specialized animation work.

	But I also have to agree, an easy ocx patch between vb and povray would be
	super awesome.

On 30-Jun-1998, "DreamChaser" <Dre### [at] spydeenet> wrote:

> Another thought.  Since POV files are just plain text files, you could
> write
> your own editor.  save the file then load and render in POV, or call POV
> (ShellExecute()) with the proper command line switches.  True this is not
> what you (or I) would really want, but if your just learning VB then that
> might be the best route.
>
> DC :)
>
> p.s.  I've worked with VB for a long time and I've just changed over to
> Borlands C++ Builder.  If you are just learning programming, you might
> look
> into that.  BCB is based on the Delphi VCL (Visual Component Library) and
> has done to C++ windows programming what VB did for BASIC windows
> programming.
>
> p.s.s.  I've been playing with the idea of porting POV to BCB and made the
> UI in about 2~3 hours.  I'm looking for the POV source code to see how to
> merge the two.  Any thoughts about new UI options would be appreciated.


Post a reply to this message

From: Rick [Kitty5]
Subject: Re: ** Visual Basic **
Date: 18 Mar 2003 03:36:31
Message: <3e76da8f@news.povray.org>
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

From: Greg Edwards
Subject: Re: ** Visual Basic **
Date: 18 Mar 2003 16:39:00
Message: <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

From: Rick Gutleber
Subject: Re: ** Visual Basic **
Date: 20 Mar 2003 08:35:54
Message: <3e79c3ba$1@news.povray.org>
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

From: Greg Edwards
Subject: Re: ** Visual Basic **
Date: 20 Mar 2003 18:56:08
Message: <1fggm8asjf9z5.1o2ma4whao9ug.dlg@40tude.net>
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

From: J  M  Rowlett
Subject: What POV-Ray needs to take on LightWave
Date: 30 Oct 1998 22:10:51
Message: <363a7fbb.0@news.povray.org>
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

From: Ronald L  Parker
Subject: Re: What POV-Ray needs to take on LightWave
Date: 30 Oct 1998 22:17:56
Message: <363a8119.6813711@news.povray.org>
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

From: Roland Mas
Subject: Re: What POV-Ray needs to take on LightWave
Date: 31 Oct 1998 00:42:02
Message: <m37lxhe15b.fsf@rpc66.acr.atr.co.jp>
"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

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.