OpenGLContext (was: Re: [Edu-sig] re: intro)

[Mike C. Fletcher]

Dethe Elza wrote:

> Mike C. Fletcher wrote:
>
>> I've been thinking about creating wrapper prototypes to provide the 
>> equivalent of the VPython environment as part of the OpenGLContext 
>> 2.0.0 beta process (the goal being, in switching to the scenegraph 
>> model, to provide all the nice features, such as transparency, 
>> culling, geometry-loading, and textures that are available in your 
>> average scenegraph engine).
>
>
> Wow, this sounds like exactly what I've been looking for!  Three 
> questions:  When will it exist?  Will it compile on OS X?  What's a 
> good entry point for learning OpenGLContext? 

OpenGLContext itself only includes a few very minor (and optional) 
extension modules which should compile without problem on any 
architecture where Python and Numeric Python can be compiled.  PyOpenGL 
2.0.1 (on which OpenGLContext is built) should compile on OS X (though 
the OS X peoples haven't yet contributed their deltas for building back 
to the core tree, there are binaries available (from fink, I believe)).  
I believe that mxTextTools is available for OS X, as should be FontTools 
(which should be completely portable) and PIL (common), so in theory, 
OpenGLContext *should* be OS X ready today with at least the GLUT 
context (wxPython and PyGame contexts should also work, but I'm not sure 
if the libraries are readily available on OS X), but I have no way to 
test that.

Regarding timelines, I'm planning to release OpenGLContext 2.0.0 beta 1 
this weekend, the major feature still being worked on for that is the 
system TrueType font support (finding and matching system fonts).  The 
beta process will probably be three or four months long, with the 
features of the core library just being enhanced/fixed and more demos 
and documentation added.  I would hope that preliminary support for the 
existing VPython mechanisms (excluding the "controls") would be a 
weekend's work.  Can't begin to guess when that weekend would occur, 
however, as I'm currently searching for a job.

I don't really have a good "entry point" document for learning 
OpenGLContext, beyond those on the web site:
    http://pyopengl.sourceforge.net/context/
    http://pyopengl.sourceforge.net/context/documentation.html
the NeHe conversions, in particular, are targeted at new OpenGL 
programmers.  They don't, however deal with the (VRML97) scenegraph 
engine.  I don't really have any user-focused documentation for that 
part of the system yet (the documentation there is targeted at those 
seeking to extend the scenegraph/learn OpenGL, rather than those trying 
to use the scenegraph as a stand-alone tool).

> I haven't been very vocal about this in the past, because 3D work is 
> very much hobby stuff for me and I haven't had a lot of time for 
> hobbies, but I would be willing to beta test and provide feedback on 
> OS X if it provides the features you describe. 

The current OpenGLContext engine provides all the features 
(transparency, Frustum culling, texture loading, geometry loading), it's 
just a matter of providing bridges to the VPython APIs, meshing the 
various animation mechanisms, etceteras.

>> Most of the complexity seems to be in providing the various controls 
>> (sliders, toggles, labels, etceteras), and in mapping the less 
>> rigorous scenegraph model (e.g. no separation for geometry, texture 
>> and material) into the more rigorous one.  Similarly, mapping the 
>> synchronous interaction mechanisms of VPython to the 
>> callback/asynchronous mode of OpenGLContext will take some effort.
>
>
> A lot of VPython's complexity appear (to me) to be in providing it's 
> own windowing code for each platform and handling threading issues.  
> These two things kept me from porting it to run natively on OS X.  
> Also, from the VPython list I gather their code organized in such a 
> way that adding textures or transparency would be a major overhaul.  
> Guess which 3 things top my wishlist for VPython or a VPython workalike? 

I would likely not do much toward creating GUI-library-specific 
windowing code, more likely I would work on an API for creating 
OpenGL-hosted controls (which would be generally useful to PyOpenGL 
developers) and use the existing cross-GUI OpenGL window code to host 
those in a separate window for the VPython-analogue API (as opposed to 
hosting them in an overlay layer, where a normal game-style engine would 
put them).

>> PyOSG is another approach someone might take that might be more 
>> useful, as it includes scene-sorting (and has more than one 
>> developer's efforts available).  It's targeted at being used (rather 
>> than at being a source of demo-code), so it would probably provide a 
>> better long-term platform for development.
>
>
> Is this a serious recommendation to avoid OpenGLContext? What are the 
> tradeoffs? 

OSG is a large project, it has large numbers of contributors, and is 
undoubtedly many times faster and larger than OpenGLContext.  
OpenGLContext was designed to be a source of sample code for students 
trying to learn OpenGL (and in particular PyOpenGL) programming, and 
only has a single development (me).  (For the most part) it works, but 
it isn't intended to be a professional quality scenegraph engine, it is 
a simplified sketch from which students can understand how scenegraph 
engines operate, and it is "tinkering friendly", as you can look under 
the hood without needing to switch languages.

PyOSG is a new project, but it does build on a very extensive C++ 
project, so once all the kinks are worked out of the binding, it should 
be a more stable long-term platform.  OSG is basically a rationalization 
and consolidation of scenegraph mechanisms, so you will see most 
scenegraph mechanisms available within it that you would ever want.  
That said, I'm not likely to work on it anytime soon, as it does not use 
PyOpenGL, and my primary need in the 3-D field these days is as the 
maintainer of PyOpenGL; i.e. needing sample and testing code to aid with 
PyOpenGL maintenance and education. 

If I were concerned primarily with creating new software for end-users, 
I would probably choose PyOSG, I just don't actually have that need at 
the moment.  The thing is, beyond the "control" set and the particulars 
of the threading model, VPython should be fairly easy to implement on 
top of any scenegraph engine, so I can consider providing a bridge API 
as a "demo of existing features", rather than a separate project.  I 
would imagine that the PyOSG developer (Gideon) would see the project 
similarly, merely a matter of translating the particular quirks of the 
VPython API to the particular quirks of the OSG engine.

Enjoy,
Mike

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