On Wed, Feb 6, 2013 at 4:43 PM, Richard Jones <r1chardj0...@gmail.com>wrote:
> > For a package that gives you low-level access, my recommendation is > > PyOpenGL. It's lower-level than PyGlet and much cleaner, I think. > > That's not quite right. PyOpenGL and pyglet exist at about the same > level architecturally. PyOpenGL does not provide an OpenGL context - > you need another library (like pyglet or pygame) to provide that. > While I have not used PyGlet extensively, that is not my impression. PyGlet, for example, provides a dedicated shader class, and an entire rendering backend. I do recall that there is some direct exposure of some OpenGL calls (particularly OpenGL 2 callbacks), but by and large I have seen PyGlet applications that do not touch a single line of GL. Conversely, PyOpenGL is a "binding" of raw OpenGL, with facilities for extensions. You will need to use these OpenGL calls to accomplish anything. There are a few helper classes (e.g. for VBOs), but the most complicated thing it provides IIRC is a testing framework. At any rate, I feel like PyGlet is a binding on top of OpenGL, but it's not meant to be used that way. While you can make direct GL callbacks, PyGlet encourages the use of their abstracting classes built on top of it. Whereas, PyOpenGL is just a binding, with maybe a few higher level classes added on top of it for convenience. Ian
