pyopengl-devel — Discussion of PyOpenGL development.

[PyOpenGL-Devel] [ pyopengl-Bugs-1145859 ] py2exe fails missing "version" file in OpenGL/__init__.py

[SourceForge.net <no...@so...>]

Bugs item #1145859, was opened at 2005-02-22 00:59
Message generated for change (Comment added) made by giovannibajo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1145859&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: install
Group: v2.0.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John A Meinel (jfmeinel)
Assigned to: Nobody/Anonymous (nobody)
Summary: py2exe fails missing "version" file in OpenGL/__init__.py

Initial Comment:
In OpenGL/__init__.py you find out the current version
by doing:
	filename = os.path.join(os.path.dirname(__file__),
'version')
	__version__ = string.strip(open(filename).read())

However, once things are packed up by py2exe,
__init__.py is actually inside a zipfile, and there is
no "version" file for it to read.

The easiest fix that I've found is to just wrap the
above in a try/except block, and use whatever the
current version should be.

For example
    try:
        filename =
os.path.join(os.path.dirname(__file__), 'version')
        __version__ = string.strip(open(filename).read())
    except OSError:
        __version__ = '2.0.2.01'


Even if you did something that indicated an "unknown"
version, or something else, it would be nice to have
pyOpenGL work out of the box when packed up.

Thanks,
John


----------------------------------------------------------------------

Comment By: Giovanni Bajo (giovannibajo)
Date: 2008-02-25 02:10

Message:
Logged In: YES 
user_id=727687
Originator: NO

I'll notice that PyInstaller has a stable workaround for this bug, so it
can be used with stock PyOpenGL.

----------------------------------------------------------------------

Comment By: Giovanni Bajo (giovannibajo)
Date: 2005-08-23 18:39

Message:
Logged In: YES 
user_id=727687

I have the very same problem. Can we get a fix for this bug?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1145859&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1827190 ] Default (Numpy) array return values not accepted

[SourceForge.net <no...@so...>]

Bugs item #1827190, was opened at 2007-11-06 23:35
Message generated for change (Comment added) made by giovannibajo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1827190&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris Waters (crwaters)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: Default (Numpy) array return values not accepted

Initial Comment:
The values returned by the default array type, numpy, are not accepted by OpenGL; more importantly, they are not accepted by the respective set/bind functions.

This output is from the attached test file, run with the latest CVS revision:

glGenTextures(1) -> 1 (<type 'long'>)
glGenTextures(2) -> [2 3] (list: <type 'numpy.ndarray'>, elements: <type 'numpy.uint32'>)
Calling: glBindTexture(GL_TEXTURE_2D, 1)
         (created from glGenTextures(1))
    No Exceptions
Calling: glBindTexture(GL_TEXTURE_2D, 2)
         (created from glGenTextures(2), element 0)
    Exception Caught: argument 2: <type 'exceptions.TypeError'>: wrong type

The returned type of the array is numpy.ndarray, with each element having the type numpy.uint32. This element type is also not immediately convertable to a function argument type such as GLuint.

The return type of glGenTextures(1), however, is of the type long due to the special-case functionality. This is not the case for functions that do not handle special cases similar to this, such as OpenGL.GL.EXT.framebuffer_object.glGenFramebuffersEXT

A quick global work-around is to change the array type to ctypes after importing OpenGL:
 from OpenGL.arrays import formathandler
 formathandler.FormatHandler.chooseOutput( 'ctypesarrays' )

----------------------------------------------------------------------

Comment By: Giovanni Bajo (giovannibajo)
Date: 2008-02-25 01:59

Message:
Logged In: YES 
user_id=727687
Originator: NO

Right, I saw this in Python 2.5.2 changelog:

- The ctypes int types did not accept objects implementing
  __int__() in the constructor.

Nice to see this bug squashed then (it was really annoying to debug
because numpy array/integers look like python basic types in repr!).

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-02-25 00:46

Message:
Logged In: YES 
user_id=34901
Originator: NO

AFAIK the default was *never* ctypes arrays.  ctypes arrays aren't
generally compatible with Numpy/Numeric-assuming code, so they are far more
likely to cause coding problems than Numpy scalars.  Thomas has fixed the
bug in ctypes (which wasn't calling __int__ on the values), so with the
next point release of Python we should see the problem fix itself.

----------------------------------------------------------------------

Comment By: Giovanni Bajo (giovannibajo)
Date: 2008-02-25 00:12

Message:
Logged In: YES 
user_id=727687
Originator: NO

Thus, can't we switch the default back to ctypesarrays until this is
resolved (if ever)?

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-08 01:50

Message:
Logged In: YES 
user_id=34901
Originator: NO

Seems "pending" is considered "closed" for some reason.  Reopening so it's
not lost.

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-08 01:49

Message:
Logged In: YES 
user_id=34901
Originator: NO

Hmm, maybe I'm just having a bad ctypes day, but I don't see how to take
the buffer object (the proposed work-around) and convert its contents to a
ctypes.c_* type.  The buffer must have knowledge of its internal address,
but I don't see a member that gives me access to it.

Even if it did work, we'd be in the same boat with an extra Python
function call introduced as overhead for every single simple data-type
parameter.  This needs to happen down in the C code in ctypes to have any
hope of being fast enough IMO.

----------------------------------------------------------------------

Comment By: Andrew Straw (astraw)
Date: 2008-01-07 22:54

Message:
Logged In: YES 
user_id=210276
Originator: NO

I forwarded this bug report to the numpy-discussion list, where a bugfix
was implemented and workaround was discussed:

http://projects.scipy.org/pipermail/numpy-discussion/2008-January/030670.html

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-07 19:32

Message:
Logged In: YES 
user_id=34901
Originator: NO

I've added an optional flag to the top-level module which allows for using
numpy scalars. ALLOW_NUMPY_SCALARS which when true allows your test case to
succeed.

Coded in Python, however, it's rather slow (and rather poorly
implemented).  I looked into implementing this using the
__array_interface__ on scalars, but the data-pointer there appears to be
randomly generated.  Without that, a conversion at the Python level and
then passing onto the original function seems the only solution.

I doubt we'll get a *good* solution to this in the near term.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1827190&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1827190 ] Default (Numpy) array return values not accepted

[SourceForge.net <no...@so...>]

Bugs item #1827190, was opened at 2007-11-06 17:35
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1827190&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris Waters (crwaters)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: Default (Numpy) array return values not accepted

Initial Comment:
The values returned by the default array type, numpy, are not accepted by OpenGL; more importantly, they are not accepted by the respective set/bind functions.

This output is from the attached test file, run with the latest CVS revision:

glGenTextures(1) -> 1 (<type 'long'>)
glGenTextures(2) -> [2 3] (list: <type 'numpy.ndarray'>, elements: <type 'numpy.uint32'>)
Calling: glBindTexture(GL_TEXTURE_2D, 1)
         (created from glGenTextures(1))
    No Exceptions
Calling: glBindTexture(GL_TEXTURE_2D, 2)
         (created from glGenTextures(2), element 0)
    Exception Caught: argument 2: <type 'exceptions.TypeError'>: wrong type

The returned type of the array is numpy.ndarray, with each element having the type numpy.uint32. This element type is also not immediately convertable to a function argument type such as GLuint.

The return type of glGenTextures(1), however, is of the type long due to the special-case functionality. This is not the case for functions that do not handle special cases similar to this, such as OpenGL.GL.EXT.framebuffer_object.glGenFramebuffersEXT

A quick global work-around is to change the array type to ctypes after importing OpenGL:
 from OpenGL.arrays import formathandler
 formathandler.FormatHandler.chooseOutput( 'ctypesarrays' )

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-02-24 18:46

Message:
Logged In: YES 
user_id=34901
Originator: NO

AFAIK the default was *never* ctypes arrays.  ctypes arrays aren't
generally compatible with Numpy/Numeric-assuming code, so they are far more
likely to cause coding problems than Numpy scalars.  Thomas has fixed the
bug in ctypes (which wasn't calling __int__ on the values), so with the
next point release of Python we should see the problem fix itself.

----------------------------------------------------------------------

Comment By: Giovanni Bajo (giovannibajo)
Date: 2008-02-24 18:12

Message:
Logged In: YES 
user_id=727687
Originator: NO

Thus, can't we switch the default back to ctypesarrays until this is
resolved (if ever)?

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-07 19:50

Message:
Logged In: YES 
user_id=34901
Originator: NO

Seems "pending" is considered "closed" for some reason.  Reopening so it's
not lost.

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-07 19:49

Message:
Logged In: YES 
user_id=34901
Originator: NO

Hmm, maybe I'm just having a bad ctypes day, but I don't see how to take
the buffer object (the proposed work-around) and convert its contents to a
ctypes.c_* type.  The buffer must have knowledge of its internal address,
but I don't see a member that gives me access to it.

Even if it did work, we'd be in the same boat with an extra Python
function call introduced as overhead for every single simple data-type
parameter.  This needs to happen down in the C code in ctypes to have any
hope of being fast enough IMO.

----------------------------------------------------------------------

Comment By: Andrew Straw (astraw)
Date: 2008-01-07 16:54

Message:
Logged In: YES 
user_id=210276
Originator: NO

I forwarded this bug report to the numpy-discussion list, where a bugfix
was implemented and workaround was discussed:

http://projects.scipy.org/pipermail/numpy-discussion/2008-January/030670.html

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-07 13:32

Message:
Logged In: YES 
user_id=34901
Originator: NO

I've added an optional flag to the top-level module which allows for using
numpy scalars. ALLOW_NUMPY_SCALARS which when true allows your test case to
succeed.

Coded in Python, however, it's rather slow (and rather poorly
implemented).  I looked into implementing this using the
__array_interface__ on scalars, but the data-pointer there appears to be
randomly generated.  Without that, a conversion at the Python level and
then passing onto the original function seems the only solution.

I doubt we'll get a *good* solution to this in the near term.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1827190&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1827190 ] Default (Numpy) array return values not accepted

[SourceForge.net <no...@so...>]

Bugs item #1827190, was opened at 2007-11-06 23:35
Message generated for change (Comment added) made by giovannibajo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1827190&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris Waters (crwaters)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: Default (Numpy) array return values not accepted

Initial Comment:
The values returned by the default array type, numpy, are not accepted by OpenGL; more importantly, they are not accepted by the respective set/bind functions.

This output is from the attached test file, run with the latest CVS revision:

glGenTextures(1) -> 1 (<type 'long'>)
glGenTextures(2) -> [2 3] (list: <type 'numpy.ndarray'>, elements: <type 'numpy.uint32'>)
Calling: glBindTexture(GL_TEXTURE_2D, 1)
         (created from glGenTextures(1))
    No Exceptions
Calling: glBindTexture(GL_TEXTURE_2D, 2)
         (created from glGenTextures(2), element 0)
    Exception Caught: argument 2: <type 'exceptions.TypeError'>: wrong type

The returned type of the array is numpy.ndarray, with each element having the type numpy.uint32. This element type is also not immediately convertable to a function argument type such as GLuint.

The return type of glGenTextures(1), however, is of the type long due to the special-case functionality. This is not the case for functions that do not handle special cases similar to this, such as OpenGL.GL.EXT.framebuffer_object.glGenFramebuffersEXT

A quick global work-around is to change the array type to ctypes after importing OpenGL:
 from OpenGL.arrays import formathandler
 formathandler.FormatHandler.chooseOutput( 'ctypesarrays' )

----------------------------------------------------------------------

Comment By: Giovanni Bajo (giovannibajo)
Date: 2008-02-25 00:12

Message:
Logged In: YES 
user_id=727687
Originator: NO

Thus, can't we switch the default back to ctypesarrays until this is
resolved (if ever)?

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-08 01:50

Message:
Logged In: YES 
user_id=34901
Originator: NO

Seems "pending" is considered "closed" for some reason.  Reopening so it's
not lost.

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-08 01:49

Message:
Logged In: YES 
user_id=34901
Originator: NO

Hmm, maybe I'm just having a bad ctypes day, but I don't see how to take
the buffer object (the proposed work-around) and convert its contents to a
ctypes.c_* type.  The buffer must have knowledge of its internal address,
but I don't see a member that gives me access to it.

Even if it did work, we'd be in the same boat with an extra Python
function call introduced as overhead for every single simple data-type
parameter.  This needs to happen down in the C code in ctypes to have any
hope of being fast enough IMO.

----------------------------------------------------------------------

Comment By: Andrew Straw (astraw)
Date: 2008-01-07 22:54

Message:
Logged In: YES 
user_id=210276
Originator: NO

I forwarded this bug report to the numpy-discussion list, where a bugfix
was implemented and workaround was discussed:

http://projects.scipy.org/pipermail/numpy-discussion/2008-January/030670.html

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-07 19:32

Message:
Logged In: YES 
user_id=34901
Originator: NO

I've added an optional flag to the top-level module which allows for using
numpy scalars. ALLOW_NUMPY_SCALARS which when true allows your test case to
succeed.

Coded in Python, however, it's rather slow (and rather poorly
implemented).  I looked into implementing this using the
__array_interface__ on scalars, but the data-pointer there appears to be
randomly generated.  Without that, a conversion at the Python level and
then passing onto the original function seems the only solution.

I doubt we'll get a *good* solution to this in the near term.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1827190&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1900757 ] glAreTexturesResident function is broken (doesn't match docs

[SourceForge.net <no...@so...>]

Bugs item #1900757, was opened at 2008-02-24 02:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1900757&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: glAreTexturesResident function is broken (doesn't match docs

Initial Comment:
using pyOpenGl 3.0.0b1 and the glAreTexturesResident() function.

Documentation (take it its fairly old: http://pyopengl.sourceforge.net/documentation/manual/glAreTexturesResident.3G.xml) says usage is

glAreTexturesResident(textures[]) → residences[]

But using it like this gives:

ValueError: glAreTexturesResident requires 3 arguments (n, textures, residences), received 1: ([1L],)

Either the glAreTexturesResident() function needs to be fixed to this more pythonic syntax, or the documentation updated to reflect the more C like syntax. I would like to see the former. Keeping the pythonic approach.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1900757&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Patches-805324 ] McMillian Installer and &quot; version&quot; file

[SourceForge.net <no...@so...>]

Patches item #805324, was opened at 2003-09-12 22:55
Message generated for change (Comment added) made by giovannibajo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305988&aid=805324&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Shane Holloway (shane_holloway)
Assigned to: Tarn Weisner Burton (twburton)
Summary: McMillian Installer and "version" file

Initial Comment:
After fiddling with the McMillian Installer
(http://www.mcmillan-inc.com/install5_intro.html) and
my little PyOpenGL client application, I found what was
causing the OpenGL import to fail -- the reading of the
"version" file in the root of the package.  

If you are not familar with the McMillian Installer, it
effecitvely zips up all modules and packages your
application is dependent upon, and packs that
information to the tail end of an executable file.  It
does this by detecting all imports and also has a
mechanism for adding modules manually.  However, it
does not have a mechanism for detecting or including
standard files in the fashion that OpenGL/__init__.py
file is using.  So therefore, it has trouble importing
OpenGL in the McMillian Installer, and thus my patch.  :)

There are a few ways in which we can accomplish fixing
this problem.

1.  We could hard code the version number in the
__init__.py (yuck! -- that's why there is a "version"
file in the first place)
2.  We can do a try/except block around the reading of
the file.  (what value does OpenGL.__version__ get when
this error occurs?  If we set it to some default value,
this potentially changes the behavior of any version
dependent code in the application.  This is
undersierable...  I like things to work the same in or
out of the packaging.
3.  We can rename "version" to "__version__.py", change
the syntax slightly, and change the "__init__.py" file
to deal with those new changes.  (This allows packaging
implementations like Installer and cx_Freeze detect the
import and include it in the packaging.)

I like the 3rd option the best, and thereby have
created a patch to implement that feature.



----------------------------------------------------------------------

Comment By: Giovanni Bajo (giovannibajo)
Date: 2008-02-15 01:04

Message:
Logged In: YES 
user_id=727687
Originator: NO

This bug is fully outdated and can be safely closed. McMillan Installer is
no more, and its successor (PyInstaller, http://www.pyinstaller.org) does
not have this problem since it contains a builtin workaround for PyOpenGL.

----------------------------------------------------------------------

Comment By: Shane Holloway (shane_holloway)
Date: 2003-09-12 22:58

Message:
Logged In: YES 
user_id=283742

Sorry, I could not figure out how to get the file to be in
the patch without adding it to cvs first...  What's the
magic phrase?  Anyhow, this file should complement the patch
by going into PyOpenGL2/OpenGL/__version__.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305988&aid=805324&group_id=5988

[PyOpenGL-Devel] Help

[Sibtey M. <si...@in...>]

Hi All

        I am new to PyOpenGl and want to use 2D graphics, to create
rectangle to represent some information. Is there any 2D graphics library
that is supported by pygame that will be a better option instead of using
PyOpenGl?

 

Thanks,

Sibtey Mehdi

 

[PyOpenGL-Devel] [ pyopengl-Bugs-1892167 ] Shader related error reporting is broken

[SourceForge.net <no...@so...>]

Bugs item #1892167, was opened at 2008-02-12 11:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1892167&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Shader related error reporting is broken

Initial Comment:
In pyopengl-ctypes CVS:
When trying to compile an erroneous shader pyopengl returns the following error:

  File "/usr/lib/python2.5/site-packages/OpenGL/GL/VERSION/GL_2_0.py", line 85, in GLSLCheckError
    description= glGetInfoLog( cArguments[0] )
NameError: global name 'glGetInfoLog' is not defined

After adding "from OpenGL.GL.ARB.shader_objects import glGetInfoLogARB as glGetInfoLog" to GL_2.0.py the following error appears:

  File "/usr/lib/python2.5/site-packages/OpenGL/GL/ARB/shader_objects.py", line 120, in glGetInfoLogARB
    log = ctypes.create_string_buffer(length)
  File "/usr/lib/python2.5/ctypes/__init__.py", line 73, in create_string_buffer
    raise TypeError, init
TypeError: 220

The preceding call to glGetObjectParameterivARB returns a "length" that is of type numpy.int32 while ctypes expects long or int.
After casting "length" to int, the program now throws the proper GLError.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1892167&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1887247 ] Install error on Mac OS X

[SourceForge.net <no...@so...>]

Bugs item #1887247, was opened at 2008-02-05 21:27
Message generated for change (Settings changed) made by neppord
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1887247&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: install
>Group: v2.0.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Neppord (neppord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install error on Mac OS X

Initial Comment:
There is an error in the newest darwin.py file

there is a "GLUT" that should be "glut".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1887247&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1887247 ] Install error on Mac OS X

[SourceForge.net <no...@so...>]

Bugs item #1887247, was opened at 2008-02-05 21:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1887247&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: install
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Neppord (neppord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Install error on Mac OS X

Initial Comment:
There is an error in the newest darwin.py file

there is a "GLUT" that should be "glut".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1887247&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1878648 ] glShaderSource wrapper not loaded properly

[SourceForge.net <no...@so...>]

Bugs item #1878648, was opened at 2008-01-23 22:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1878648&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: tkerwin (tkerwin)
Assigned to: Nobody/Anonymous (nobody)
Summary: glShaderSource wrapper not loaded properly

Initial Comment:
When I try to use glShaderSource, I get this error message:

  File "C:\Python25\Lib\site-packages\OpenGL\platform\baseplatform.py", line 253, in __call__
    return self( *args, **named )
TypeError: this function takes 4 arguments (2 given)

I was expecting it to require two arguments from the documentation.  From glancing at the code, it seems like the wrapper is in there, but perhaps not loading properly.  Is there any workaround for this to get shaders working?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1878648&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1498439 ] glTexImage1/2/3D does not allow NULL texture data

[SourceForge.net <no...@so...>]

Bugs item #1498439, was opened at 2006-05-31 19:27
Message generated for change (Comment added) made by illume
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1498439&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v2.0.1
>Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: glTexImage1/2/3D does not allow NULL texture data

Initial Comment:
The glTexImage1/2/3D calls do not allow NULL texture 
data to be passed in. For example, the following 
valid OpenGL call fails with a TypeError:

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, 512, 512, 0, 
GL_RGB, GL_INT, None)

File "gl.pyx", line 592, in gl.glTexImage2D
TypeError: expected string or Unicode object, 
NoneType found

A NULL texture is useful when you want to create a 
render target texture or a texture whose content will 
be defined at a later time.

Regards,
Sami Kyöstilä <sky...@TH...>


----------------------------------------------------------------------

>Comment By: Rene Dudfield (illume)
Date: 2008-01-23 01:10

Message:
Logged In: YES 
user_id=2042
Originator: NO

What about allowing the use of 0?

Often in example opengl code 0 is used, and not NULL.  Passing in 0
currently fails - where I think it should act as C opengl does.  This would
allow more copy/paste examples to work from C code.

cu,

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-20 03:04

Message:
Logged In: YES 
user_id=34901
Originator: NO

This is now working in 3.x CVS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1498439&group_id=5988

[PyOpenGL-Devel] GLSL GPGPU demo - with a crash. Please help?

[<re...@gm...>]

Hi,

this could be a good demo + test for GLSL, and basic GPGPU processing with GLSL.

http://rene.f0o.com/~rene/stuff/gpudemo.py

1. basic glsl usage.
2. basic GPGPU style usage.


1. It requires opengl-ctypes latest cvs.  It works correctly with the command:

python gpudemo.py basic

That just shows a tea pot using a basic shader.



2. To run the GPGPU demo call it like this:
python gpudemo.py


This works correctly almost.   It crashes on program exit... The
results printed out are correct.  It appears to be a reference
counting type problem.

I've tried it on OSX with an ATI card.


So if people can test this, and debug it I'll clean it up and add it
as a nice demo for pyopengl.  I think it must have something to do
with the array handling... or something :)


cu,

Re: [PyOpenGL-Devel] Could someone with Win32 and/or OS-X test latest CVS

[<re...@gm...>]

Hi,

do you still need this tested?  I can help on OSX, and XP as well as debian.

After I run setup.py develop then how do I test?

cheers,


On Jul 9, 2007 1:16 PM, Mike C. Fletcher <mcf...@vr...> wrote:
> I've been eliminating the hard-coded platform implementation restriction
> (i.e. allowing people to write plug-ins for supporting other
> platforms).  In doing so I've had to rewrite the platform
> implementations.  I don't have a real Win32 or OS-X environment on which
> to test, however.
>
> Anyway, if someone could check out the code from CVS on those platforms,
> run setup.py develop, and then test to see if we have working
> extensions, GLUT, GLE and the like, that would be helpful.
>
> There's also an experimental script in the src directory for
> downloading/installing the GLUT and GLE dlls automatically on Win32 in
> case someone wants to try that.  I've also made it possible to
> completely disable error checking by setting a flag before you import
> the various modules (OpenGL.ERROR_CHECKING).
>
> Have fun all,
> Mike
>
> --
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Devel mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
>

[PyOpenGL-Devel] OpenGL/GL/VERSION/GL_2_0.py fix.

[<re...@gm...>]

hi,

'getter' inside of GLSLCheckError was used incorrectly inside
OpenGL/GL/VERSION/GL_2_0.py.  2 args, instead of required 3.  Fixed.

Applied to cvs too.


cheers,

[PyOpenGL-Devel] [ pyopengl-Bugs-1266693 ] segfault when non-float arg to glColor4v()

[SourceForge.net <no...@so...>]

Bugs item #1266693, was opened at 2005-08-22 21:35
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1266693&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Maciej Kalisiak (mackal)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: segfault when non-float arg to glColor4v()

Initial Comment:
"Bad things"(TM) happen when a non-float is passed to
glColor4v().  Specific case I ran into: by mistake I
happened to pass a somewhat complex class object as the
fourth element of the vector.  This caused a segfault
immediately (SDL parachute deployed, etc.)  I haven't
tested to see whether this occurs with the class object
in the other vector positions, but I imagine so, seeing
as how this is probably caused by Pyopengl passing the
arguments directly to OpenGL, without checking validity.


----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-19 22:10

Message:
Logged In: YES 
user_id=34901
Originator: NO

Version 3.x guards against this and does not crash on tests with the
situation described.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1266693&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1498439 ] glTexImage1/2/3D does not allow NULL texture data

[SourceForge.net <no...@so...>]

Bugs item #1498439, was opened at 2006-05-31 15:27
Message generated for change (Settings changed) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1498439&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v2.0.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: glTexImage1/2/3D does not allow NULL texture data

Initial Comment:
The glTexImage1/2/3D calls do not allow NULL texture 
data to be passed in. For example, the following 
valid OpenGL call fails with a TypeError:

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, 512, 512, 0, 
GL_RGB, GL_INT, None)

File "gl.pyx", line 592, in gl.glTexImage2D
TypeError: expected string or Unicode object, 
NoneType found

A NULL texture is useful when you want to create a 
render target texture or a texture whose content will 
be defined at a later time.

Regards,
Sami Kyöstilä <sky...@TH...>


----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-19 22:04

Message:
Logged In: YES 
user_id=34901
Originator: NO

This is now working in 3.x CVS.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1498439&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1579715 ] Probable int/int32 problem with version 3.0.0a4

[SourceForge.net <no...@so...>]

Bugs item #1579715, was opened at 2006-10-18 09:57
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1579715&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
>Status: Closed
>Resolution: Duplicate
Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: Probable int/int32 problem with version 3.0.0a4

Initial Comment:
With version 3.0.0a4, compiled on Linux 64 bits,
lesson18 in Demo/NeHe dies with:

Traceback (most recent call last):
  File "lesson18.py", line 302, in ?
    main()
  File "lesson18.py", line 294, in main
    InitGL(640, 480)
  File "lesson18.py", line 106, in InitGL
    LoadTextures()
  File "lesson18.py", line 76, in LoadTextures
    glBindTexture(GL_TEXTURE_2D, textures[0])   # 2d
texture (x and y size)
ctypes.ArgumentError: argument 2: exceptions.TypeError:
int expected instead of numpy.int32 instance


This may suggest that an explicit signature with int32
is needed (at least to accommodate 64 bits architectures,
since 32 bits architectures will find both int and int32
equivalent).

A fix can possibly made in several places, but
I would think that changing the signature of
glBindTexture for its secnd argument to int32 is 
what is needed.
 




----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-19 20:44

Message:
Logged In: YES 
user_id=34901
Originator: NO

This is being addressed (though not yet satisfactorily) under bug
#1827190, closing this ticket in favour of that.

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2006-11-07 13:37

Message:
Logged In: YES 
user_id=34901

This is a numpy migration issue.  I need to teach ctypes how
to handle numpy's "scalar" types (e.g. int32, int16), these
are now returned instead of regular Python integers when you
pull a value out of a numpy array.

----------------------------------------------------------------------

Comment By: lgautier (lgautier)
Date: 2006-10-18 09:59

Message:
Logged In: YES 
user_id=1623918

The entry above should have been logged under this account.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1579715&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1682476 ] Unknown specifier GL_MAX_COLOR_ATTACHMENTS_EXT (36063)

[SourceForge.net <no...@so...>]

Bugs item #1682476, was opened at 2007-03-16 19:17
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1682476&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unknown specifier GL_MAX_COLOR_ATTACHMENTS_EXT (36063)

Initial Comment:
Hello,

I can't get the following program to work:


import sys
from OpenGL.GLUT import *
from OpenGL.GL import *
from OpenGL.GL.EXT.framebuffer_object import *

argv = glutInit(sys.argv)
glutCreateWindow('foo')
if not glInitFramebufferObjectEXT():
    raise Exception, "framebuffer_object not available"

print glGenFramebuffersEXT(4)
print glGetIntegerv(GL_MAX_COLOR_ATTACHMENTS_EXT)


Here is the output:

[1 2 3 4]
Traceback (most recent call last):
  File "bugfbo.py", line 12, in ?
    print glGetIntegerv(GL_MAX_COLOR_ATTACHMENTS_EXT)
  File "build/bdist.linux-x86_64/egg/OpenGL/wrapper.py", line 1624, in __call__
  File "build/bdist.linux-x86_64/egg/OpenGL/wrapper.py", line 675, in wrapperCall
  File "build/bdist.linux-x86_64/egg/OpenGL/converters.py", line 195, in __call__
  File "build/bdist.linux-x86_64/egg/OpenGL/converters.py", line 234, in getSize
KeyError: ('Unknown specifier GL_MAX_COLOR_ATTACHMENTS_EXT (36063)', 'Failure in cConverter <OpenGL.converters.SizedOutput object at 0x2aaaadec7668>', [GL_MAX_COLOR_ATTACHMENTS_EXT], 1, <OpenGL.wrapper.glGetIntegerv object at 0x2aaaadecbe60>)

Do you have any idea how to fix this ?

Thank you.

-- Nicolas

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-19 20:42

Message:
Logged In: YES 
user_id=34901
Originator: NO

This should be fixed in current CVS.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-04-14 15:02

Message:
Logged In: NO 

Up !

Do you have any idea how to fix this ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1682476&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1736891 ] Seg fault on Ubuntu Fiesty x86-64 - 3.0.0a6

[SourceForge.net <no...@so...>]

Bugs item #1736891, was opened at 2007-06-14 00:51
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1736891&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GLUT
Group: v3.0.0
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Seg fault on Ubuntu Fiesty x86-64 - 3.0.0a6

Initial Comment:
With 
Python 2.5,Python-2.5.tar.bz2
numpy, numpy-1.0.tar.gz
PyOpenGL, PyOpenGL-3.0.0a6.tar.gz

OpenGL-ctypes/OpenGL/tests$ python test_glutwindow.py 
newArguments ['test_glutwindow.py']
Segmentation fault (core dumped)


This occurs on line 78
glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGB )

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-19 12:16

Message:
Logged In: YES 
user_id=34901
Originator: NO

Closing duplicate

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1736891&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1744414 ] ctypes.ArgumentError in glReadPixels

[SourceForge.net <no...@so...>]

Bugs item #1744414, was opened at 2007-06-27 15:04
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1744414&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: ctypes.ArgumentError in glReadPixels

Initial Comment:

We're running problems with glReadPixels throwing an exception. Here's the backtrace:

Traceback (most recent call last):
  File "/store/home/mukaissi/MetNetVis/MetNetVis/UI/graphdrawwidget.py", line 155, in mousePressEvent
    index=GL.glReadPixels(event.x,event.y,1,1,GL.GL_RGB,GL.GL_UNSIGNED_BYTE)
  File "/store/home/mukaissi/software/PyOpenGL-3.0.0a6/OpenGL/GL/images.py", line 279, in glReadPixels
    ctypes.c_void_p( arrayType.dataPointer(array))
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type

Adding a few prints to see the types of the involved variables they seem to be ok:

array: [[[0 0 0]]] <type 'numpy.ndarray'>
arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> <type '_ctypes.PointerType'>
dataPointer: 20509152 <type 'long'>

This is using 3.0.0a6 on an x86_64 (RHEL) system.

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-19 12:06

Message:
Logged In: YES 
user_id=34901
Originator: NO

With current CVS on AMD64 Gentoo the function appears to be working
correctly (as tested with the OpenGLContext/tests/saveimage.py script).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1744414&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1743168 ] ctypes.ArgumentError in glReadPixels

[SourceForge.net <no...@so...>]

Bugs item #1743168, was opened at 2007-06-25 17:54
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1743168&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
Status: Closed
Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ctypes.ArgumentError in glReadPixels

Initial Comment:

We're running problems with glReadPixels throwing an exception. Here's the backtrace:

Traceback (most recent call last):
  File "/store/home/mukaissi/MetNetVis/MetNetVis/UI/graphdrawwidget.py", line 155, in mousePressEvent
    index=GL.glReadPixels(event.x,event.y,1,1,GL.GL_RGB,GL.GL_UNSIGNED_BYTE)
  File "/store/home/mukaissi/software/PyOpenGL-3.0.0a6/OpenGL/GL/images.py", line 279, in glReadPixels
    ctypes.c_void_p( arrayType.dataPointer(array))
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type

Adding a few prints to see the types of the involved variables they seem to be ok:

array: [[[0 0 0]]] <type 'numpy.ndarray'>
arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> <type '_ctypes.PointerType'>
dataPointer: 20509152 <type 'long'>

This is using 3.0.0a6 on an x86_64 (RHEL) system.

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-19 11:54

Message:
Logged In: YES 
user_id=34901
Originator: NO

Closing duplicate.

----------------------------------------------------------------------

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-19 11:53

Message:
Logged In: YES 
user_id=34901
Originator: NO

Closing duplicate.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1743168&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1743168 ] ctypes.ArgumentError in glReadPixels

[SourceForge.net <no...@so...>]

Bugs item #1743168, was opened at 2007-06-25 17:54
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1743168&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ctypes.ArgumentError in glReadPixels

Initial Comment:

We're running problems with glReadPixels throwing an exception. Here's the backtrace:

Traceback (most recent call last):
  File "/store/home/mukaissi/MetNetVis/MetNetVis/UI/graphdrawwidget.py", line 155, in mousePressEvent
    index=GL.glReadPixels(event.x,event.y,1,1,GL.GL_RGB,GL.GL_UNSIGNED_BYTE)
  File "/store/home/mukaissi/software/PyOpenGL-3.0.0a6/OpenGL/GL/images.py", line 279, in glReadPixels
    ctypes.c_void_p( arrayType.dataPointer(array))
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type

Adding a few prints to see the types of the involved variables they seem to be ok:

array: [[[0 0 0]]] <type 'numpy.ndarray'>
arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> <type '_ctypes.PointerType'>
dataPointer: 20509152 <type 'long'>

This is using 3.0.0a6 on an x86_64 (RHEL) system.

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-19 11:53

Message:
Logged In: YES 
user_id=34901
Originator: NO

Closing duplicate.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1743168&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1742909 ] ctypes.ArgumentError in glReadPixels

[SourceForge.net <no...@so...>]

Bugs item #1742909, was opened at 2007-06-25 11:21
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1742909&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ctypes.ArgumentError in glReadPixels

Initial Comment:

We're running problems with glReadPixels throwing an exception. Here's the backtrace:

Traceback (most recent call last):
  File "/store/home/mukaissi/MetNetVis/MetNetVis/UI/graphdrawwidget.py", line 155, in mousePressEvent
    index=GL.glReadPixels(event.x,event.y,1,1,GL.GL_RGB,GL.GL_UNSIGNED_BYTE)
  File "/store/home/mukaissi/software/PyOpenGL-3.0.0a6/OpenGL/GL/images.py", line 279, in glReadPixels
    ctypes.c_void_p( arrayType.dataPointer(array))
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type

Adding a few prints to see the types of the involved variables they seem to be ok:

array: [[[0 0 0]]] <type 'numpy.ndarray'>
arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> <type '_ctypes.PointerType'>
dataPointer: 20509152 <type 'long'>

This is using 3.0.0a6 on an x86_64 (RHEL) system.

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-19 11:52

Message:
Logged In: YES 
user_id=34901
Originator: NO

Closing duplicate.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1742909&group_id=5988

[PyOpenGL-Devel] [ pyopengl-Bugs-1742607 ] ctypes.ArgumentError in glReadPixels

[SourceForge.net <no...@so...>]

Bugs item #1742607, was opened at 2007-06-24 20:39
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1742607&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GL
Group: v3.0.0
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ctypes.ArgumentError in glReadPixels

Initial Comment:

We're running problems with glReadPixels throwing an exception. Here's the backtrace:

Traceback (most recent call last):
  File "/store/home/mukaissi/MetNetVis/MetNetVis/UI/graphdrawwidget.py", line 155, in mousePressEvent
    index=GL.glReadPixels(event.x,event.y,1,1,GL.GL_RGB,GL.GL_UNSIGNED_BYTE)
  File "/store/home/mukaissi/software/PyOpenGL-3.0.0a6/OpenGL/GL/images.py", line 279, in glReadPixels
    ctypes.c_void_p( arrayType.dataPointer(array))
ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type

Adding a few prints to see the types of the involved variables they seem to be ok:

array: [[[0 0 0]]] <type 'numpy.ndarray'>
arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> <type '_ctypes.PointerType'>
dataPointer: 20509152 <type 'long'>

This is using 3.0.0a6 on an x86_64 (RHEL) system.

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-19 11:52

Message:
Logged In: YES 
user_id=34901
Originator: NO

Closing duplicate

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1742607&group_id=5988