Greetings!

My experience with POVRay is all of about four hours long, so forgive me
if I jump right in and make a fool of myself.

History...

I'm a big fan of Perl and use it whenever and wherever performance is
not a crucial issue.  A web-based game I have been working on for years
(a space opera) uses Perl extensively, and is getting to the point where
I need to generate visual feedback for players (above and beyond the dry
statistics inherent in such a project).  Enter POVRay.

Since the game is verging on the grand-strategic, real-time combat is a
non-issue.  User-customisable AI govern tactical command and the players
only get to see the results of their subordinates' efforts.  My
intention is to use the combat logs to generate a QuickTime movie of the
battles - in a similar vein as Visual Combat Recordings in VGA Planets. 
I'd use Perl to coerce the logs into battle.pov and battle.ini files,
and then invoke POVRay to do the rest.

Point...

The POVRay Mac OS Read Me says plans are afoot to "Completely rework the
application model... POV-Ray engine should be a simple rendering
application,  separate from the UI.  This could pave the way to use it
as a rendering plugin for QD3D or modeling  applications, and for
network rendering farms."  All I'd like to say is that I am STONGLY IN
FAVOUR of this approach.

Whenever the UI is tightly coupled to the functionality of a program,
flexibility is lost.  Bryce is a classic example - an otherwise
brilliant work confined by a staggeringly rigid UI.  I'd prefer the same
mistake not be repeated with POVRay.

The normal response by Mac developers is to make an application
"scriptable".  Now AppleScript is fine and dandy when it comes to
automating repetitive processes, but that's *not* what is required by
POVRay.  There are precious few repetitive tasks in setting up a scene,
and macros would seem to address the issue quite adequately when it
comes to multi-frame movies.

What, then, is the point in investing time implementing robust
AppleScript support in the Mac version?  Very little, if you ask me.  My
suggestion would be to only implement the most minimal AS Dictionary -
enough to open an arbitrary .pov file (which should trigger reading of
the associated .ini file) and report back a standard result code along
with a string containing much of the statistical information that is
currently returned to STDOUT.

Not only does this mean that POVRay remains flexible, but it means that
there is that much less difference between the Mac version and the
Unix/Windows versions - and that can only be good from a maintenance
point of view.  I can think of a lot of better things to do with time
than maintain marginalised AppleEvent-handlers which Apple seem
hell-bent on breaking every so-often.

That's about it.  Go right ahead and divorce the interface from the
engine, but don't spend significant amounts of time supporting a second
control method - you've already got one.

Ciao.

Henry.

Post a reply to this message

In article <38CAE718.66F06330@mac.com> , Henry Penninkilampi <htp### [at] maccom>
wrote:

> Greetings!
>
> My experience with POVRay is all of about four hours long, so forgive me
> if I jump right in and make a fool of myself.

No problem.

> The POVRay Mac OS Read Me says plans are afoot to "Completely rework the
> application model... POV-Ray engine should be a simple rendering
> application,  separate from the UI.  This could pave the way to use it
> as a rendering plugin for QD3D or modeling  applications, and for
> network rendering farms."  All I'd like to say is that I am STONGLY IN
> FAVOUR of this approach.
>
> Whenever the UI is tightly coupled to the functionality of a program,
> flexibility is lost.  Bryce is a classic example - an otherwise
> brilliant work confined by a staggeringly rigid UI.  I'd prefer the same
> mistake not be repeated with POVRay.
>
> The normal response by Mac developers is to make an application
> "scriptable".  Now AppleScript is fine and dandy when it comes to
> automating repetitive processes, but that's *not* what is required by
> POVRay.  There are precious few repetitive tasks in setting up a scene,
> and macros would seem to address the issue quite adequately when it
> comes to multi-frame movies.

Hmm, I think you misunderstood our idea of AppleScript support here: It is
about controlling the application to start renders, open files for editing,
etx - the usual stuff.  We never wanted to do anything else, the part that
does the parsing and rendering in POV-Ray is cross-platform and separate
from the different GUIs in any possible way.

> What, then, is the point in investing time implementing robust
> AppleScript support in the Mac version?  Very little, if you ask me.  My
> suggestion would be to only implement the most minimal AS Dictionary -
> enough to open an arbitrary .pov file (which should trigger reading of
> the associated .ini file) and report back a standard result code along
> with a string containing much of the statistical information that is
> currently returned to STDOUT.

POV-Ray 3.5 will be a recordable application.  AppleEvents are a very good
method when it comes to designing a new application (the Mac 3.5 frontend is
a full rewrite).  If properly implemented this creates a much more logical
and simpler separation of the GUI code and the actual data access.

> Not only does this mean that POVRay remains flexible, but it means that
> there is that much less difference between the Mac version and the
> Unix/Windows versions - and that can only be good from a maintenance
> point of view.  I can think of a lot of better things to do with time
> than maintain marginalised AppleEvent-handlers which Apple seem
> hell-bent on breaking every so-often.

Hmm, I have no recollection of Apple ever breaking any Apple Event code.


     Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message