PySqueak: Which 3D package should I use?
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_01... (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
On 5/13/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote:
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...)
Actually, I'd forgotten that 'apt-get python-soya' works on Ubuntu at least (universe repository). I got into trouble when I tried to install from source to try some more bleeding edge features. So, to be fair, it isn't necessarily particularly difficult. --Tom
Tom- Thanks. apt-get install python-soya python-soya-doc just worked for me. Pulled in a bunch of stuff, but a few warnings though. Several FutureWarning but look OK. A few SyntaxWarning too. My default python is 2.3 so maybe that is it. "/usr/lib/python2.3/site-packages/soya/pudding/test.py:42: SyntaxWarning: import * only allowed at module level def test(debug = False):" Having some problems with tutorial windows locking up, like: http://home.gna.org/oomadness/en/soya_tuto/tutomodeling-1.html (which I paste into a Python prompt. :-) I can get a pyramid but the OpenGL window won't close, and I have to get out of Python (seems to tie up Gnome too, maybe their idle loop is using too much CPU? Pegs my system at 100%.). Seems like it will take some understanding (maybe that's what it is supposed to do?) So, not quite a painless out of the box experience -- not to say it is not worth using, just a datapoint on first few minutes difficulties and confusions. Still, I'm starting to lean to just using OpenGL under wx as a starter. I'm thinking that may have the least install problems for proof of concept stuff. [BTW, in the 2D realm under wx, I'm up to P.O.C. #12, with menus to add and remove morphs and tell them to do things.] Thanks again for the pointer. --Paul Fernhout Tom Hoffman wrote:
Actually, I'd forgotten that 'apt-get python-soya' works on Ubuntu at least (universe repository). I got into trouble when I tried to install from source to try some more bleeding edge features.
So, to be fair, it isn't necessarily particularly difficult.
On 5/13/06, Paul D. Fernhout <pdfernhout@kurtz-fernhout.com> wrote:
Tom-
Thanks. apt-get install python-soya python-soya-doc just worked for me.
Pulled in a bunch of stuff, but a few warnings though. Several FutureWarning but look OK. A few SyntaxWarning too. My default python is 2.3 so maybe that is it. "/usr/lib/python2.3/site-packages/soya/pudding/test.py:42: SyntaxWarning: import * only allowed at module level def test(debug = False):"
Having some problems with tutorial windows locking up, like: http://home.gna.org/oomadness/en/soya_tuto/tutomodeling-1.html (which I paste into a Python prompt. :-) I can get a pyramid but the OpenGL window won't close, and I have to get out of Python (seems to tie up Gnome too, maybe their idle loop is using too much CPU? Pegs my system at 100%.). Seems like it will take some understanding (maybe that's what it is supposed to do?) So, not quite a painless out of the box experience -- not to say it is not worth using, just a datapoint on first few minutes difficulties and confusions.
Still, I'm starting to lean to just using OpenGL under wx as a starter. I'm thinking that may have the least install problems for proof of concept stuff.
That's about as far as I got with it. My brief experience with Panda3d was more promising, but I also found both of these API's to be just too daunting. --Tom
Tom Hoffman wrote:
That's about as far as I got with it. My brief experience with Panda3d was more promising, but I also found both of these API's to be just too daunting.
Yes, I can see that now. If you really want all the features something like Soya provides then I can see there would be motivation to get through early hassles. But if you don't, it's hard to know if the investment is worth it given you don't know everything it can do until you see it in action. I'm really seeing the value of video on the web these days, in terms of being able to give quick overviews of what things do to motivate you to explore it on your own and get past the early problems. Those web videos are sort of a substitute for the old way of seeing new things in action by looking over someone's shoulder at the computer lab. :-). I'm up to POC #13 with a cleanup of menu handling definable by the prototypes (mostly a cleanup over #12, really), http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_01... and I'm thinking now I may still try to push forward with 2D a little more and hold off on 3D proof of concepts until I get a few more ideas or evaluations on good 3D crossplatform choices (thanks also go to Kirby). Probably the move will be driven more than anything by my repeated inability to get that darn wx flicker to go away under GNU/Linux! :-) Still, it might be an opportune moment to switch because I am starting to have to be concerned over text display and composite widgets, which is often more platform specific. --Paul Fernhout
So many difficult decisions; maybe I will just go back to expanding the 2D proof of concepts for a while... :-)
--Paul Fernhout
If just trying to do some quick and dirty proof of concept work, I'd go with VPython. The API is simple. No textures, not really OpenGL, but hey, that could come later. On the OpenGL front, I'm finding Panda3D very promising, works on Edubuntu, Windows, haven't tried it on Mac (I don't think it works there yet). I haven't looked into Soyo in any detail yet. If you do, please report back on your experience. I think writing directly to OpenGL through PyOpenGL will be too much work for rapid prototyping, though I may underestimate your productivity and skills. Kirby
participants (3)
-
kirby urner -
Paul D. Fernhout -
Tom Hoffman