pyopengl-users — Discussion of all PyOpenGL matters.

[PyOpenGL-Users] Exception on Exit

[Ian M. <geo...@gm...>]

Hi,

I have code that creates an exception on exit.  I can't imagine why.

Exception exceptions.TypeError: "'NoneType' object is not callable" in
<bound method glLibLight.__del__ of <glLib.glLibLight.glLibLight instance at
0x034B3F80>> ignored

This error only happens on exit.  Ideas?

Ian

Re: [PyOpenGL-Users] GLUError and gluNurbsCurve

[Mike C. F. <mcf...@vr...>]

Ivo Ugrina wrote:
> Mike C. Fletcher wrote:
>   
>> Can you give me some details as to what you mean by "bad arguments"?  Do
>> you mean values that are logically inconsistent (don't match the
>> mathematics)?  Or wrong enumerants/invalid options?
>>     
>
> For example 5 points of control polygon and
> order 13 should raise exception GLUError, "too few knots"
> or when I give a decreasing knot sequence it
> should raise exception GLUError, "decreasing knot sequence"
>
> Here is a part of Knotvector::validate
> from sgi implementation of glu (knotvector.cc)
>   
Hmm, are you saying those ints are supposed to be returned as values 
from gluNurbsCurve?  My manual says that it is supposed to have a void 
return type.  Or is this supposed to show up in a glGetError return 
value?  Basically I'm wondering whether these are supposed to be part of 
GLU or part of the wrapper?  If they are part of GLU I don't yet know 
how to retrieve them.

For now, I've added them to the wrapper and have them controlled by 
OpenGL.ERROR_CHECKING, so you can turn them off when your code is no 
longer producing invalid values and want to reclaim the performance.  
You should be able to check out current head via:

    bzr branch lp:pyopengl

and check that the code now catches your errors.

Thanks for the bug report,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] GLUError and gluNurbsCurve

[Mike C. F. <mcf...@vr...>]

Ivo Ugrina wrote:
> Hi,
>
> I'm trying to port my code from 2.x to 3.0
> and everything seems to work except
> gluNurbsCurve.
>
> The problem is that in 2.x pyopengl
> gluNurbsCurve would raise GLUError exception
> when arguments were bad, but in 3.0 it doesn't
> raise any exceptions ( at least I see it that way).
>
> I would appreciate any help,
>   
Can you give me some details as to what you mean by "bad arguments"?  Do 
you mean values that are logically inconsistent (don't match the 
mathematics)?  Or wrong enumerants/invalid options?

I wouldn't be surprised if there was less checking in the current code, 
just not sure what particular checks the old code was doing.

Good luck,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] glMapBuffer with GL_WRITE_ONLY

[Mike C. F. <mcf...@vr...>]

Colin Caufield wrote:
> Hi everyone,
>
> I've managed to get VBOs working in my PyOpenGL application, but I've  
> hit a wall trying to update the data in them.  My VBOs contain  
> position and texcoord data only (not interleaved).  Every few frames I  
> need to change some of the texcoord data.  I know this is done with  
> glMapBuffer, but I can't wrap my head around the python bindings for  
> this function.  glMapBuffer returns a ctypes.c_void_p.  I'm very  
> comfortable with C, but not with ctypes.  I want to treat this  
> c_void_p like a python list of floats, and use slicing to change the  
> values at particular locations.  Is this possible?  I'm also very  
> worried about performance; I don't want any of the texcoord buffer to  
> be copied back into main memory.  I've spent a lot of time hunting  
> around with Google, but I'm still lost.  Any help is greatly  
> appreciated.
>   
There are actually two ways to update the data, the first is to map the 
buffer, update it and then unmap it.  The second is to copy a subset of 
the data explicitly into the new data-set.  Given your use case, it 
sounds like you want to use the second method.

However, to use the first method, the secret is that you want to use 
either a numpy array or a ctypes array mapped to the data-set and then 
update it.  For numpy this looks something like this:

pbfm = pythonapi.PyBuffer_FromMemory
pbfm.restype = py_object
buffer = pbfm( pointer, size_of_data )
array = numpy.frombuffer( buffer, dtype )

http://www.mail-archive.com/num...@li.../msg01161.html  
I can't claim to have done this myself, I'm guessing that people who use 
this approach will come up with suggestions for better wrappers for the 
mapping API.

But for the second approach: the OpenGL buffer api also includes 
glBufferSubData(self.target, start, size, dataptr) which lets you update 
a subset of the data without mapping the data into your memory space, 
i.e. it just sends a block of data over to the card to replace the 
current set of data.  This is a nice, discrete API that does not rely on 
having the data in shared memory space, you just say what you want to 
replace and with what and the data is passed to the card.  This 
obviously avoids any concerns about having to copy the data back or the 
like.  You'll see an implementation of this in the OpenGL.arrays.vbo 
module, though I'm not sure I'm currently testing it, as my current 
tests tend to replace the whole of the vbo when there's an update.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] PyOpenGL Release 3.0.0 (final)

[Thomas H. <th...@ct...>]

René Dudfield schrieb:
> On Fri, Apr 3, 2009 at 2:20 AM, Mike C. Fletcher <mcf...@vr...>wrote:
> 
>> Peter Gebauer wrote:
>>
>>> Hi Mike!
>>>
>>> Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or
>>> Python extensions written in C to improve performance? Is there a
>>> possibility
>>> of mixing ctypes with Python extensions in C for the more critical parts?
>>>
>>>
>> The OpenGL_accelerate module is written in Cython (~= Pyrex) to improve
>> performance.  Yes, you can fairly freely mix C/Cython/Pyrex coded
>> OpenGL-using extensions with PyOpenGL code.  The current GL context is used
>> by all PyOpenGL calls (well, the ones that don't explicitly specify
>> contexts, such as those in GLUT or GLX).
>>
>> As for rewriting the core library, I doubt *I* will do another rewrite. But
>> the fact is that someone could easily generate a new Cython/Pyrex wrapper
>> without breaking a sweat.  They would just then need to do all the project
>> management and maintenance on the code-base, and I quit working on the SWIG
>> code-base because of the maintenance headaches, so it's not really something
>> I want to go back to.
>>
>> The use of ctypes means that we should eventually be able to run on all of
>> Jython, PyPy, IronPython, Unladen Swallow and CPython with the core
>> Python+ctypes-only implementation.  Interpreters that actually *use* the
>> ctypes annotations (PyPy) may eventually be able to use the fact of using
>> ctypes to generate almost-C-level performance from the code.
>>
> 
> 
> A funny side note is that ironpython can more easily run CPython compiled
> extensions than ctypes code at the moment.  This is done by emulating the
> CPython API.

But this means that it should be possible to run ctypes code on IronPython;
just load _ctypes.pyd via the emulated CPython api.

-- 
Thanks,
Thomas

[PyOpenGL-Users] glMapBuffer with GL_WRITE_ONLY

[Colin C. <cjc...@gm...>]

Hi everyone,

I've managed to get VBOs working in my PyOpenGL application, but I've  
hit a wall trying to update the data in them.  My VBOs contain  
position and texcoord data only (not interleaved).  Every few frames I  
need to change some of the texcoord data.  I know this is done with  
glMapBuffer, but I can't wrap my head around the python bindings for  
this function.  glMapBuffer returns a ctypes.c_void_p.  I'm very  
comfortable with C, but not with ctypes.  I want to treat this  
c_void_p like a python list of floats, and use slicing to change the  
values at particular locations.  Is this possible?  I'm also very  
worried about performance; I don't want any of the texcoord buffer to  
be copied back into main memory.  I've spent a lot of time hunting  
around with Google, but I'm still lost.  Any help is greatly  
appreciated.

Colin

[PyOpenGL-Users] PyInstaller Problem (was: Re: import dependencies mess with py2exe)

[Dirk R. <dir...@gm...>]

	Hi Lorenzo,

Lorenzo Mancini wrote:
> 
> If aren't tied to py2exe for some reason, I suggest you to try 
> PyInstaller (http://pyinstaller.python-hosting.com): some time ago I 
> contributed the support for PyOpenGL >=3.0.0b6, which now should work 
> with no manual intervention needed.
> 
> PyOpenGL 2.x is also supported.
> 
> Remember to checkout PyInstaller trunk:
> 
> svn co http://svn.pyinstaller.python-hosting.com/trunk pyinstaller
> 
> because the latest stable version (1.3) is really outdated.

That sounds pretty cool! I just can't make it work... :(

I have a fairly simple app using PyQT and PyOpenGL. I follow the
instructions on the website, but I'm running into problems with
importing _ctypes in the final executable.

My spec file:

# -*- mode: python -*-
a = Analysis([os.path.join(HOMEPATH,'support\\_mountzlib.py'),
os.path.join(HOMEPATH,'support\\useUnicode.py'),
'd:\\Workspace\\Grid3D\\src\\pyqt\\grid3d.py'],
              pathex=['D:\\CMPS415_Stuff\\Installer_trunk'])
pyz = PYZ(a.pure)
exe = EXE(pyz,
           a.scripts + [('v','','OPTION')],
           exclude_binaries=1,
           name=os.path.join('build\pyi.win32\grid3d', 'grid3d.exe'),
           debug=True,
           strip=False,
           upx=False,
           console=True )
coll = COLLECT( exe,
                a.binaries,
                a.zipfiles,
                a.datas,
                strip=False,
                upx=False,
                name=os.path.join('dist', 'grid3d'))

Build output:

D:\CMPS415_Stuff\Installer_trunk>python.exe Build.py Grid3D\grid3d.spec
Build.py:29: DeprecationWarning: the md5 module is deprecated; use
hashlib instead
   import md5
checking Analysis
checking PYZ
building because outPYZ1.toc is bad
building PYZ outPYZ1.toc
checking PKG
building because Grid3D\build\pyi.win32\grid3d\outPYZ1.pyz changed
building PKG outPKG3.pkg
checking EXE
building because debug changed
building EXE from outEXE2.toc
Appending archive to EXE Grid3D\build\pyi.win32\grid3d\grid3d.exe
checking COLLECT
building outCOLLECT4.toc because
Grid3D\build\pyi.win32\grid3d\grid3d.exe is more recent
building COLLECT outCOLLECT4.toc


The warngrid3d.txt is a little long for this mail, I put it on drop.io
at http://drop.io/dlww0ve .


Running the program output:

D:\CMPS415_Stuff\Installer_trunk\Grid3D\build\pyi.win32\grid3d>grid3d.exe
Cannot open archive:
D:\CMPS415_Stuff\Installer_trunk\Grid3D\build\pyi.win32\grid3d\grid3d.pkg
Extracting binaries
python26.dll
Manipulating evironment
PYTHONPATH=D:/CMPS415_Stuff/Installer_trunk/Grid3D/build/pyi.win32/grid3d
v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
importing modules from CArchive
import marshal # builtin
extracted iu
import imp # builtin
import nt # builtin
extracted struct
import _struct # builtin
extracted archive
Installing import hooks
outPYZ1.pyz
Running scripts
import zlib # builtin
import _codecs # builtin
import errno # builtin
Traceback (most recent call last):
   File "<string>", line 2, in <module>
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 427, in importHook
     mod = _self_doimport(nm, ctx, fqname)
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 512, in doimport
     exec co in mod.__dict__
   File "Grid3D\build\pyi.win32\grid3d\outPYZ1.pyz/OpenGL.GL", line 2,
in <module>
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 427, in importHook
     mod = _self_doimport(nm, ctx, fqname)
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 512, in doimport
     exec co in mod.__dict__
   File "Grid3D\build\pyi.win32\grid3d\outPYZ1.pyz/OpenGL.raw.GL", line
6, in <module>
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 427, in importHook
     mod = _self_doimport(nm, ctx, fqname)
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 512, in doimport
     exec co in mod.__dict__
   File
"Grid3D\build\pyi.win32\grid3d\outPYZ1.pyz/OpenGL.raw.GL.constants",
line 6, in <module>
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 427, in importHook
     mod = _self_doimport(nm, ctx, fqname)
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 512, in doimport
     exec co in mod.__dict__
   File "Grid3D\build\pyi.win32\grid3d\outPYZ1.pyz/ctypes", line 10, in
<module>
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 446, in importHook
     raise ImportError, "No module named %s" % fqname
ImportError: No module named _ctypes
RC: -1 from grid3d
OK.

This using python 2.6, PyOpenGL 3.0.0 and PyInstaller trunk.

Any ideas what could be going wrong?

Thanks

	Dirk

[PyOpenGL-Users] PyInstaller Problem (was: Re: import dependencies mess with py2exe)

[Dirk R. <dir...@gm...>]

	Hi Lorenzo,

Lorenzo Mancini wrote:
> 
> If aren't tied to py2exe for some reason, I suggest you to try 
> PyInstaller (http://pyinstaller.python-hosting.com): some time ago I 
> contributed the support for PyOpenGL >=3.0.0b6, which now should work 
> with no manual intervention needed.
> 
> PyOpenGL 2.x is also supported.
> 
> Remember to checkout PyInstaller trunk:
> 
> svn co http://svn.pyinstaller.python-hosting.com/trunk pyinstaller
> 
> because the latest stable version (1.3) is really outdated.

That sounds pretty cool! I just can't make it work... :(

I have a fairly simple app using PyQT and PyOpenGL. I follow the 
instructions on the website, but I'm running into problems with 
importing _ctypes in the final executable.

My spec file:

# -*- mode: python -*-
a = Analysis([os.path.join(HOMEPATH,'support\\_mountzlib.py'), 
os.path.join(HOMEPATH,'support\\useUnicode.py'), 
'd:\\Workspace\\Grid3D\\src\\pyqt\\grid3d.py'],
              pathex=['D:\\CMPS415_Stuff\\Installer_trunk'])
pyz = PYZ(a.pure)
exe = EXE(pyz,
           a.scripts + [('v','','OPTION')],
           exclude_binaries=1,
           name=os.path.join('build\pyi.win32\grid3d', 'grid3d.exe'),
           debug=True,
           strip=False,
           upx=False,
           console=True )
coll = COLLECT( exe,
                a.binaries,
                a.zipfiles,
                a.datas,
                strip=False,
                upx=False,
                name=os.path.join('dist', 'grid3d'))

Build output:

D:\CMPS415_Stuff\Installer_trunk>python.exe Build.py Grid3D\grid3d.spec
Build.py:29: DeprecationWarning: the md5 module is deprecated; use 
hashlib instead
   import md5
checking Analysis
checking PYZ
building because outPYZ1.toc is bad
building PYZ outPYZ1.toc
checking PKG
building because Grid3D\build\pyi.win32\grid3d\outPYZ1.pyz changed
building PKG outPKG3.pkg
checking EXE
building because debug changed
building EXE from outEXE2.toc
Appending archive to EXE Grid3D\build\pyi.win32\grid3d\grid3d.exe
checking COLLECT
building outCOLLECT4.toc because 
Grid3D\build\pyi.win32\grid3d\grid3d.exe is more recent
building COLLECT outCOLLECT4.toc


The warngrid3d.txt is a little long for this mail, I put it on drop.io 
at http://drop.io/dlww0ve .


Running the program output:

D:\CMPS415_Stuff\Installer_trunk\Grid3D\build\pyi.win32\grid3d>grid3d.exe
Cannot open archive: 
D:\CMPS415_Stuff\Installer_trunk\Grid3D\build\pyi.win32\grid3d\grid3d.pkg
Extracting binaries
python26.dll
Manipulating evironment
PYTHONPATH=D:/CMPS415_Stuff/Installer_trunk/Grid3D/build/pyi.win32/grid3d
v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
importing modules from CArchive
import marshal # builtin
extracted iu
import imp # builtin
import nt # builtin
extracted struct
import _struct # builtin
extracted archive
Installing import hooks
outPYZ1.pyz
Running scripts
import zlib # builtin
import _codecs # builtin
import errno # builtin
Traceback (most recent call last):
   File "<string>", line 2, in <module>
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 427, in importHook
     mod = _self_doimport(nm, ctx, fqname)
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 512, in doimport
     exec co in mod.__dict__
   File "Grid3D\build\pyi.win32\grid3d\outPYZ1.pyz/OpenGL.GL", line 2, 
in <module>
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 427, in importHook
     mod = _self_doimport(nm, ctx, fqname)
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 512, in doimport
     exec co in mod.__dict__
   File "Grid3D\build\pyi.win32\grid3d\outPYZ1.pyz/OpenGL.raw.GL", line 
6, in <module>
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 427, in importHook
     mod = _self_doimport(nm, ctx, fqname)
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 512, in doimport
     exec co in mod.__dict__
   File 
"Grid3D\build\pyi.win32\grid3d\outPYZ1.pyz/OpenGL.raw.GL.constants", 
line 6, in <module>
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 427, in importHook
     mod = _self_doimport(nm, ctx, fqname)
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 512, in doimport
     exec co in mod.__dict__
   File "Grid3D\build\pyi.win32\grid3d\outPYZ1.pyz/ctypes", line 10, in 
<module>
   File "D:\CMPS415_Stuff\Installer_trunk\iu.py", line 446, in importHook
     raise ImportError, "No module named %s" % fqname
ImportError: No module named _ctypes
RC: -1 from grid3d
OK.

This using python 2.6, PyOpenGL 3.0.0 and PyInstaller trunk.

Any ideas what could be going wrong?

Thanks

	Dirk

Re: [PyOpenGL-Users] [pygame] PyOpenGL Release 3.0.0 (final)

[René D. <re...@gm...>]

On Fri, Apr 3, 2009 at 2:20 AM, Mike C. Fletcher <mcf...@vr...>wrote:

> Peter Gebauer wrote:
>
>> Hi Mike!
>>
>> Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or
>> Python extensions written in C to improve performance? Is there a
>> possibility
>> of mixing ctypes with Python extensions in C for the more critical parts?
>>
>>
> The OpenGL_accelerate module is written in Cython (~= Pyrex) to improve
> performance.  Yes, you can fairly freely mix C/Cython/Pyrex coded
> OpenGL-using extensions with PyOpenGL code.  The current GL context is used
> by all PyOpenGL calls (well, the ones that don't explicitly specify
> contexts, such as those in GLUT or GLX).
>
> As for rewriting the core library, I doubt *I* will do another rewrite. But
> the fact is that someone could easily generate a new Cython/Pyrex wrapper
> without breaking a sweat.  They would just then need to do all the project
> management and maintenance on the code-base, and I quit working on the SWIG
> code-base because of the maintenance headaches, so it's not really something
> I want to go back to.
>
> The use of ctypes means that we should eventually be able to run on all of
> Jython, PyPy, IronPython, Unladen Swallow and CPython with the core
> Python+ctypes-only implementation.  Interpreters that actually *use* the
> ctypes annotations (PyPy) may eventually be able to use the fact of using
> ctypes to generate almost-C-level performance from the code.
>


A funny side note is that ironpython can more easily run CPython compiled
extensions than ctypes code at the moment.  This is done by emulating the
CPython API.


cu,

[PyOpenGL-Users] GLUError and gluNurbsCurve

[Ivo U. <iv...@iu...>]

Hi,

I'm trying to port my code from 2.x to 3.0
and everything seems to work except
gluNurbsCurve.

The problem is that in 2.x pyopengl
gluNurbsCurve would raise GLUError exception
when arguments were bad, but in 3.0 it doesn't
raise any exceptions ( at least I see it that way).

I would appreciate any help,
-- 
Ivo Ugrina | Jab: gro.rebbajTAanirgui
www.iugrina.com | ICQ: 47508335

Re: [PyOpenGL-Users] [pygame] PyOpenGL Release 3.0.0 (final)

[Mike C. F. <mcf...@vr...>]

Peter Gebauer wrote:
> Hi Mike!
>
> Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or
> Python extensions written in C to improve performance? Is there a possibility
> of mixing ctypes with Python extensions in C for the more critical parts?
>   
The OpenGL_accelerate module is written in Cython (~= Pyrex) to improve 
performance.  Yes, you can fairly freely mix C/Cython/Pyrex coded 
OpenGL-using extensions with PyOpenGL code.  The current GL context is 
used by all PyOpenGL calls (well, the ones that don't explicitly specify 
contexts, such as those in GLUT or GLX).

As for rewriting the core library, I doubt *I* will do another rewrite. 
But the fact is that someone could easily generate a new Cython/Pyrex 
wrapper without breaking a sweat.  They would just then need to do all 
the project management and maintenance on the code-base, and I quit 
working on the SWIG code-base because of the maintenance headaches, so 
it's not really something I want to go back to.

The use of ctypes means that we should eventually be able to run on all 
of Jython, PyPy, IronPython, Unladen Swallow and CPython with the core 
Python+ctypes-only implementation.  Interpreters that actually *use* the 
ctypes annotations (PyPy) may eventually be able to use the fact of 
using ctypes to generate almost-C-level performance from the code.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] PyOpenGL Release 3.0.0 (final)

[Mike C. F. <mcf...@vr...>]

Lorenzo Mancini wrote:
> Hello Mike, this really is great news!  Congratulations!
>
>
>> 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.
>
> In the past days I've tried OpenGL_accelerate on some code of mine 
> that suffers an expected 50% performance loss switching from pyopengl 
> 2.x to 3.x, and it already yields a little speedup; since you are 
> speaking in future tense, does this mean that more consistent 
> improvements on OpenGL_accelerate are planned?
>
> [[Note: the code I'm talking about is heavily display-lists and other 
> OpenGL legaciness based, so probably it doesn't represent a valid test 
> bench for pyopengl 3.x performance measurements.]]
I'm intending to get rather more (Cython) accelerator helpers in 
OpenGL_accelerate, but no, it likely won't be focusing on the legacy 
APIs.  Basically I'm planning to focus on the array-handling APIs so 
that we can reduce the overhead there to something reasonable.  There 
are a considerable number of performance improvements still lying on the 
ground in the wrapper mechanism that could be fairly straightforwardly 
fixed if I can find the time.  I also want to look into whether we can 
simplify some of the wrapper operations if you enable legacy-free behavior.
>
>> 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.
>
> Are you talking about OpenGL.FORWARD_COMPATIBLE_ONLY?  To do that, the 
> OpenGL code in the application must be legacy-free, correct?
Nope, FORWARD_COMPATIBLE_ONLY is part of the migration path machinery 
(which is another of the areas I'm intending to focus on), it doesn't 
give you any performance improvements, it just disables the old APIs and 
lets you know which pieces are legacy by raising errors (though it 
doesn't do this for GLUT/GLU).  Code that is entirely forward compatible 
(legacy free) is going to be reasonably fast, because it *must* use VBOs 
and shaders and there's basically nothing going on within the Python 
code[1].  I'll be looking at optimizing those paths fairly heavily as 
well, as that's where we need to go.  However, the flag itself doesn't 
make your code any faster, it just disables the legacy stuff so you 
can't use it.

The flags that impact performance are:

    * ERROR_CHECKING -- huge performance win, but no error checking, use
      at the end of the dev cycle when you know your code is handling
      all cases properly and want a performance boost, often close to 2x
      improvement, as it halves the number of OpenGL calls in many cases.
    * ERROR_LOGGING -- less of a performance win, but removes a single
      wrapper call from every OpenGL call, if you turn off error
      checking then this is turned off as well, but you can disable just
      this to remove the function-call overhead
    * ERROR_ON_COPY -- if set, will tell you when you are passing
      incompatible arrays to array-handling functions (thus requiring a
      copy of the array).  For large array-oriented code-bases array
      copying can become a huge bottleneck, so you can set this flag to
      True to be warned of the problem.  By default it silently fixes
      the problem at the cost of performance.  Eventually this will
      likely *also* reject list/tuple types as array values, as they
      require a data-copy as well.
    * ALLOW_NUMPY_SCALARS -- if set, works around a bug in older
      Python's ctypes that disallowed use of numpy scalars as return
      values, has a large negative performance penalty, so is currently
      disabled by default

The new one I plan to introduce will likely have this effect:

    * disable pointer-storage-for-safety behavior, currently PyOpenGL
      stores the pointer objects you pass it in order to prevent
      memory-access failures, this behavior becomes unnecessary when we
      have full ERROR_ON_COPY behavior and you've fixed all of your code
      to pass in objects which are compatible by default.  The behavior
      is also unneeded with legacy-free arrays, as data-copying happens
      during the call in *all* cases, so there's no need for the GL to
      access the data "later".

The idea being that by default the system will be as robust and friendly 
as possible, but as you move your application toward release you'll 
start peeling off the layers of "nets" to improve your performance.
>> 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.
>
> As I wrote in a previous message, such a "raw" C style wrapper is also 
> hidden in PyOpenGL, you just have to import from OpenGL.raw.GL instead 
> of OpenGL.GL, and switch OpenGL.ERROR_CHECKING to False.
There's a few more differences (PyOpenGL's wrapper does more to each 
function in order to be as friendly and safe as possible), but yes, that 
is the basic idea of the "raw" hierarchy.
> This can improve performance (I get a 100% speedup with the codebase 
> mentioned above) and bring it to the levels of 2.x, at the cost of 
> some ctypes pollution in the code - raw wrappers of pyopengl and 
> pyglet are almost indistinguishable both performance and code 
> appearance wise.
You should still see a performance win on Pyglet unless you're using 
OpenGL_accelerate.  It does far less per-call than PyOpenGL in most cases.
> Talking about pyglet, some time ago I happened to read their automatic 
> wrapper generator: I found it nice and easily pluggable in a toy 
> project of mine.  Since it uses the same ctypes technology and I 
> remember you praising it yourself in a past presentation of yours, are 
> you planning to merge it into pyopengl3.x to avoid duplicating efforts?
Yup, my intention is to use Pyglet's generator to replace the PyOpenGL 
generation mechanism.  That was put on hold to focus on just getting the 
library out the door.  The proof of concept was able to generate 
basically the same wrapper as PyOpenGL for the core, but there were some 
subtle differences from the current raw wrappers that wound up making 
the result unstable in my testing.  That should all just be a matter of 
time to fix... unfortunately, time is something I seem to have little of 
these days :) .

Enjoy,
Mike

[1] The one big anti-pattern for legacy-free is the individual-quad 
rendering pattern that a lot of people are using in current PyOpenGL.  
You (including me) really need to switch to texture atlases for things 
like rendering text/sprites and use a big buffer with a shader that 
renders the sprites with a single pass.

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] PyOpenGL Release 3.0.0 (final)

[Lorenzo M. <lma...@de...>]

Hello Mike, this really is great news!  Congratulations!


> 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.

In the past days I've tried OpenGL_accelerate on some code of mine that 
suffers an expected 50% performance loss switching from pyopengl 2.x to 
3.x, and it already yields a little speedup; since you are speaking in 
future tense, does this mean that more consistent improvements on 
OpenGL_accelerate are planned?

[[Note: the code I'm talking about is heavily display-lists and other 
OpenGL legaciness based, so probably it doesn't represent a valid test 
bench for pyopengl 3.x performance measurements.]]


> 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.

Are you talking about OpenGL.FORWARD_COMPATIBLE_ONLY?  To do that, the 
OpenGL code in the application must be legacy-free, correct?


> 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.

As I wrote in a previous message, such a "raw" C style wrapper is also 
hidden in PyOpenGL, you just have to import from OpenGL.raw.GL instead 
of OpenGL.GL, and switch OpenGL.ERROR_CHECKING to False.

This can improve performance (I get a 100% speedup with the codebase 
mentioned above) and bring it to the levels of 2.x, at the cost of some 
ctypes pollution in the code - raw wrappers of pyopengl and pyglet are 
almost indistinguishable both performance and code appearance wise.


Talking about pyglet, some time ago I happened to read their automatic 
wrapper generator: I found it nice and easily pluggable in a toy project 
of mine.  Since it uses the same ctypes technology and I remember you 
praising it yourself in a past presentation of yours, are you planning 
to merge it into pyopengl3.x to avoid duplicating efforts?


Thanks, and keep up the great work!

-- 
Lorenzo Mancini

[PyOpenGL-Users] PyOpenGL Release 3.0.0 (final)

[Mike C. F. <mcf...@vr...>]

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:pyopengl
    bzr branch lp:pyopengl-demo

then add the pyopengl/OpenGL directory to your PYTHONPATH.  You can also 
download the source distributions from:

    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 PyOpenGL
    easy_install PyOpenGL-Demo

You can then run the scripts in the PyOpenGL-Demo package.

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.

Enjoy yourselves,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] should it be 'posix' in opengl/__init__.py ?

[Mike C. F. <mcf...@vr...>]

wen heping wrote:
> Hi,
>
> In file OpenGL/__init__.py there is:
>        PlatformPlugin( 'posix ', 'OpenGL.platform.glx.GLXPlatform' )
> Should it be:
>        PlatformPlugin( 'posix', 'OpenGL.platform.glx.GLXPlatform' )
Yup, it should have been.  I've updated it locally.  I'm guessing no-one 
with a non-linux posix machine has used PyOpenGL 3.x

Thanks,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] Point VBO

[Ian M. <geo...@gm...>]

I didn't know that would be a problem.  That completely fixes it
though--thanks!

Re: [PyOpenGL-Users] Point VBO

[Mike C. F. <mcf...@vr...>]

Ian Mallett wrote:
> Hello,
>
> I have a VBO which should make a square grid:
>
> #Numeric is "import numpy as Numeric"
> class glLibCausticGrid:
>     def __init__(self,size):
>         self.size = size
>         self.size_squared = size*size
>         threedimensionalgrid = 
> Numeric.dstack(Numeric.mgrid[0:size,0:size,0:1])/float(size-1)
Wouldn't this have created a double, rather than a float data-set, does 
on my machine:

 >>> n = numpy.dstack( numpy.mgrid[0:255,0:255,0:1])/float(254)
 >>> n.dtype
dtype('float64')


HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

[PyOpenGL-Users] Point VBO

[Ian M. <geo...@gm...>]

Hello,

I have a VBO which should make a square grid:

#Numeric is "import numpy as Numeric"
class glLibCausticGrid:
    def __init__(self,size):
        self.size = size
        self.size_squared = size*size
        threedimensionalgrid =
Numeric.dstack(Numeric.mgrid[0:size,0:size,0:1])/float(size-1)
        threedimensionalgrid =
threedimensionalgrid.reshape(self.size_squared,3)
        self.vertex_vbo = vbo.VBO(threedimensionalgrid)
    def draw(self):
        glEnableClientState(GL_VERTEX_ARRAY)
        self.vertex_vbo.bind()
        glVertexPointerf(self.vertex_vbo)
        glDrawArrays(GL_POINTS,0,self.size_squared)
        glBindBuffer(GL_ARRAY_BUFFER,0)
        glDisableClientState(GL_VERTEX_ARRAY)
    def __del__(self):
        self.vertex_vbo.delete()

When it is drawn, I get an incorrect result--the vertices are all over the
place in semi-ordered, but incomprehensible patterns.  I really need it to
be a grid.  Pointers?

Thanks,
Ian

[PyOpenGL-Users] should it be 'posix' in opengl/__init__.py ?

[wen h. <wen...@gm...>]

Hi,

In file OpenGL/__init__.py there is:
       PlatformPlugin( 'posix ', 'OpenGL.platform.glx.GLXPlatform' )
Should it be:
       PlatformPlugin( 'posix', 'OpenGL.platform.glx.GLXPlatform' )

More detailed description please visit:
      http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/130821


Regards,
wen

[PyOpenGL-Users] glReadPixels error

[. <rem...@gm...>]

I'm getting the following traceback with this code:
OpenGL.GL.glReadPixels(0,0,640,480,OpenGL.GL.GL_RGBA,OpenGL.GL.GL_UNSIGNED_BYTE)

...

Traceback (most recent call last):
  File
"/home/packages/python/2.5/python2.5-2.5.2/Modules/_ctypes/callbacks.c",
line 274, in 'calling callback function'
  File "/home/c7a71k/Hexer/SIL/Engine.py", line 182, in idleCallback
    self.displayCallback()
  File "/home/c7a71k/Hexer/SIL/Engine.py", line 161, in displayCallback

OpenGL.GL.glReadPixels(0,0,640,480,OpenGL.GL.GL_RGBA,OpenGL.GL.GL_UNSIGNED_BYTE)
  File "/home/c7a71k/Hexer/SIL/OpenGL/GL/images.py", line 319, in
glReadPixels
    imageData = arrayType.dataPointer(array)
  File "/home/c7a71k/Hexer/SIL/OpenGL/arrays/arraydatatype.py", line 38, in
dataPointer
    return cls.getHandler(value).dataPointer( value )
  File "/home/c7a71k/Hexer/SIL/OpenGL/arrays/formathandler.py", line 16, in
__call__
    typ = value.__class__
AttributeError: __class__

...

also very curious to note from that first 'File' line ... that file, and
even that DIRECTORY (/home/packages/) does not exist! Heh.

Any ideas?

Re: [PyOpenGL-Users] import dependencies mess with py2exe

[Lorenzo M. <lma...@de...>]

Faudot Timothe wrote:
> Hello,
> 
> I am using py2exe to create en executable of a wxpython application in 
> which I use a glcanvas.
> My exe doesn't run for all the needed files are not included in the 
> executable.

If aren't tied to py2exe for some reason, I suggest you to try 
PyInstaller (http://pyinstaller.python-hosting.com): some time ago I 
contributed the support for PyOpenGL >=3.0.0b6, which now should work 
with no manual intervention needed.

PyOpenGL 2.x is also supported.

Remember to checkout PyInstaller trunk:

svn co http://svn.pyinstaller.python-hosting.com/trunk pyinstaller

because the latest stable version (1.3) is really outdated.

-- 
Lorenzo Mancini

Re: [PyOpenGL-Users] import dependencies mess with py2exe

[Mike C. F. <mcf...@vr...>]

Faudot Timothe wrote:
...
> And when I look at the archive, yes that's true that in the "platform" 
> folder of OpenGL for example there is only the __init__.pyc file
> And that's not the only issue, if I manually copy the missing files, I 
> get another folder that's missing its files, it's never ending!
>
> Why is that??
>
> I am using pyOpenGL3.0.0c1 , python2.5.2 , py2exe0.6.9, wxpython2.8.9.2
>   
Py2exe can't pick up imports that are done via plugin mechanisms such as 
see in PyOpenGL.  There's a mechanism in Py2exe to explicitly declare 
packages/modules as required.  Reports are that with the plugins 
registered the py2exe process works.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

[PyOpenGL-Users] import dependencies mess with py2exe

[Faudot T. <fau...@la...>]

Hello,

I am using py2exe to create en executable of a wxpython application in 
which I use a glcanvas.
My exe doesn't run for all the needed files are not included in the 
executable.
After launching py2exe I get this message:

The following modules appear to be missing
['OpenGL.platform.CurrentContextIsValid', 'OpenGL.platform.GL', 
'OpenGL.platform
.GLU', 'OpenGL.platform.GLUT', 'OpenGL.platform.GLUT_GUARD_CALLBACKS', 
'OpenGL.p
latform.PLATFORM', 'OpenGL.platform.createBaseFunction', 
'OpenGL_accelerate.wrap
per']

And when I look at the archive, yes that's true that in the "platform" 
folder of OpenGL for example there is only the __init__.pyc file
And that's not the only issue, if I manually copy the missing files, I 
get another folder that's missing its files, it's never ending!

Why is that??

I am using pyOpenGL3.0.0c1 , python2.5.2 , py2exe0.6.9, wxpython2.8.9.2

Thank you for your help!


Tim

[PyOpenGL-Users] Using the raw ctypes autogenerated wrappers

[Lorenzo M. <lma...@de...>]

Hi all,

the section "Autogenerated wrappers" in the document:

http://pyopengl.sourceforge.net/ctypes/development.html

states that it is possible to directly import and use the modules in the
OpenGL.raw packages, should one want to use the bare ctypes generated
wrappers directly.

My first approach to do that was replacing imports from OpenGL.GL to
imports from OpenGL.raw.GL in my code; all symbols were imported, I
could call functions and so on, but every immediate mode operation
failed on the call to glEnd, with the error system reporting an
unhelpful err 1282 "invalid operation".

Puzzled a lot, I started browsing PyOpenGL sources to find out that, if
OpenGL.ERROR_CHECKING is True (default, see OpenGL/__init__.py),
OpenGL/GL/exceptional.py decorates glBegin/glEnd adding some logic to
perform error checking.

Setting OpenGL.ERROR_CHECKING = False in my code allows it to run using
the raw ctypes wrappers (and get the nice 100% performance boost I was
looking for, at the cost of some ctypes pollution in the code), but that
looks like a kludge to me: what if one wants error checking with raw
wrappers?  Is that possible at all?

(btw this is on PyOpenGL 3.0.0c1, on Windows XP SP3)

Thanks in advance!

-- 
Lorenzo Mancini

[PyOpenGL-Users] PyOpenGL 3.0 with freeglut on Windows

[Patrick H. <pa...@13...>]

Has anyone tried using PyOpenGL 3.0 with freeglut on Windows? Using Python
2.6 and freeglut 2.4.0 compiled by Visual C++ 9.0, I get an error when
calling OpenGL.GLUT.glutInit() because __glutInitWithExit() is not part of
freeglut's glut32.dll. AFAICT, none of the GLUT Windows-specific extension
functions used in OpenGL.GLUT.special are included with freeglut. I can work
around this for my case easily, but I am not sure what the preferred
approach would be for fixing this in general. I would be happy to test and
submit a patch if I could get a hint or two about a way to do it that fits
with the PyOpenGL design goals.

While poking through the Python files in OpenGL/GLUT, I noticed that
HAVE_FREEGLUT in __init__.py is set to False when OpenGL.GLUT.freeglut
imports successfully and to True when it fails to import. That seems like
reversed logic to me. Is that a bug, or am I just misunderstanding something?

 -Patrick


-- 
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/