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