Nieminen Mika wrote in message <6isnom$f7d$2@oz.aussie.org>...
>Mark Arrasmith (arr### [at] mathtwsuedu) wrote:
>: Also, is there any plan to make POVRay cross platform with its GUI?
>
>  As long as there is always a little command line version available!
>  I don't want guis growing the file size where it's not necessary.


IMHO, PovRay should be cut in two parts :

-  A highly portable PovRay Engine (PRE) :
When possible (most plateforms), it would be a DLL / Shared Library. On
others, static library.
It would enable easy and better integration with front-ends (shells,
modelers, texture editors, render farms, etc), for preview and final
rendering.

From version 3.0 code, at first look, it's seems not very hard work
(definition of officials APIs for calling PRE and setting callbacks for
handling POV_BANNER & Co, POV_DISPLAY_Xxxx, POV_SYSTEM).
In fact, I've already compile for personnal tests an unofficial PovRay
engine DLL for Win32...
A second look and the bad news is, today, PovRay 3.0 code isn't thread-safe
(many globals variables) !
Perhaps a welcomed next major version (4.0?) rewritten code will help this
particular point.

PRE development is obviously the POV-Team main focus, and should continue to
be.
An open (plugin-able) engine would be better...

- PovRay Shell(s), calling the PRE APIs :
An obvious and portable one (except for MacOS!?) is a little command line
shell. Any PovRay distribution should (and already) include this shell (even
if a GUI shell exist).
More sophisticated shells could be with GUI, like the Windows or MacOS
today's one.

With officials PRE APIs, more shells would be available than today. Most
plateform-specific, some cross plateform.
With same officials PRE APIs, more high front-ends could use PovRay.
Directly.

Just some suggestions for the future of PovRay developpment...

Thanks for reading.
And sorry for poor english...

Phil.

Post a reply to this message

>Yeah, I can always bolt on my own interface to the command line version.  It
>just that I wish the GUI Win32 version would compile on Win32 machines, from

As far as I am aware it should be able to. One of the reasons we went to a lot
of trouble to write the thing in C (and make the editor a optional loadable
DLL) was so it would be portable across Win32. I'm sure it won't compile out
of the box but it shouldn't be too hard.

>Cyrix to Alpha.  Which means no x86 specific stuff.

Can you please point me to the x86 specific stuff that you are referring to ?
Be sure to exclude any of the optional things like the editor and the ztimer
library ; they are not essential to building POVWIN.

Post a reply to this message

>-  A highly portable PovRay Engine (PRE) :
>When possible (most plateforms), it would be a DLL / Shared Library. On
>others, static library.
>It would enable easy and better integration with front-ends (shells,
>modelers, texture editors, render farms, etc), for preview and final
>rendering.
>


I'm starting work on an ActiveX version of PoV just for the purpose of
easy integration to front ends.  I think the Window's version of PoV is
bloated-  who wants to download a 4M rendering engine that should
be ~1M.  What should have been done was an ActiveX./DLL
version as you suggested, and if someone wants to add an editor, modeler,
everything but the kitchen sink, front end, then they can easily add the PoV
rendering engine by using the ActiveX control/DLL.

Is there much interest by other developers for this ActiveX control?
It would have a bunch of methods/properties that would allow
you to set the rendering options, fire off the rendering into your window,
then notify you that its done rendering.

I know I could use the GUI extensions already built into the Windows
version,
but its much nicer not to have PoV startup as a separate application.

    Jeff

Post a reply to this message

Philippe Houdoin <phi### [at] ouest-francefr> wrote in article
<6iuebt$hho$1@oz.aussie.org>...
> Nieminen Mika wrote in message <6isnom$f7d$2@oz.aussie.org>...
> >Mark Arrasmith (arr### [at] mathtwsuedu) wrote:
> >: Also, is there any plan to make POVRay cross platform with its GUI?
> >
> >  As long as there is always a little command line version available!
> >  I don't want guis growing the file size where it's not necessary.
> 
> 
> IMHO, PovRay should be cut in two parts :
> 
> -  A highly portable PovRay Engine (PRE) :
> When possible (most plateforms), it would be a DLL / Shared Library. On
> others, static library.
> - PovRay Shell(s), calling the PRE APIs :
> An obvious and portable one (except for MacOS!?) is a little command line
> shell. Any PovRay distribution should (and already) include this shell
(even
> if a GUI shell exist).
> More sophisticated shells could be with GUI, like the Windows or MacOS
> today's one.

	From what I've seen, I believe the Windows version of 3.1 will be like
this ! I can't confirm this, as I don't have CompuServe access, but, if
it's true, it's definitely a step in the right direction.

-- 
Scott Hill
Sco### [at] DDLinkscouk
Software Engineer (and all round nice guy)

"The best trick the devil ever pulled was convincing people he didn't
exist..."
								- Verbal Kint.

"the Internet is here so we can waste time talking about nothing in 
 particular when we should be working" - Marcus Hill.

Post a reply to this message

povray.org admin team wrote in message
<355306ea.39651135@news.povray.org>...
>Can you please point me to the x86 specific stuff that you are referring to
?
>Be sure to exclude any of the optional things like the editor and the
ztimer
>library ; they are not essential to building POVWIN.

Well now I have to look stupid here.  There was a discussion here at the
povray newsgroups about getting POVRay Win32 to compile under Alpha awhile
back.  My problem is that I am not speaking from my own experience.  (My
Visual C++ Risc Edition will not arrive until next week)

If I remember right the problem was with a dll or maybe several dll's that
were not available under the AlphaNT platform.  A Borland Delphi dll I
think.

Sorry if I was an ass about this.  I'll ask those that have actually tried
this to give a more complete answer.  And when my VC++ shows up I'll see
what the problems are firsthand.

Since you did mention the editor and ztimer I'll try to work around them.
You know building vim 5.0 as the editor would be kind of cool, with color
syntax and everything.

Mark Arrasmith
arr### [at] mathtwsuedu

Post a reply to this message

>Is there much interest by other developers for this ActiveX control?
>It would have a bunch of methods/properties that would allow
>you to set the rendering options, fire off the rendering into your window,
>then notify you that its done rendering.


I'm interested!!! Sound VERY cool.. Maybe set up Web support? So the people
can call it from a webpage, when they go to a site with a .POV file? =P

>I know I could use the GUI extensions already built into the Windows
>version,
>but its much nicer not to have PoV startup as a separate application.


I can DEFINATELY agree with that. It's quite hard, especially in VB5, to
monitor an external app like Povray, and see if it's finished.

>    Jeff


Twyst

Post a reply to this message

Philippe Houdoin <phi### [at] ouest-francefr> wrote:

> Perhaps a welcomed next major version (4.0?) rewritten code will help this
> particular point.

Another small problem is that (I read somewhere) povray version 4.0 will
be written in C++ which makes it a little bit more difficult to make
sharedlibraries of it on some plattforms. The reason for this is that
there is no widely addopted standard for how the name mangling should
be performed. Ie my MrC compiler and my Codewarrior compiler creates
different symbols (for the linker) for the same function. I would expect
this to be a problem also on other plattforms. Am I right?
I know that this is easy to overcome (Mix C and C++), but in a portable
way?

> An obvious and portable one (except for MacOS!?) is a little command line
> shell. 

You can make shell tools for the Mac too. Either for a real shell like
MPW (which many Mac developers use) or use a simple library
to simulate a shell in your program. (Ie creates a simple window and 
routes stdio,stdout and stderr to it without a single line of program
code).

/ Mathias Broxvall

Post a reply to this message

>If I remember right the problem was with a dll or maybe several dll's that
>were not available under the AlphaNT platform.  A Borland Delphi dll I
>think.

The DLL you are referring to is the Editor. It is not essential to the programs
operation.

Post a reply to this message

>I'm starting work on an ActiveX version of PoV just for the purpose of
>easy integration to front ends.  I think the Window's version of PoV is
>bloated-  who wants to download a 4M rendering engine that should
>be ~1M.

Get your facts right. Most of that 4m is docs and misc files. PVENGINE itself
is 1.4m total. Your claim that the 'rendering engine' is 4m is misleading and
could put people off using POVWIN if they haven't already tried it.

>What should have been done was an ActiveX./DLL

'Should' by your standards perhaps. Active X didn't exist at the time (as you
should well know) and we won't use a DLL because it allows POV-Ray's renderer
to be too easily subverted by leechware.

Really, if you want a DLL-based renderer, why don't you simply write your own ?

Post a reply to this message

Ok.  I'll try to get povwin to compile without the editor and ztimer
library.  Is there anything else I should look for?  And, any hints on
replacements?

Mark

povray.org admin team wrote in message
<35543cdd.25997502@news.povray.org>...
>>If I remember right the problem was with a dll or maybe several dll's that
>>were not available under the AlphaNT platform.  A Borland Delphi dll I
>>think.
>
>The DLL you are referring to is the Editor. It is not essential to the
programs
>operation.

Post a reply to this message