[Edu-sig] re: 3d in Python

[Arthur]

Dethe writes -


> That's probably a good thing.  If only it was to port it out of C++ to C 
> I'd be able to participate more.  Tracing through dozens of C++ files to 
> find where a method is implemented is one of my least favorite things.

Can't speak to C vs. C++.

What I am aeware of is the following:

I believe the VPython project has some funding, and there is at least 
one student proficient in C++ actively focused on it.

There is another student, I believe, in New Zealand, who is working on 
extending it, in interesting ways (it sounds like), I believe as part of 
some thesis work.  He has not released code yet.  I think he feels 
constrained until either his thesis work is complete and accepted, or 
until he gets some necessary premissions from his institution.  But he 
expects to be able to do so at some point.

Back to C vs C++.

It does seem to me that if ported as a pure C extension, there would be 
the possibility of VPython eventually included in the core distro.  Were 
it not for its semi-dependency on Numeric, I would be lobbying for that 
direction. But I wouldn't be surprised to see some multi-dimensional 
array capabilities in the core distribution in the not too distant 
future, so that a VPython in the core distribution could be a real 
possiblity.

As a bonus, the possbility could give me something new to fight with 
Guido about. ;)

Are you on the vpython-users list?  Things are pretty much in a kicking 
around ideas stage.  And you're sugestions - a pure C extension, "plays 
better" with PyOpenGL -  seem consistent with ideas that David Scherer 
has put out there.  Though it doesn't seem David is in a position to 
devote energies to implementation work. And as a practical matter, those 
who are, seem to be more C++ than C folks.  Though that issue has not 
been addressed head-on as far as I am aware.

The slated port to Boost is partly my doing, only in the sense that I 
pointed out that Paul Dubois, the CXX develper, himself points to Boost 
as a better alternative for new projects than his CXX library. And one 
of the goals of the port is not just to go from CXX to Boost, but to 
simplify and "dequirkify" the code some - making it more realistic for 
the project to go forward as collaberative, participatory  Open Source.

It also seems like it is going to be necessary to transition from 
Numeric to Numarray, and from gtkglarea (providing the OpenGL context 
for GTK, on Linux) to another library which is superceding it (this, 
again, being the general recommendation of the gtkglarea developer 
himself).  (Aha, GLUT, he says)

So there is much to be done just to stay even, in some sense. But I am 
getting confident that more than that will get accomplished.


> Yes, and I'd expect the same behaviour from VPython, whether it was part 
> of PyOpenGL or not.  I'd like to see it become part of PyOpenGL in part 
> because that is the closest thing to a standard for 3D in Python, and 
> gets ported to more platforms (although their support for OS X has been 
> lagging, it's still better than VPython's).  VPython could use GLUT for 
> its windows by default, eliminating a lot of code overhead in the 
> current version, but allow windows to be specified as wxWindows, 
> Tkinter, or whatever by overriding the default.

Again, please jump in on the list. There is more flexiblity in thinking 
there than had been.  Though, prelimininarily, I would probably be on 
the side of "plays better" with PyOpenGL, rather than "become part of 
PyOpenGL". And that is probably a more realistic shorter term goal.

Is the fact that PyOpenGL Swig, and VPython CXX, moving, it looks like, 
to Boost, an impediment to even a "plays better" status?

> 
> Actually, just making the default windows use GLUT instead of native 
> windows would make my life better (without becoming part of PyOpenGL) 
> because then I could compile and run VPython on OS X.

There are a number of distribution semi-nightmares arising out of the 
different windowing dependecies under Windows and under Linux. On the 
other hand GLUT doesn't seem to be part of the core Linux distros, nor 
part of Windows - so its does present something of a distribution 
problem.  I know Bruce Sherwood is trying to keep the distribution as 
simple as possible, but fighting something of an uphill battle in any 
case due to shifting sands. And since there doesn't, at the moment seem 
to be any really good and easy solution, maybe the GLUT solution is the 
lesser of "evils". And when one is talking aobut education and about 
graphics, it does seem unwise to short shrift Mac. So, yes, it seems to 
me like it should be brought up. I can do it, but you can do it with 
more authority.

In fact maybe the simplest way to bring it up is to copy vython-users on 
this exchange.

What do you think?
> 
> Well, I have a demo program for VPython, a collection of shapes that 
> show off vertices, edges, and faces for polyhedra and spirals.  It was 
> getting too big, and some of the shapes take a long time to load, so I 
> added a buttload of command-line flags.  Another approach would be to 
> add a control window with checkboxes and lists to select aspects of the 
> demo, but I didn't really want to take that on in the context of 
> VPython.  Your question gave me an "Aha!" moment, because if I wire the 
> VPython demo up to XML-RPC (or any other RPC-like mechanism), then I can 
> drive the demo from Tkinter, or a web page, or command-line access to 
> the running program.  So I'm going to try that.
> 
> I haven't had a running VPython for some time, since my hard drive 
> crashed a few months ago and I've been reluctant to install Fink and all 
> the other cruft needed to get VPython running on OS X under X Windows.  
> But I'll spend some time today to get it running, polish up the demo 
> (the code needs a bit of TLC), and wire up some remote features.   I 
> should have something to show by the end of the week.
> 
> Does that sound anything like what you're looking for?

Sounds delicious!

Art