More thoughts, this time about implementing Visual Python
on top of a scene graph API.
This I don't think is a good idea, for technical reasons and
for a more stylistic reason of who Visual Python is meant for.
I'm writing my own Python 3D toolkit for virtual reality and
visualization, based on the SGI Performer scene graph API.
(Yeah I know SGI have gone bankrupt, it's the reason I happen
to be thinking a lot about Python and scene graphs just now.)
This gives me some experience and/or bias which I think is
useful.
Technically, it introduces a major dependency on another
piece of software. I wrote in my last message that VP is
great because you can download the binary and it Just Works.
I'm not at all sure this could be done if VP required a
scene graph. They're large, complicated bits of software
under constant development.
From my experience, I could just about offer a binary version
of my Python scene graph toolkit for SGI IRIX, because it's
a commercial OS that always ships with the scene graph libs.
For Linux, I have to tell people to first install Performer,
then compile and install my Python toolkit. MacOS or Windows
wouldn't be any better, because neither has a standard scene
graph API.
A scene graph would almost certainly require a major rewrite
of Visual Python. OpenGL has succeeded because it's low level
and very flexible, without forcing you to write programs in
a particular way. The price is no window management, event
handling, picking, etc.
Scene graph APIs provide a lot more features, but they also
require you to write your code to match their style. They
have to, large interactive 3D systems are really complicated.
As I'm finding out, once you've committed to a scene graph
API, it's difficult to switch.
The rewriting might even have to extend to Visual Python
code, not just the implementation. In the current version,
as shown by all the demo programs, the main control loop
and event loop is written in Python. The scene graphs I know
all have an internal frame loop with event callbacks, and
you have to write the Python code in the same style as PyGTK
or wxPython. It's not difficult, but it isn't how Visual
Python currently works and users would have to adapt.
Which brings me to my second reason, is Visual Python meant
for the kind of people who use scene graphs?
A scene graph like Performer is a big complicated library for
people who want to build big and frequently complicated 3D
systems. We want to do wierd things, to tweak and tune for
maximum performance, and this means exposing all the knobs
and levers. We are, in short, speed freaks who willingly put
up with the extra complexity.
This is why I didn't use Visual Python as the basis for my
own toolkit. I think VP is a wonderful tool for scientists,
mathematicians, and students. I'd hate to spoil it by adding
on a ton of features that I'd find useful but they would not.
Which is not to say it's impossible to move smoothly from
Visual Python to a full fledged scene graph. Maybe it can be
done. But I'd be very careful about it.
--
Hugh Fisher
DCS, ANU
PS. For anyone interested in looking at my 3D Python toolkit,
<http://cs.anu.edu.au/~hugh.fisher/py3d/>
For either an introduction to just how complicated a scene
graph can be even in Python, or an example of how NOT to do
it :-), have a look at
py3dview/py3dview/Doc/
which is the HTML reference pages and a mini tutorial for
Python programmers, and
py3dview/py3dview/Demo/
has a bunch of little demonstration and testing programs.
Needs a Linux or IRIX system with Performer if you actually
want to build and run the thing.
|
