[Edu-sig] PyGeo vs PovRay

[David Scherer]

> Leaving the issues of implementation behind for the moment, in a
> perfect world we want the interactivity of PyGeo/OpenGl with the
> quality of PovRay.

In support of our effort to integrate Python with the physics curriculum
here, I am working on a Python visualization library which aims to provide
both high rendering quality and "automatic" interactivity to Python
programs.  The interface aims at allowing the user to write "zero graphics
code" by making the graphics primitives useful data structures.  For
example,

from visual import *

ball = sphere()
ball.momentum = vector(10,0,0)
ball.mass = 3.0
dt = 0.1

while 1:
  ball.position = ball.position + ball.momentum/ball.mass*dt

'momentum' and 'mass' are attribute names invented by the user - any names
could be used.  Python's __getattr__ and __setattr__ mechanism allows me to
make changing the ball's built-in 'position' attribute actually move the
ball on the screen in real-time.

At present, I am working with a prototype implementation which, like PyGeo,
uses PyOpenGL for rendering.  Once we are satisfied with the interface, I
plan to re-implement the library with a custom graphics engine in C++, which
will probably use OpenGL directly to render polygons (if it's good enough
for Quake 3... :).  Although it obviously won't be a raytracer, the presence
of an engine written by knowledgable graphics coders in a fast
implementation language makes all kinds of powerful rendering techniques
available.  For example, the engine could transparently do stereo rendering
with anaglyph or shutter glasses, replace lines with shaded cylinders or
alpha 'trails', interpolate curves for added detail, or reduce unnecessary
detail in order to maintain a high frame rate.  It could also support
advanced primitives like height and even volume fields at interactive frame
rates.

The internals of the graphics engine aren't intended to be exposed to the
beginning coder, any more than the internals of the Python interpreter or
the OpenGL library itself are.  I don't see that as a problem - you have to
draw the line at *some* level of abstraction.

> Since that is impossible (at least with our resources) the next best
> thing is to be able to debug with lower (graphical) quality higher
> speed interactive tools and then do hardcopy with PovRay.

For our purposes, animation and even interactivity are very important, so we
haven't seriously considered a non-real-time back end implementation, but
the level of abstraction of the interface is already adequate to make this
possible.

> Another disadvantage of such an approach is that it is a lowest common
> denominator kind of thing. Adding features gets harder because they
> have to be implemented and debugged in both backends.

Indeed.  In fact, even releasing a prototype makes it harder to make changes
because you instantly have a group of users who are used to the "old way."

I think it's a good idea to "let a thousand flowers bloom" at the moment.
There are all kinds of ways that separate efforts could be integrated
later - for example, PyGeo is an interactive 'application' that could easily
run on top of my library instead of PyOpenGL and enjoy both simpler code and
better rendering quality.  A "dump screenshot to povray" feature could then
be added to my library, and you would have the best of all worlds.

Dave