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