OpenGL wrappers
mithrandi
wrappers, or to migrate to PyOpenGL-ctypes at some point. Could
someone fill me in on the plans for the future?
mmarshall
IIRC pyglet tries to minimize dependencies, so PyOpenGL won't be
used. However, pyglet's wrapping of OpenGL isn't meant to be
complete; it's only what pyglet itself uses. You'll need to use
PyOpenGL for the rest.
But, I don't really know. (I'm just a lurker here.)
MWM
Alex Holkner
On 06/08/2007, at 8:01 AM, mmarshall wrote:
>
> On Aug 5, 1:12 pm, mithrandi <mithra...@gmail.com> wrote:
>> I'm wondering whether the plan is to maintain an independent set of
>> wrappers, or to migrate to PyOpenGL-ctypes at some point. Could
>> someone fill me in on the plans for the future?
>
> IIRC pyglet tries to minimize dependencies, so PyOpenGL won't be
> used. However, pyglet's wrapping of OpenGL isn't meant to be
> complete; it's only what pyglet itself uses. You'll need to use
> PyOpenGL for the rest.
>
That was more or less the original plan. pyglet wraps OpenGL at the
lowest level, so it only provides glVertex3f, glVertex2d, etc.,
whereas PyOpenGL also provides polymorphic functions such as glVertex.
I have found (and others have agreed) that this is not altogether a
bad thing, as it requires less thought when moving between C and
Python code.
pyglet provides all of the error-checking functionalities that
PyOpenGL does (though these can be disabled for performance). At
last check, pyglet was significantly faster than PyOpenGL 3, but
slower than PyOpenGL 2. I'm not sure what the current status is.
What this means for application developers is: you can use pyglet's
GL wrappings and be confident of universal availability, fast
performance and error checking. You can, at your option, use
PyOpenGL with pyglet for possibly better performance (this is
unknown) or to use the polymorphic functions. No extra setup is
required to do this: pyglet.gl and PyOpenGL function calls can be
freely intermixed.
I will be keeping the pyglet.gl wrappings up-to-date as new releases
from nVidia and the ARB are made.
Alex.
mithrandi
> unknown) or to use the polymorphic functions. No extra setup is
> required to do this: pyglet.gl and PyOpenGL function calls can be
> freely intermixed.
My only concern is that this may not necessarily be the case; for
example, I think there is some internal bookkeeping done in PyOpenGL
regarding glBegin/glEnd; calling the pyglet.gl versions of these could
then cause problems. But, I suppose there are probably not too many
cases where this is a problem; the duplication of effort is of mild
annoyance, but since the pyglet interfaces are low-level and (mostly?
completely?) autogenerated, I suppose it isn't that much of a concern.
Alex Holkner
On 06/08/2007, at 10:56 AM, mithrandi wrote:
>
> On Aug 6, 12:28 am, Alex Holkner <Alex.Holk...@gmail.com> wrote:
>> unknown) or to use the polymorphic functions. No extra setup is
>> required to do this: pyglet.gl and PyOpenGL function calls can be
>> freely intermixed.
>
> My only concern is that this may not necessarily be the case; for
> example, I think there is some internal bookkeeping done in PyOpenGL
> regarding glBegin/glEnd; calling the pyglet.gl versions of these could
> then cause problems. But, I suppose there are probably not too many
You are correct in this case, pyglet also maintains its own state
here when error checking is enabled. I would assume that any
developer would not be mixing libraries between glBegin/glEnd blocks.
> cases where this is a problem; the duplication of effort is of mild
> annoyance, but since the pyglet interfaces are low-level and (mostly?
> completely?) autogenerated, I suppose it isn't that much of a concern.
The scripts for (re)generating the pyglet.gl modules are in the
tools/ directory. Downloading the latest header(s) and rerunning the
script on the appropriate platform is sufficient to update pyglet's
wrap. It would be nice if some cron job recognised a new GL release
and initiated this automatically, but probably unnecessary :-)
Alex.