PyOpenGL 3.0.0c1 Available for Testing
Written by
on
in
Snaking.
This baby has been cooking for way too long. If there's no show-stoppers reported, PyOpenGL 3.0.0c1 should be the same as the final release. The only big change from the last beta is that it now includes GLUT and GLE implementations packaged as data-files for Win32 deployments.
3.0.0 is a complete rewrite of PyOpenGL using the ctypes library. It has a number of small incompatible changes, can use numpy arrays, has pluggable support for other data-format types, provides access to most modern extensions and core OpenGL up to 3.0. PyOpenGL 3.0 has not yet been tested with Python 2.6, and definitely will not work with Python 3.0. You should expect a small slowdown with PyOpenGL 3.x, as the ctypes based wrapping system is inherently slower then the SWIG system used in the 2.x series.
If you are using deprecated functionality (such as using individual calls for vertices, colours and the like) you may find PyOpenGL 3.x unacceptably slow. You should convert your code to use array-based drawing (or vertex buffer objects), as OpenGL 3.1 and beyond are intending to drop support for the legacy APIs.
Downloads of .tar.gz, .zip and .exe installers are available.
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Mike C. Fletcher, the VRPlumber, is a philosopher of design turned computer programmer based in Toronto, Canada. He works primarily in the Python programming language, and maintains a large number of Open Source software packages. You can reach him at: mcfletch@vrplumber.com.
Pascal Giard on 02/24/2009 10:23 p.m. #
Hi, i'm one of the FoFiX developer and we use pyopengl extensively. Maybe not always in the cleanest fashion.
That said, as you mentioned it, we expected a small slowdown factor going from pyopengl 2.x to 3.x.
There are two things that disturb me.
The first one being that get half[!] of the framerate.
The second one is that converting direct mode rendering to array-based vertices/colors/texture drawing, not only does not help but, it makes things worst!
There must be something i'm missing...
Please have a look at this diff [1].
With py2.5 pyopengl3.x, the left side is faster than the right side.
Any help appreciated, thanks!
[1] http://code.google.com/p/fofix/source/diff?spec=svn1098&old=1048&r=1095&format=side&path=%2FMFH-Mod%2Ftrunk%2Fsrc%2FFont.py
Pascal Giard on 02/24/2009 10:38 p.m. #
Forget #1, that's when passing from python2.4 to 2.5.
But #2 remains...
Please see a small framerate plot:
http://i39.tinypic.com/2vvjg2e.png
Mike Fletcher on 02/24/2009 10:51 p.m. #
Note that what you've done there isn't what "using the array interfaces" is about.
While it would technically prevent OpenGL 3.1 deprecation from causing your code to fail, you're still drawing each face individually (and now you've got the array overhead as well).
The array (and VBO) interfaces only become useful when you push large numbers of polygons in a single data-set. That is, you create an array with *all* of your polygons and tell OpenGL to render the whole array with a single call.
PyOpenGL 3.x will unquestionably be far slower than 2.x on per-vertex/per-poly rendering, but that's exactly the stuff that's deprecated at the OpenGL level.
I'm actually just sitting down and writing my PyCon 2009 presentation on the need to move code from old per-vertex/per-poly rendering.
Pascal Giard on 02/24/2009 10:59 p.m. #
Oh! I think i got you. In our case that'll require alot of changes tho...
Thanks for answering!
PS: Please let me know when you'll make your presentation available.
Mike Fletcher on 02/25/2009 12:04 a.m. #
No problem, in fact you validated the core point of the presentation that I was (trying to) write, namely that OpenGL 3.1 is going to break just about every PyOpenGL package/library ever written.
Moving to OpenGL 1.1 (array based rendering) gets you about 90% of the way to Vertex Buffer Object usage, which is as high-performance as you can get these days.
Display-lists going away is really just a side-show (if you can't do per-vertex operations then display lists don't make much sense).
The elimination of fixed-function materials, lighting, etc is a bit trickier to get around *easily*, but it's mostly just a matter of having some handy-dandy tool that spits out fixed-function equivalent renderers (there's already one of those available).
Anyway, good luck. I'll announce the presentation's availability when it's ready for consumption.
Pascal Giard on 02/25/2009 8:20 a.m. #
I'm trying to figure how to make a smart use of array-based drawing.
I can easily understand how i can render alot of polygons at once if they share the same texture and transformation matrix.
But what's the clean/optimal way of rendering objects if:
- they do not share the same transformation matrix? (Besides the camera transformations).
- they do not share the same texture?
For the first one, should i use Numpy array [matrix] transformations and update parts of the "big" array?
When using VBOs, is this when glBufferSubData comes handy?
I think i'll need a simple, yet with good coverage of the concepts, example to understand the good practices. e.g. something like NeHe's lesson 5 but w/ textures. Do you happen to know where i can find something like this?
PS: Shouldn't Hearn Baker's Computer Graphics with OpenGL cover that kind of stuff!?
Mike Fletcher on 02/25/2009 11:38 p.m. #
For a task such as rendering text, the approach I understand to be recommended is that you render many characters into a single texture, then use an array (vbo) of vertex/texcoord values to rendering e.g. strings of text with a single call. The idea being that your individual characters are polygons within a larger polygon-set.
Separate strings become separate calls, but a body of text is a single call. The font is, for the most part, rendered as a single texture, so if you draw thousands of characters in a paragraph that's a single call, all over on the server side.
Rendering individual characters, by comparison, is always going to be slow, you can push the coordinates and texture onto the server, but if you're doing a separate call-per-polygon (even an array-based one), you'll likely find performance lacking.
Rewriting OpenGLContext's bitmap text to use that kind of setup is one of the things I really need to get around to one of these days. As with much of the 3.1 transitions, it all comes down to doing a lot of "bookkeeping" in your code (e.g. tracking coordinates for characters in a larger texture) which then lets the hardware ignore all the high-level issues and just process big chunks of data.
Pascal Giard on 04/16/2009 1:44 p.m. #
Still willing to gradually move toward OpenGL 3.x while still supporting older videocards...
I wrote a little piece of code to compare direct-drawing, array-based drawing and VBO drawing.
But i'm having an unexpected issue... VBO and array-based drawing don't treat arrays the same way?!
Please consider the following:
http://pastebin.com/m6f1103f5
In the init() method, i'm initializing both triangVtx and triangVbo. I would expect those two triangles to be the same...
Namely with the vertices (x, y, z):
( 0, 1, 0)
(-1,-1, 0)
( 1,-1, 0)
In VBO's case, it isn't... it looks like two vertices are on the y=1 axis and two vertices share the same x value. Did i miss something?
Mike C. Fletcher on 04/16/2009 2:09 p.m. #
It's just a problem with your array. You're initializing it with:
array([[ 0, 1, 0],
[-1, -1, 0],
[ 1, -1, 0]],dtype=float)
you wanted:
array([[ 0, 1, 0],
[-1, -1, 0],
[ 1, -1, 0]],dtype='f')
OpenGL is, under the covers "fixing" the array type in mode "1" because it can look at the type and see that it's wrong when you call glVertexPointerf()
With the VBO, there's no necessary relationship between the type of the array you use when constructing the VBO and the type you pass to glVertexPointer. It is possible, for instance, to have the VBO array's type be "bytes" and yet use it as floats.
Pascal Giard on 04/16/2009 2:29 p.m. #
Thanks alot for pointing this out!
I'll use the float32 from numpy to avoid this ambiguity.