pyopengl-devel — Discussion of PyOpenGL development.

[PyOpenGL-Devel] [ pyopengl-Bugs-1794394 ] crash with pyopengl

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

Bugs item #1794394, was opened at 2007-09-13 23:13
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1794394&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: None
Priority: 5
Private: No
Submitted By: Satyajit Sarangi (ssarangi)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: crash with pyopengl

Initial Comment:
Hi,
   whenever I try to run applications from within an IDE like IDLE or PyScripter then the program runs correctly but when I exit it, it gives me an error of unreferenced memory location read and crashes. 
Please help.
Thanks,
Satyajit

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

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

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

Many IDEs are written in such a way that you cannot cleanly run another
GUI program from within them.  That is due to conflicting GUI library
mainloops.  My guess would be that you are seeing that effect where the
"inner" event loop is terminating and trying to take everything with it
(doing cleanup that interferes with the parent mainloop).  Not normally a
PyOpenGL-specific problem, rather a problem in GUI library designs.

I'm closing the ticket for now, if you feel that's in error, please open a
new ticket with your script and why you feel this isn't a normal GUI
interaction error and I'll look into it further.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1869877 ] glColorPointer/ glVertexPointer broken

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

Bugs item #1869877, was opened at 2008-01-12 05:40
Message generated for change (Settings changed) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1869877&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: Mike C. Fletcher (mcfletch)
Summary: glColorPointer/ glVertexPointer broken

Initial Comment:
This might be related to bug 1067130, but I'm not sure, mark duplicate if needed.

In the attached script, the polygon is often miscoloured, or lacks vertexes. If I disable GL_COLOR_ARRAY, vertexes draw fine.
>From what I get it seems that calling glColorPointer overwrites some data in vertex pointer and/or vice versa.

I get distorted views like http://img292.imageshack.us/img292/5295/bugwd1.jpg, while I should get the full polygon.
If I change the order of functions artifacts change too and sometimes disappear, but nothing predictable.

The similar program in C runs fine, so it is unlikely to be a driver issue.

System used: Ubuntu Linux, kernel 2.6.22
pyopengl 3.0.0
Python 2.5.1

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

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

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

With current CVS I can't reproduce the problem.  I'm guessing this was the
same bug as fixed a while ago where the two arrays were both getting stored
as floats and the caching code was storing them using their type rather
than their role.

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

Comment By: Vytas (vytaslt)
Date: 2008-01-12 05:44

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

I am the submitter just forgot to login 

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1869877 ] glColorPointer/ glVertexPointer broken

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

Bugs item #1869877, was opened at 2008-01-12 12:40
Message generated for change (Comment added) made by vytaslt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1869877&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: glColorPointer/ glVertexPointer broken

Initial Comment:
This might be related to bug 1067130, but I'm not sure, mark duplicate if needed.

In the attached script, the polygon is often miscoloured, or lacks vertexes. If I disable GL_COLOR_ARRAY, vertexes draw fine.
>From what I get it seems that calling glColorPointer overwrites some data in vertex pointer and/or vice versa.

I get distorted views like http://img292.imageshack.us/img292/5295/bugwd1.jpg, while I should get the full polygon.
If I change the order of functions artifacts change too and sometimes disappear, but nothing predictable.

The similar program in C runs fine, so it is unlikely to be a driver issue.

System used: Ubuntu Linux, kernel 2.6.22
pyopengl 3.0.0
Python 2.5.1

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

Comment By: Vytas (vytaslt)
Date: 2008-01-12 12:44

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

I am the submitter just forgot to login 

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1869877 ] glColorPointer/ glVertexPointer broken

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

Bugs item #1869877, was opened at 2008-01-12 02:40
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=1869877&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: glColorPointer/ glVertexPointer broken

Initial Comment:
This might be related to bug 1067130, but I'm not sure, mark duplicate if needed.

In the attached script, the polygon is often miscoloured, or lacks vertexes. If I disable GL_COLOR_ARRAY, vertexes draw fine.
>From what I get it seems that calling glColorPointer overwrites some data in vertex pointer and/or vice versa.

I get distorted views like http://img292.imageshack.us/img292/5295/bugwd1.jpg, while I should get the full polygon.
If I change the order of functions artifacts change too and sometimes disappear, but nothing predictable.

The similar program in C runs fine, so it is unlikely to be a driver issue.

System used: Ubuntu Linux, kernel 2.6.22
pyopengl 3.0.0
Python 2.5.1

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1869877&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-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 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: Pending
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-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 22:35
Message generated for change (Comment added) made by astraw
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: Pending
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: Andrew Straw (astraw)
Date: 2008-01-07 21: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 18: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: Pending
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-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-1828695 ] [Win32] TypeError: 'staticmethod' object is not callable

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

Bugs item #1828695, was opened at 2007-11-08 20:36
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1828695&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: v3.0.0
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [Win32] TypeError: 'staticmethod' object is not callable

Initial Comment:
WindowsXP SP2
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32
OpenGL-ctypes latest CVS

  File "c:\python25\lib\site-packages\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\platform\win32.py", line 69, in safeGetError
    return glGetError()
TypeError: 'staticmethod' object is not callable

On any OpenGL call in Win32.

Culprit seems to be found at OpenGL/platform/win32.py : line 72:
glGetError = staticmethod( Win32Platform.OpenGL.glGetError )

Naive removal of the 'staticmethod' call remedies the error.

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

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

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

Win32 platform now fixed.  thanks.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1850600 ] glMultMatrix does not work correctly with transposed arrays

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

Bugs item #1850600, was opened at 2007-12-14 03:46
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1850600&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: Fixed
Priority: 5
Private: No
Submitted By: Toon Verstraelen (tovrstra)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: glMultMatrix does not work correctly with transposed arrays

Initial Comment:
Hello,

In the example attached, it shown that the function glMultMatrixf does not work correctly with transposed arrays. Apparently, the strides of a numpy.array object are ignored. This problem is present in version 3.0.0a6. It was not present in the 2.x versions.

In the program bug.py, the relevant part is marked by comments 'BEGIN INTERESTING PART' and 'END INTERESTING PART'. When transf.transpose() is given as argument, glGetFloatv(GL_MODELVIEW_MATRIX) clearly shows the problem. When transf.transpose().copy() is given as argument, the problem is 'fixed', but not in a very satisfying way.

cheers,

Toon

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

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

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

Code that was supposed to force to contiguous as a side-effect does not,
in fact, force to contiguous form.  CVS now uses an explicit function to
force to contiguous.  Test case added.

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

Comment By: Mike C. Fletcher (mcfletch)
Date: 2008-01-07 10:35

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

I'll take a look at the test case. PyOpenGL 2.x was doing a copy *all* the
time, so it was always using the unsatisfying solution.  PyOpenGL 3.x
*tries* not to do a copy, but it *should* do a copy (in the same manor)
under the covers... it doesn't try to figure out your array strides or the
like.  In this case it's apparently failing to do the copy when it should.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1819348 ] OpenGL.GL.GL_ALL_ATTRIB_BITS has bad value

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

Bugs item #1819348, was opened at 2007-10-24 10:29
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1819348&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: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: OpenGL.GL.GL_ALL_ATTRIB_BITS has bad value

Initial Comment:
On a Mac OS X 10.4.9 straightforward tarball build (PyOpenGL-3.0.0a6) the value of the constant OpenGL.GL.GL_ALL_ATTRIB_BITS is wrong (so glPushAttrib(GL_ALL_ATTRIB_BITS) won't work).
The gl.h header says

#define GL_ALL_ATTRIB_BITS 0x000fffff

but the value is 4294967295.

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

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

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

Weird, don't see how that got to that value.  Anyway, current CVS has the
correct value in place.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1836665 ] demo/redbook/fog.py nonworking

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

Bugs item #1836665, was opened at 2007-11-22 16:03
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1836665&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: Demo
Group: v3.0.0
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Janto Dreijer (janto_d)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: demo/redbook/fog.py nonworking

Initial Comment:
It seems an old version (pre-2002?) of fog.py is still distributed. There is a working version attached to
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=617949&group_id=5988

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

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

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

Seems the fixed version got dropped during the switch to a separate
project. The version in the Demo project now runs and shows the changing
fog characteristics properly.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1850600 ] glMultMatrix does not work correctly with transposed arrays

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

Bugs item #1850600, was opened at 2007-12-14 03:46
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1850600&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: Toon Verstraelen (tovrstra)
Assigned to: Nobody/Anonymous (nobody)
Summary: glMultMatrix does not work correctly with transposed arrays

Initial Comment:
Hello,

In the example attached, it shown that the function glMultMatrixf does not work correctly with transposed arrays. Apparently, the strides of a numpy.array object are ignored. This problem is present in version 3.0.0a6. It was not present in the 2.x versions.

In the program bug.py, the relevant part is marked by comments 'BEGIN INTERESTING PART' and 'END INTERESTING PART'. When transf.transpose() is given as argument, glGetFloatv(GL_MODELVIEW_MATRIX) clearly shows the problem. When transf.transpose().copy() is given as argument, the problem is 'fixed', but not in a very satisfying way.

cheers,

Toon

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

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

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

I'll take a look at the test case. PyOpenGL 2.x was doing a copy *all* the
time, so it was always using the unsatisfying solution.  PyOpenGL 3.x
*tries* not to do a copy, but it *should* do a copy (in the same manor)
under the covers... it doesn't try to figure out your array strides or the
like.  In this case it's apparently failing to do the copy when it should.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1854632 ] gluTessVertex function take wrong data

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

Bugs item #1854632, was opened at 2007-12-20 00:07
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1854632&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: GLU
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: gluTessVertex function take wrong data

Initial Comment:
Windows XP 32bit, Python2.5.1
When running tests.py in PyOpenGL3.0.0b1 from cvs, I got the flowing output:
.........error 12590456
E.
======================================================================
ERROR: Test that tessellation works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\tests.py", line 225, in test_tess
    gluTessEndPolygon(tobj);
WindowsError: exception code 0xc01d78

----------------------------------------------------------------------
Ran 11 tests in 3.469s

FAILED (errors=1)

I'm sure that it's caused by a bug in gluTessVertex function.

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

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

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

There was at least one major bug in the gluTess* functions (wrong
ctypes-level function type) which would cause win32 failures, which is
fixed in the first beta.  We're still seeing occasional failures on win32
tessellation, though.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1859019 ] unable to import GLUT

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

Bugs item #1859019, was opened at 2007-12-27 12:47
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1859019&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: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: unable to import GLUT

Initial Comment:
I get the following error upon a command:


>>> from OpenGL.GLUT import *

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    from OpenGL.GLUT import *
  File "build\bdist.win32\egg\OpenGL\GLUT\__init__.py", line 4, in <module>
  File "build\bdist.win32\egg\OpenGL\GLUT\special.py", line 73, in <module>
AttributeError: 'NoneType' object has no attribute 'glutDestroyWindow'




Please help me to get GLUT to work

sha...@ya...


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

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

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

Your problem is likely that GLUT is not installed, or is installed
somewhere other than on the system's library lookup path.  The newest code
uses checks that allow GLUT not to be installed and still import the GLUT
module, but that doesn't address your problem, which is most likely just a
system setup issue.  Closing for now.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1863687 ] Error in 3.0.0b1 loading extendes GL functions

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

Bugs item #1863687, was opened at 2008-01-03 19:46
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1863687&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: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: Error in 3.0.0b1 loading extendes GL functions

Initial Comment:
There is an Error in the baseplatform.py under Windows.
functionTypeFor cannot be found in the load method of _NullFunctionPointer class.

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

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

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

Fixed in current CVS.

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

Comment By: Markus Wankus (markus_wankus)
Date: 2008-01-05 17:03

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

More specifically, the error is:

  File
"c:\python25\lib\site-packages\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\platform\baseplatform.py",
line 234, in load
    func = functionTypeFor( self.DLL )(
NameError: global name 'functionTypeFor' is not defined


This can be fixed by changing the line in question from:

func = functionTypeFor( self.DLL )(

to:

func = platform.PLATFORM.functionTypeFor( self.DLL )(

Mark.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1864674 ] PyOpenGL fails to pickle GL constants on Windows

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

Bugs item #1864674, was opened at 2008-01-05 15:03
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1864674&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: v3.0.0
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Mike C. Fletcher (mcfletch)
Summary: PyOpenGL fails to pickle GL constants on Windows

Initial Comment:
On a Windows XP machine using Python2.5 and PyOpenGL-3.0.0a7, an attempt to cPickle a
GL constant fails on loading it back in.

Here's the error produced:

Traceback (most recent call last):
  File "tp.py", line 11, in <module>
    print cPickle.load(f)
TypeError: __new__() takes exactly 3 arguments (2 given)


Here's the tiny example that produced that error:

import cPickle
from OpenGL.GL import GL_DECAL

print type(GL_DECAL), int(GL_DECAL)

f = open('dumpfile','wb')
cPickle.dump(GL_DECAL,f,2)
f.close()

f = open('dumpfile','rb')
print cPickle.load(f)
f.close()

Gary Herron
gh...@di...

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

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

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

Fixed in the beta release.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1863687 ] Error in 3.0.0b1 loading extendes GL functions

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

Bugs item #1863687, was opened at 2008-01-03 19:46
Message generated for change (Comment added) made by markus_wankus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1863687&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: Error in 3.0.0b1 loading extendes GL functions

Initial Comment:
There is an Error in the baseplatform.py under Windows.
functionTypeFor cannot be found in the load method of _NullFunctionPointer class.

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

Comment By: Markus Wankus (markus_wankus)
Date: 2008-01-05 17:03

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

More specifically, the error is:

  File
"c:\python25\lib\site-packages\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\platform\baseplatform.py",
line 234, in load
    func = functionTypeFor( self.DLL )(
NameError: global name 'functionTypeFor' is not defined


This can be fixed by changing the line in question from:

func = functionTypeFor( self.DLL )(

to:

func = platform.PLATFORM.functionTypeFor( self.DLL )(

Mark.

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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1864674 ] PyOpenGL fails to pickle GL constants on Windows

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

Bugs item #1864674, was opened at 2008-01-05 12:03
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=1864674&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: PyOpenGL fails to pickle GL constants on Windows

Initial Comment:
On a Windows XP machine using Python2.5 and PyOpenGL-3.0.0a7, an attempt to cPickle a
GL constant fails on loading it back in.

Here's the error produced:

Traceback (most recent call last):
  File "tp.py", line 11, in <module>
    print cPickle.load(f)
TypeError: __new__() takes exactly 3 arguments (2 given)


Here's the tiny example that produced that error:

import cPickle
from OpenGL.GL import GL_DECAL

print type(GL_DECAL), int(GL_DECAL)

f = open('dumpfile','wb')
cPickle.dump(GL_DECAL,f,2)
f.close()

f = open('dumpfile','rb')
print cPickle.load(f)
f.close()

Gary Herron
gh...@di...

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

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

Re: [PyOpenGL-Devel] Problem with numpy and OpenGL textures

[Adeola B. <the...@gm...>]

Thanks Andrew... pyglet looks like it might simplify a lot, but I'll
try it out first and see.

On Jan 3, 2008 5:30 PM, Andrew Straw <str...@as...> wrote:
> Hi Adeola,
>
> I am doing the same thing using pyglet to handle all the texture
> manipulation. Perhaps you are interested:
>
> http://code.astraw.com/projects/motmot/wiki/wxglvideo
>
>
> Adeola Bannis wrote:
> > Hi everyone,
> >
> > I'm doing a project using wxPython and pyopengl, and I seem to have a
> > problem rendering textures. This is code that worked before my hard
> > drive had a meltdown, but not since I re-installed everything.
> >
> > I've determined the problem is in the OpenGL part of my program. I do
> > some calculations to generate a 2D numpy array that holds the image
> > data, and pylab.imshow() shows me the image as it is meant to be. I
> > used the same algorithm in Octave and MATLAB, and all are giving me
> > the right picture.
> >
> > However, using pyOpenGL and the numpyhandler functions (http://cours-
> > info.iut-bm.univ-fcomte.fr/docs/python/OpenGL/
> > OpenGL.arrays.numpymodule.NumpyHandler-class.html) doesn't seem to
> > work. I get a garbled screen pocked with black pixels. I am including
> > my openGL code below. What am I doing wrong?
> >
> > And yes, I did make the dtype of my array 'float32'.
> >
> > -------code snippets------
> >
> > import wx
> > from wx.glcanvas import GLCanvas
> >
> > from OpenGL.GLU import *
> > from OpenGL.GL import *
> > from OpenGL.arrays.numpymodule import NumpyHandler
> >
> > PC = 1
> > RI = 0
> >
> > class myGLCanvas(GLCanvas):
> >         def __init__(self, parent):
> >                 GLCanvas.__init__(self, parent,-1)
> >                 wx.EVT_PAINT(self, self.OnPaint)
> >                 self.init = 0
> >                 self.mode = -1
> >                 # making a texture for the range image
> >                 self.texture = glGenTextures(1)
> >                 # making a spot for the point cloud points
> >                 self.cloud = None
> >                 return
> >
> >         def OnPaint(self,event):
> >                 dc = wx.PaintDC(self)
> >                 self.SetCurrent()
> >                 if not self.init:
> >                         self.InitGL()
> >                         self.init = 1
> >                 self.OnDraw()
> >                 return
> >
> >         def OnDraw(self):
> >                 glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
> >                 if self.mode == RI:
> >                         self.drawRange()
> >                 elif self.mode == PC:
> >                         self.drawCloud()
> >
> >         def InitGL(self):
> >                 glClearColor(0.0, 0.0, 0.0, 0.0);
> >                 glClearDepth(1.0)
> >                 glEnable(GL_DEPTH_TEST)
> >                 glDepthFunc(GL_LEQUAL)
> >                 glClear(GL_COLOR_BUFFER_BIT)
> >
> >                 glPixelStorei(GL_UNPACK_ALIGNMENT, 1)
> >                 glPixelStorei(GL_PACK_ALIGNMENT, 1)
> >
> >                 #NTSC colour scales...
> >                 glPixelTransferf(GL_RED_SCALE, 0.299);
> >                 glPixelTransferf(GL_GREEN_SCALE, 0.587);
> >                 glPixelTransferf(GL_BLUE_SCALE, 0.114);
> >
> >                 glMatrixMode(GL_PROJECTION)
> >                 glLoadIdentity()
> >                 glOrtho(0.0,1.0,0,1.0,-1.0,1.0)
> >                 glMatrixMode(GL_MODELVIEW)
> >                 glLoadIdentity()
> >
> >                 return
> >
> >         def rangeImage(self, image):
> >
> >                 glBindTexture(GL_TEXTURE_2D, self.texture)
> >                 glTexEnvf( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE )
> >
> >                 glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
> >                                                 GL_LINEAR)
> >                 glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER,
> > GL_LINEAR)
> >                 glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT)
> >                 glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT)
> >
> >                 # flatten it into a list so the OpenGL calls work
> >                 n = NumpyHandler()
> >                 fI = image.flatten()
> >                 flatImage = n.dataPointer(n.contiguous(fI))
> >
> >                 print n.contiguous(fI)
> >
> >                 gluBuild2DMipmaps(GL_TEXTURE_2D, 1, image.shape[0]+1,
> > image.shape[1]+1,
> >                                                         GL_LUMINANCE,
> > GL_FLOAT, flatImage)
> >                 self.mode = RI
> >                 self.OnDraw()
> >
> >         def drawRange(self):
> >                 ''' Controls the actual drawing of the range image'''
> >
> >                 glMatrixMode(GL_MODELVIEW)
> >                 glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
> >
> >                 glColor3f(1.0,1.0,1.0)
> >                 glEnable(GL_TEXTURE_2D)
> >                 glBindTexture(GL_TEXTURE_2D, self.texture)
> >                 glBegin(GL_TRIANGLE_FAN)
> >                 glTexCoord2d(1,1); glVertex3f(0.0, 0.0, 0.0)
> >                 glTexCoord2d(1,0); glVertex3f(0.0, 1.0, 0.0)
> >                 glTexCoord2d(0,0); glVertex3f(1.0, 1.0, 0.0)
> >                 glTexCoord2d(0,1); glVertex3f(1.0, 0.0, 0.0)
> >                 glEnd()
> >                 self.SwapBuffers()
> >
> > --------end snippet-----------
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > PyOpenGL Homepage
> > http://pyopengl.sourceforge.net
> > _______________________________________________
> > PyOpenGL-Devel mailing list
> > PyO...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
>
>

[PyOpenGL-Devel] [ pyopengl-Bugs-1863687 ] Error in 3.0.0b1 loading extendes GL functions

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

Bugs item #1863687, was opened at 2008-01-03 16:46
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=1863687&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: Error in 3.0.0b1 loading extendes GL functions

Initial Comment:
There is an Error in the baseplatform.py under Windows.
functionTypeFor cannot be found in the load method of _NullFunctionPointer class.

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

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

Re: [PyOpenGL-Devel] Problem with numpy and OpenGL textures

[Andrew S. <str...@as...>]

Hi Adeola,

I am doing the same thing using pyglet to handle all the texture
manipulation. Perhaps you are interested:

http://code.astraw.com/projects/motmot/wiki/wxglvideo

Adeola Bannis wrote:
> Hi everyone,
> 
> I'm doing a project using wxPython and pyopengl, and I seem to have a
> problem rendering textures. This is code that worked before my hard
> drive had a meltdown, but not since I re-installed everything.
> 
> I've determined the problem is in the OpenGL part of my program. I do
> some calculations to generate a 2D numpy array that holds the image
> data, and pylab.imshow() shows me the image as it is meant to be. I
> used the same algorithm in Octave and MATLAB, and all are giving me
> the right picture.
> 
> However, using pyOpenGL and the numpyhandler functions (http://cours-
> info.iut-bm.univ-fcomte.fr/docs/python/OpenGL/
> OpenGL.arrays.numpymodule.NumpyHandler-class.html) doesn't seem to
> work. I get a garbled screen pocked with black pixels. I am including
> my openGL code below. What am I doing wrong?
> 
> And yes, I did make the dtype of my array 'float32'.
> 
> -------code snippets------
> 
> import wx
> from wx.glcanvas import GLCanvas
> 
> from OpenGL.GLU import *
> from OpenGL.GL import *
> from OpenGL.arrays.numpymodule import NumpyHandler
> 
> PC = 1
> RI = 0
> 
> class myGLCanvas(GLCanvas):
>         def __init__(self, parent):
>                 GLCanvas.__init__(self, parent,-1)
>                 wx.EVT_PAINT(self, self.OnPaint)
>                 self.init = 0
>                 self.mode = -1
>                 # making a texture for the range image
>                 self.texture = glGenTextures(1)
>                 # making a spot for the point cloud points
>                 self.cloud = None
>                 return
> 
>         def OnPaint(self,event):
>                 dc = wx.PaintDC(self)
>                 self.SetCurrent()
>                 if not self.init:
>                         self.InitGL()
>                         self.init = 1
>                 self.OnDraw()
>                 return
> 
>         def OnDraw(self):
>                 glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
>                 if self.mode == RI:
>                         self.drawRange()
>                 elif self.mode == PC:
>                         self.drawCloud()
> 
>         def InitGL(self):
>                 glClearColor(0.0, 0.0, 0.0, 0.0);
>                 glClearDepth(1.0)
>                 glEnable(GL_DEPTH_TEST)
>                 glDepthFunc(GL_LEQUAL)
>                 glClear(GL_COLOR_BUFFER_BIT)
> 
>                 glPixelStorei(GL_UNPACK_ALIGNMENT, 1)
>                 glPixelStorei(GL_PACK_ALIGNMENT, 1)
> 
>                 #NTSC colour scales...
>                 glPixelTransferf(GL_RED_SCALE, 0.299);
>                 glPixelTransferf(GL_GREEN_SCALE, 0.587);
>                 glPixelTransferf(GL_BLUE_SCALE, 0.114);
> 
>                 glMatrixMode(GL_PROJECTION)
>                 glLoadIdentity()
>                 glOrtho(0.0,1.0,0,1.0,-1.0,1.0)
>                 glMatrixMode(GL_MODELVIEW)
>                 glLoadIdentity()
> 
>                 return
> 
>         def rangeImage(self, image):
> 
>                 glBindTexture(GL_TEXTURE_2D, self.texture)
>                 glTexEnvf( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE )
> 
>                 glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
>                                                 GL_LINEAR)
>                 glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER,
> GL_LINEAR)
>                 glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT)
>                 glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT)
> 
>                 # flatten it into a list so the OpenGL calls work
>                 n = NumpyHandler()
>                 fI = image.flatten()
>                 flatImage = n.dataPointer(n.contiguous(fI))
> 
>                 print n.contiguous(fI)
> 
>                 gluBuild2DMipmaps(GL_TEXTURE_2D, 1, image.shape[0]+1,
> image.shape[1]+1,
>                                                         GL_LUMINANCE,
> GL_FLOAT, flatImage)
>                 self.mode = RI
>                 self.OnDraw()
> 
>         def drawRange(self):
>                 ''' Controls the actual drawing of the range image'''
> 
>                 glMatrixMode(GL_MODELVIEW)
>                 glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
> 
>                 glColor3f(1.0,1.0,1.0)
>                 glEnable(GL_TEXTURE_2D)
>                 glBindTexture(GL_TEXTURE_2D, self.texture)
>                 glBegin(GL_TRIANGLE_FAN)
>                 glTexCoord2d(1,1); glVertex3f(0.0, 0.0, 0.0)
>                 glTexCoord2d(1,0); glVertex3f(0.0, 1.0, 0.0)
>                 glTexCoord2d(0,0); glVertex3f(1.0, 1.0, 0.0)
>                 glTexCoord2d(0,1); glVertex3f(1.0, 0.0, 0.0)
>                 glEnd()
>                 self.SwapBuffers()
> 
> --------end snippet-----------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Devel mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-devel

[PyOpenGL-Devel] Problem with numpy and OpenGL textures

[Adeola B. <the...@gm...>]

Hi everyone,

I'm doing a project using wxPython and pyopengl, and I seem to have a
problem rendering textures. This is code that worked before my hard
drive had a meltdown, but not since I re-installed everything.

I've determined the problem is in the OpenGL part of my program. I do
some calculations to generate a 2D numpy array that holds the image
data, and pylab.imshow() shows me the image as it is meant to be. I
used the same algorithm in Octave and MATLAB, and all are giving me
the right picture.

However, using pyOpenGL and the numpyhandler functions (http://cours-
info.iut-bm.univ-fcomte.fr/docs/python/OpenGL/
OpenGL.arrays.numpymodule.NumpyHandler-class.html) doesn't seem to
work. I get a garbled screen pocked with black pixels. I am including
my openGL code below. What am I doing wrong?

And yes, I did make the dtype of my array 'float32'.

-------code snippets------

import wx
from wx.glcanvas import GLCanvas

from OpenGL.GLU import *
from OpenGL.GL import *
from OpenGL.arrays.numpymodule import NumpyHandler

PC = 1
RI = 0

class myGLCanvas(GLCanvas):
        def __init__(self, parent):
                GLCanvas.__init__(self, parent,-1)
                wx.EVT_PAINT(self, self.OnPaint)
                self.init = 0
                self.mode = -1
                # making a texture for the range image
                self.texture = glGenTextures(1)
                # making a spot for the point cloud points
                self.cloud = None
                return

        def OnPaint(self,event):
                dc = wx.PaintDC(self)
                self.SetCurrent()
                if not self.init:
                        self.InitGL()
                        self.init = 1
                self.OnDraw()
                return

        def OnDraw(self):
                glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
                if self.mode == RI:
                        self.drawRange()
                elif self.mode == PC:
                        self.drawCloud()

        def InitGL(self):
                glClearColor(0.0, 0.0, 0.0, 0.0);
                glClearDepth(1.0)
                glEnable(GL_DEPTH_TEST)
                glDepthFunc(GL_LEQUAL)
                glClear(GL_COLOR_BUFFER_BIT)

                glPixelStorei(GL_UNPACK_ALIGNMENT, 1)
                glPixelStorei(GL_PACK_ALIGNMENT, 1)

                #NTSC colour scales...
                glPixelTransferf(GL_RED_SCALE, 0.299);
                glPixelTransferf(GL_GREEN_SCALE, 0.587);
                glPixelTransferf(GL_BLUE_SCALE, 0.114);

                glMatrixMode(GL_PROJECTION)
                glLoadIdentity()
                glOrtho(0.0,1.0,0,1.0,-1.0,1.0)
                glMatrixMode(GL_MODELVIEW)
                glLoadIdentity()

                return

        def rangeImage(self, image):

                glBindTexture(GL_TEXTURE_2D, self.texture)
                glTexEnvf( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE )

                glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
                                                GL_LINEAR)
                glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER,
GL_LINEAR)
                glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT)
                glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT)

                # flatten it into a list so the OpenGL calls work
                n = NumpyHandler()
                fI = image.flatten()
                flatImage = n.dataPointer(n.contiguous(fI))

                print n.contiguous(fI)

                gluBuild2DMipmaps(GL_TEXTURE_2D, 1, image.shape[0]+1,
image.shape[1]+1,
                                                        GL_LUMINANCE,
GL_FLOAT, flatImage)
                self.mode = RI
                self.OnDraw()

        def drawRange(self):
                ''' Controls the actual drawing of the range image'''

                glMatrixMode(GL_MODELVIEW)
                glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)

                glColor3f(1.0,1.0,1.0)
                glEnable(GL_TEXTURE_2D)
                glBindTexture(GL_TEXTURE_2D, self.texture)
                glBegin(GL_TRIANGLE_FAN)
                glTexCoord2d(1,1); glVertex3f(0.0, 0.0, 0.0)
                glTexCoord2d(1,0); glVertex3f(0.0, 1.0, 0.0)
                glTexCoord2d(0,0); glVertex3f(1.0, 1.0, 0.0)
                glTexCoord2d(0,1); glVertex3f(1.0, 0.0, 0.0)
                glEnd()
                self.SwapBuffers()

--------end snippet-----------

[PyOpenGL-Devel] [ pyopengl-Bugs-1859019 ] unable to import GLUT

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

Bugs item #1859019, was opened at 2007-12-27 09:47
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=1859019&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: unable to import GLUT

Initial Comment:
I get the following error upon a command:


>>> from OpenGL.GLUT import *

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    from OpenGL.GLUT import *
  File "build\bdist.win32\egg\OpenGL\GLUT\__init__.py", line 4, in <module>
  File "build\bdist.win32\egg\OpenGL\GLUT\special.py", line 73, in <module>
AttributeError: 'NoneType' object has no attribute 'glutDestroyWindow'




Please help me to get GLUT to work

sha...@ya...


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

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

[PyOpenGL-Devel] [ pyopengl-Bugs-1854632 ] gluTessVertex function take wrong data

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

Bugs item #1854632, was opened at 2007-12-19 21:07
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=1854632&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: GLU
Group: v3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: gluTessVertex function take wrong data

Initial Comment:
Windows XP 32bit, Python2.5.1
When running tests.py in PyOpenGL3.0.0b1 from cvs, I got the flowing output:
.........error 12590456
E.
======================================================================
ERROR: Test that tessellation works
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\tests.py", line 225, in test_tess
    gluTessEndPolygon(tobj);
WindowsError: exception code 0xc01d78

----------------------------------------------------------------------
Ran 11 tests in 3.469s

FAILED (errors=1)

I'm sure that it's caused by a bug in gluTessVertex function.

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

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