[Edu-sig] re: 3d in Python

[Mike C. Fletcher]

Arthur wrote:

> Dethe writes -

...

> 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. 

I'm somewhat surprised by this ("playing better") assumption.  OpenGL 
itself should, in general, operate properly without any significant 
problems based on whether a C++ or C extension is calling it (basically 
if you can get the extension to load in Python you should be fine).

PyOpenGL is programmed in C, of course, but unless you're actually 
trying to integrate into PyOpenGL itself (why?), or you're using, for 
instance C++ arrays/vectors or similar data structures instead of Numpy 
arrays (and passing them to PyOpenGL), it doesn't seem like it would be 
a problem (the OpenGL layer doesn't care how it's called, and the Python 
layer doesn't really care either).  Is there some history of C++ 
extensions causing problems with PyOpenGL? 

>> 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. 
>

Didn't know we were lagging, have been hearing a deafening silence from 
the Mac peoples regarding whether the current CVS version builds & runs 
without problems <shrug> *I* don't have one of those nice titanium 
powerbooks on which to test it ;) .

> 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. 

Don't know where the flexibility is (can't be PyOpenGL, I've been there 
for 5? years (eek!) or so, and you know how pig-headed I am ;) ).  I am 
certainly open to changes required to support compatibility, but to be 
quite frank, there is too much stuff in the PyOpenGL project as it is 
(really if OpenGLContext were not the only significant source of tests I 
have (and my own project so I can add to it) it would probably be broken 
out, (and GLE is already suffering from bit-rot due to lack of general 
interest AFAICS)).

PyOpenGL has the equivalent of .2 total active developers/administrators 
(my own time shared across numbers of projects, plus a little bit of 
Rene's time when he's able (though he did a considerable swack when he 
first came on board, he seems to have been hijacked by some project or 
another)).  Unless that situation changes (and it looks like I have a 
stable lead developer), I just don't have the resources to integrate and 
support another project.  Of course, suitors with trunks full of 
developers are more warmly received ;) :) .

That said, marketing is more subtle thing than merely living in the same 
project space on SourceForge.  There's no reason the PyOpenGL web site 
can't be pointing to other 3D Python projects, particularly those which 
"play well" with us ;) .  BTW, I'm considering doing a "3D Sumo" 
distribution for OpenGLContext (w/ mxTextTools + SimpleParse + Numpy + 
PyOpenGL + PIL + (OpenGL + GLUT&GLE)), this would be a piece-wise 
installer exe for windows, and a mega-RPM-set for Linux.  Still not sure 
how necessary it is, so still considering.

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

See my note above regarding playing better.  I have not examined 
VPython's architecture (yes, I know, bad Mikey), but the Python and 
OpenGL levels are fairly generic in PyOpenGL, they use regular pointers 
to Numeric arrays for most things which are not already built-in Python 
types.  There might be some problems with, for instance callback 
formats, but the PyOpenGL stuff just takes callable python objects, so 
as long as the python level is used from VPython I would think it would 
be fine unless shown otherwise :) .

>> 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? 

This may be an inappropriate suggestion, facing the same basic problems 
as the GLUT one, but the PyGame folks do a fairly good job of providing 
an OpenGL context (not to mention lots of other facilities).  They also 
give you complete control over the mainloop.  One downside, of course, 
is that they have no "WIMP" interface support, so your students have to 
write the entire interface code instead of being able to dump 
GTK/Tkinter/wxPython buttons onto a window to control their 
applications.  Not sure if the PyUI project ever got far enough to be 
useful that way.  The upside is that students are often more excited to 
work in a "game"-oriented environment, and there are already Python 
educational initiatives using PyGame (Pygsear, if I recall correctly).

Okay, enough of my blathering.  Enjoy all,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/