[Edu-sig] PySqueak: Which 3D package should I use?

[Paul D. Fernhout]

Well, I've finished a simple 2D proof of concept with prototype 
inheritance and some user interaction of dragging (using wx):
http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_010.py?view=markup
(Just dragging five related squares around, but shows basic prototype 
ideas in a Pythonic? style, i.e. initially you drag a parent and children 
move, then you drag a child and it no longer tracks the parent x,y as it 
has a private copy of x and y after dragging.)

So, now I'm thinking of making a simple 3D version. But what 3D library to 
use? This has been discussed here before, for example:
   http://mail.python.org/pipermail/edu-sig/2003-April/002789.html
but I wanted a current perspective three years later (if it has changed).

The (enviable) problem is that there is so much to choose from now! See 
this list for example:
  "A small collection (72 packages) of pointers to Python software for 
working in three dimensions"
  http://www.vrplumber.com/py3d.py
Which should I use from all of those 72 packages? Obviously, that depends 
on my needs.

In the past, we bundled our own 3D graphics engine (a 3D turtle) into what 
we wrote, but it does finally seem like 3D graphics are common place.  So, 
I want to go with the best current standard, and that seems to be OpenGL.

In the short term,  for PataPata (my PySqueak) proof of concept tests, I 
just want something 3D-ish that I know other people will have an easy time 
installing alongside their regular Python 2.3/2.4 distribution. First, I 
just want to put up some 3D objects that people can drag around. That's 
fairly simple. But later, I want to pop up GUI elements (menus, lists, 
editors) to support people doing Self-like things. That's harder.

So, here are the longer term needs:
* Python bindings (obviously :-)
* OpenGL based (to get hardware acceleration).
* Good current level of support and longevity.
* Easy installation and configuration on Mac OS X, Windows, and GNU/Linux.
* Existing support for at least the rudiments of GUI widgets in the 3D.
* Not a moving target. :-) [Though perhaps I could compromise on that 
point if it was very cool.]

I'm OK with it being complex as I plan on hiding that. I already know 3D 
graphics, e.g. have written my own 3D turtle and learned 3D on the SGI, 
though that was all many years ago, but still, I'm rusty.

License really doesn't matter to me as long as it is "free" in a FSF sense 
and can be in the "free" part of a Debian distribution.

Being lazy, and short on time, it would also be nice if it already easily 
handled issues like managing a world of 3D objects and knowing which was 
clicked on (and where). Here is an overview of that issue:
     http://pivy.tammura.at/documentation/pycon
That issue of easily displaying 3D objects and then mapping from mouse 
clicks back to what is clicked on are key to the application in the long 
term, if I were to emulate any of what Croquet can do.

It would be superb if it had widgets with openGL (lists, text, etc.) with 
Python bindings. Even for that, using GLUT, there are a few choices on the 
vrplumber page above. I have not used any such packages. I don't want to 
emphasize that too much though. I'm OK with working with simpler 
components. So it doesn't have to have everything. And it is possible I 
might just punt on that for now and have a separate 2D GUI for that sort 
of stuff. If displaying 2D widgets in 3D makes the selection of 3D 
graphics packages harder, even though Squeak has it, I'm OK right now even 
with a compromise that the 3D environment might have "control panel" 
objects that when you got close and clicked on them you got a separate 2D 
window in wx or TK on your system where you could do the usual GUI things 
(with sliders, etc.). In general, right now I'm fine with having a system 
that mixes 2D and 3D windows for different activities, though I'm sure how 
to do that best may be an issue, and I can see the merit of having 
everything in 3D to make it easier to share visible state across multiple 
users.

Anyway, I'm wondering if I should just go with PyOpenGL, or maybe the 
OpenGL Context, at the start, as being fairly easy to install with the 
least dependencies? (I already have that running on my Debian GNU/Linux 
machine, though with some issues.)

But other choices like VTK as a base or maybe even using Blender somehow 
certainly look intriguing. And, looking through recent discussions, maybe 
I should look harder at Soya, at the very least to get a sense of how they 
used various technologies?
   http://home.gna.org/oomadness/en/soya/index.html
(Looks like it is very Python oriented, but Tom Hoffman suggested it was a 
tougher install...) Still, there is so much to choose from. For example, 
"SLUT" addresses issues I'd have down the road with Croquet style networking:
   http://slut.sourceforge.net/
 From there: "Slut is a programming framework for generative, synthetic, 
interactive, network-enabled graphics." And from:
   http://slut.sourceforge.net/manual/index.html
"Knowing Slut means knowing Python, pyOpenGL, pyGame, Twisted and Slut 
itself. Python is the language. OpenGL is used to draw shapes. PyGame 
handles sound and the integration with the operating system. And Twisted 
does networking." But that seems like a small project.

Anyway, what 3D toolkits have people here had success with from a painless 
installation standpoint on typical current machines? And which ones do 
people think are here to stay with significant support and would feel good 
about using? Is plain pyOpenGL or even pyGame a "safe" choice?

So many difficult decisions; maybe I will just go back to expanding the 2D 
proof of concepts for a while... :-)

--Paul Fernhout