PyOpenGL 3.0.0 (final) Released
Written by
on
in
Snaking.
PyOpenGL is the traditional OpenGL binding for the Python language (Python 2.x series). This release is the first major release of the package in more than 4 years. PyOpenGL 3.x is a complete rewrite of the PyOpenGL project which attempts to retain compatibility with the original PyOpenGL 2.x API while providing support for many more data-formats and extensions than were wrapped by the previous code-base. It attempts to retain the "easy" approachable API of the original PyOpenGL bindings, focusing more on ease of development (both for client code and the library itself) than speed.
Build and installation has been dramatically simplified. It is possible
to work directly from a PyOpenGL bzr branch or to merely unpack the
package into your PYTHONPATH. To install from source and/or participate
in development:
bzr branch lp:pyopenglthen add the pyopengl/OpenGL directory to your PYTHONPATH. You can also download the source distributions from:
bzr branch lp:pyopengl-demo
http://pyopengl.sourceforge.net
and use standard distutils commands to install. PyOpenGL 3.x is already supported by the PyInstaller "exe" packaging utility, and can be made to work with Py2exe with inclusion statements.
PyOpenGL may be installed using the easy_install script if desired. There are no setuptools/package-resources dependencies in PyOpenGL 3.0.0 final. You can install PyOpenGL on supported platforms (currently Linux, Win32 and OSX) with the following if you have setuptools, PIL and Numpy installed:
easy_install PyOpenGLYou can then run the scripts in the PyOpenGL-Demo package.
easy_install PyOpenGL-Demo
PyOpenGL 3.x introduces package-level configuration flags which allow you to modify the behavior of the entire PyOpenGL package, e.g. by introducing extremely verbose logging, or turning off all error-checking to improve performance. Of particular note is a flag which allows you to disable APIs which have been deprecated by the ARB in OpenGL 3.0. Other flags allow you to control the trade-off between ease-of-use and
performance during the development and release process.
PyOpenGL 3.x provides access to the entire OpenGL 3.0 API, as well as most extensions which have been entered in the OpenGL extension registry. Commonly used extensions can have "Pythonic" wrappers written easily, and many of the commonly used extensions already have simplified APIs provided. It also provides wrappers for the GLUT, GLE and GLX libraries. The AGL and WGL modules are not provided with PyOpenGL 3.x, as most devs are using window-manager-based GL operations.
PyOpenGL 3.x provides a simple plug-in API that allows you to write data-format or platform plugins. These can be used to easily add "native" support for your array-friendly data-formats (vector classes and the like). There is a sample data-format plug-in which wraps the "Vertex Buffer Objects" extensions (in the OpenGL/arrays/vbo.py module).
PyOpenGL 3.x's documentation has been regenerated and the build process for the documentation has been updated so that it can be easily regenerated to include pointers to other Open Source PyOpenGL project's online code viewers. If you would like to add your project to the list of referenced projects, please contact the author with details of your
code viewer's url, code license and project name.
Notes in the reference documentation indicates the deprecated entry points for OpenGL 3.0. If you have a PyOpenGL code-base you should be looking at reworking the code in order to eliminate the use of "legacy" APIs before OpenGL 3.1 drivers become mainstream. At minimum you should be converting away from per-vertex operations and the use of display lists toward using array-based geometry.
You should expect a performance decline with the use of PyOpenGL 3.x versus PyOpenGL 2.x! PyOpenGL 3.x will have an accelerator module released in time to provide better performance, but the development method (ctypes) is inherently slower than the C (SWIG) method previously used. If your code is performance critical you should likely use the accelerator module when it becomes available. Also consider using the package-level configuration flags to remove "support" functionality as you near release, use of these flags can provide more than 2x speedup in most cases.
The 3.0.0 final release has a few bugs fixed from the previous 3.0.0c1 release. Users of the release candidate should upgrade. PyOpenGL 3.0.0 is intended for use with the Python 2.x series, porting to Python 3.x is not currently on the roadmap. There will likely be a PyOpenGL 3.0.1 release in the near future which will introduce a few more optimizations and likely will be synchronized with the first public release of the accelerator modules.
Since the release of PyOpenGL 2.x another common OpenGL binding for Python has become popular and may be an appropriate choice for your projects. The Pyglet project (http://www.pyglet.org) has a full OpenGL binding in "raw" C style, along with many higher-level utilities to aid in the development of games, all of which can be easily installed on common platforms.
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Brian on 04/01/2009 10:44 p.m. #
Looks good, thank you very much! Where can I find details on the package configuration flags?
Mike Fletcher on 04/01/2009 11:50 p.m. #
Docs are in the pydoc manual here: http://pyopengl.sourceforge.net/documentation/pydoc/OpenGL.html and in brief in the PyOpenGL for OpenGL programmers document here: http://pyopengl.sourceforge.net/documentation/opengl_diffs.html
I'm intending to add a number of other flags that will allow for e.g. turning off temporary array handling, storage of pointer values, etceteras to further claw back performance.
Rene Dudfield on 04/02/2009 12:12 a.m. #
congrats! Awesome job.
Anders on 04/04/2009 9:53 a.m. #
Sounds great. I guess that for PyOpenGL with the new ctypes interface the unladen-swallow plans are especially interesting
"LLVM in particular is interesting because of its easy-to-use codegen available for multiple platforms and its ability to compile C and C++ to the same intermediate representation we'll be targeting with Python. This will allows us to do inlining and analysis across what is currently a Python/C language barrier."
http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
Mike Fletcher on 04/04/2009 12:34 p.m. #
Yup, PyPy has shown that (r)ctypes interfaces can be used to type-annotate code such that a type-analyzer can produce almost-c-speed code when doing whole-program analysis. PyPy can target LLVM as well, incidentally, so we're very close technologies, the difference being between a hand-coded (easier, more limited) mechanism and an auto-generated (harder, more general) mechanism. Either way the presence of the type annotations should allow for a reasonable JIT to improve performance considerably.
fijal on 04/08/2009 11:04 a.m. #
That's not correct.
First, rctypes is gone in pypy by now, replaced by simpler mechanism. Second, rctypes never meant to include additional type annotations - it was using whole program analysis to deduce the types. You were just not allowed to mix them.
On the other hand, JIT is supposed to create good code for ctypes calls (direct calls) without type annotations. That's the whole point - you can observe what types are there at runtime, you don't need to have any kind of annotations.
cheers,
fijal
Mike C. Fletcher on 04/08/2009 11:17 a.m. #
My apologies. I've obviously not been following PyPy closely enough.