pyopengl-devel Mailing List for PyOpenGL (Page 9)
Brought to you by:
mcfletch
Menu
▾
▴
pyopengl-devel — Discussion of PyOpenGL development.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(4) |
Nov
(9) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
(6) |
Mar
(3) |
Apr
(5) |
May
(10) |
Jun
(6) |
Jul
(10) |
Aug
|
Sep
(3) |
Oct
(9) |
Nov
(20) |
Dec
(31) |
| 2003 |
Jan
(36) |
Feb
(44) |
Mar
(16) |
Apr
(35) |
May
(59) |
Jun
(17) |
Jul
(11) |
Aug
(14) |
Sep
(9) |
Oct
(29) |
Nov
(10) |
Dec
(5) |
| 2004 |
Jan
(17) |
Feb
(8) |
Mar
(6) |
Apr
(3) |
May
(4) |
Jun
(2) |
Jul
(42) |
Aug
(7) |
Sep
(17) |
Oct
(32) |
Nov
(7) |
Dec
(5) |
| 2005 |
Jan
(11) |
Feb
(11) |
Mar
(7) |
Apr
(8) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(2) |
Nov
(5) |
Dec
(1) |
| 2006 |
Jan
(1) |
Feb
(2) |
Mar
(5) |
Apr
(6) |
May
(9) |
Jun
(6) |
Jul
(7) |
Aug
(8) |
Sep
(8) |
Oct
(23) |
Nov
(29) |
Dec
(5) |
| 2007 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
(10) |
May
(7) |
Jun
(12) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(5) |
Nov
(6) |
Dec
(3) |
| 2008 |
Jan
(38) |
Feb
(10) |
Mar
(3) |
Apr
(13) |
May
(8) |
Jun
(12) |
Jul
(6) |
Aug
(3) |
Sep
(2) |
Oct
(7) |
Nov
(21) |
Dec
(1) |
| 2009 |
Jan
(7) |
Feb
(8) |
Mar
(4) |
Apr
(6) |
May
(4) |
Jun
(4) |
Jul
(38) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(16) |
Dec
|
| 2010 |
Jan
(4) |
Feb
(17) |
Mar
(2) |
Apr
(6) |
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(10) |
Nov
(3) |
Dec
(8) |
| 2011 |
Jan
|
Feb
(2) |
Mar
|
Apr
(6) |
May
(3) |
Jun
(19) |
Jul
(6) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
(6) |
Dec
(6) |
| 2012 |
Jan
(8) |
Feb
(3) |
Mar
(26) |
Apr
(12) |
May
(2) |
Jun
(8) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(10) |
Nov
(5) |
Dec
(1) |
| 2013 |
Jan
(2) |
Feb
(5) |
Mar
(1) |
Apr
(3) |
May
(6) |
Jun
|
Jul
(7) |
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(4) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2010-06-22 13:51:13
|
Patches item #3019625, was opened at 2010-06-22 15:51 Message generated for change (Tracker Item Submitted) made by lmancini You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=3019625&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: build Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lorenzo Mancini (lmancini) Assigned to: Nobody/Anonymous (nobody) Summary: Only install files from directory OpenGL/DLLS Initial Comment: PyOpenGL's setup.py manages binary versions of GLUT and GLE for win32 by os.listdir'ing the contents of directory OpenGL/DLLS. However, the relevant code should only manage files, rather than subdirectories too. This is useful in case pyopengl is built, for example, from a Subversion working copy, which stores repository metadata in the hidden ".svn" directory - in this case, the build process will fail later under Windows when trying to copy the ".svn" hidden directory. The patch is attached. I have this in production in my build system and it seems to work well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=3019625&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-05-11 14:41:15
|
Bugs item #2987754, was opened at 2010-04-15 16:38 Message generated for change (Comment added) made by cfrb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2987754&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: Open Resolution: None Priority: 5 Private: No Submitted By: Mary Ellen Foster () Assigned to: Mike C. Fletcher (mcfletch) Summary: glGetIntegerv(GL_SMOOTH_LINE_WIDTH_RANGE) result changed Initial Comment: In some code that I work with, we call glGetIntegerv(GL_SMOOTH_LINE_WIDTH_RANGE). This used to return an array, so we would later do essentially lineWidth[1] to get the max width and use that. With PyOpenGL on Windows, that seems now to return a single integer -- at least, when we try to index it, we get an error like this: IndexError: invalid index to scalar variable. Is this expected? Where can we get the old value? The single value that's returned now seems to be only the low end of the range ... ---------------------------------------------------------------------- Comment By: Christopher Frauenberger (cfrb) Date: 2010-05-11 15:41 Message: in the latest version 3.0.1 for windows, both calls for GL_LINE_WIDTH_RANGE and GL_SMOOTH_LINE_WIDTH_RANGE are broken and return a single integer. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-04-16 04:37 Message: It was definitely a bug. I've fixed the dimension declarations in bzr head and the result should show up in the next release (3.0.2). ---------------------------------------------------------------------- Comment By: Mary Ellen Foster () Date: 2010-04-15 16:50 Message: Note that changing to use GL_LINE_WIDTH_RANGE (which should in theory be an alias) seems to work on both 3.0.0 and 3.0.1. I suspect there's a bug in glget.py where GL_SMOOTH_LINE_WIDTH_RANGE is defined to have dimensions (1,) ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2987754&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-04-22 04:54:06
|
Patches item #2990717, was opened at 2010-04-22 04:54 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=2990717&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: glGenProgramsARB pythoned Initial Comment: Just a simple patch to make glGenProgramsARB more python-like. Just insert: glGenProgramsARB = wrapper.wrapper( glGenProgramsARB ).setOutput( 'programs', lambda n: (n,), 'n', ) on OpenGL/GL/ARB/vertex_program.py and thats it. I copied the pattern of glGenBuffers. Author: Ricardo Lenz (riclc -+at+- hotmail). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=2990717&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-04-16 03:37:37
|
Bugs item #2987754, was opened at 2010-04-15 11:38 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2987754&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: Open Resolution: None Priority: 5 Private: No Submitted By: Mary Ellen Foster () Assigned to: Mike C. Fletcher (mcfletch) Summary: glGetIntegerv(GL_SMOOTH_LINE_WIDTH_RANGE) result changed Initial Comment: In some code that I work with, we call glGetIntegerv(GL_SMOOTH_LINE_WIDTH_RANGE). This used to return an array, so we would later do essentially lineWidth[1] to get the max width and use that. With PyOpenGL on Windows, that seems now to return a single integer -- at least, when we try to index it, we get an error like this: IndexError: invalid index to scalar variable. Is this expected? Where can we get the old value? The single value that's returned now seems to be only the low end of the range ... ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-04-15 23:37 Message: It was definitely a bug. I've fixed the dimension declarations in bzr head and the result should show up in the next release (3.0.2). ---------------------------------------------------------------------- Comment By: Mary Ellen Foster () Date: 2010-04-15 11:50 Message: Note that changing to use GL_LINE_WIDTH_RANGE (which should in theory be an alias) seems to work on both 3.0.0 and 3.0.1. I suspect there's a bug in glget.py where GL_SMOOTH_LINE_WIDTH_RANGE is defined to have dimensions (1,) ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2987754&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-04-15 15:50:36
|
Bugs item #2987754, was opened at 2010-04-15 15:38 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2987754&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: Open Resolution: None Priority: 5 Private: No Submitted By: Mary Ellen Foster () Assigned to: Mike C. Fletcher (mcfletch) Summary: glGetIntegerv(GL_SMOOTH_LINE_WIDTH_RANGE) result changed Initial Comment: In some code that I work with, we call glGetIntegerv(GL_SMOOTH_LINE_WIDTH_RANGE). This used to return an array, so we would later do essentially lineWidth[1] to get the max width and use that. With PyOpenGL on Windows, that seems now to return a single integer -- at least, when we try to index it, we get an error like this: IndexError: invalid index to scalar variable. Is this expected? Where can we get the old value? The single value that's returned now seems to be only the low end of the range ... ---------------------------------------------------------------------- >Comment By: Mary Ellen Foster () Date: 2010-04-15 15:50 Message: Note that changing to use GL_LINE_WIDTH_RANGE (which should in theory be an alias) seems to work on both 3.0.0 and 3.0.1. I suspect there's a bug in glget.py where GL_SMOOTH_LINE_WIDTH_RANGE is defined to have dimensions (1,) ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2987754&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-04-15 15:38:52
|
Bugs item #2987754, was opened at 2010-04-15 15:38 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2987754&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: Open Resolution: None Priority: 5 Private: No Submitted By: Mary Ellen Foster () Assigned to: Mike C. Fletcher (mcfletch) Summary: glGetIntegerv(GL_SMOOTH_LINE_WIDTH_RANGE) result changed Initial Comment: In some code that I work with, we call glGetIntegerv(GL_SMOOTH_LINE_WIDTH_RANGE). This used to return an array, so we would later do essentially lineWidth[1] to get the max width and use that. With PyOpenGL on Windows, that seems now to return a single integer -- at least, when we try to index it, we get an error like this: IndexError: invalid index to scalar variable. Is this expected? Where can we get the old value? The single value that's returned now seems to be only the low end of the range ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2987754&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-04-04 03:19:42
|
Bugs item #2980896, was opened at 2010-04-01 21:51 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2980896&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: Mike C. Fletcher (mcfletch) Summary: Creating ~8000 VBOs crashes python with PyOpenGL-accelerate Initial Comment: Allocating ~8000 VBOs causes python to exit with the message "Fatal Python error: deallocating None" when PyOpenGL-accelerate is installed. It's easy to hit this limit with rapidly changing content, e.g. incoming experimental data. Uninstalling PyOpenGL-accelerate avoids this crash, and the code seems to work fine in that case. This is a reasonable workaround for the moment, but it would be nice to be able to use PyOpenGL-accelerate in the long term. System: Ubuntu 9.10, AMD_64, PyOpenGL 3.0.1b1, Intel X3100 graphics Here's a minimal reproduction case: from OpenGL.arrays import vbo import numpy as np data = np.arange(1000).astype(np.float32) for i in range(1000000): new_vbo = vbo.VBO(data) # optional: new_vbo.delete ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-04-03 23:19 Message: Thanks for the bug report, the test code was perfect for finding the bug. The code had assumed that setting a data-pointer to None meant that it would be a NULL pointer, in fact it merely points the pointer at Py_NONE. bzr head of OpenGL_accelerate has the fix and it will be released with the next PyOpenGL release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2980896&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-04-02 01:51:00
|
Bugs item #2980896, was opened at 2010-04-02 01:51 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2980896&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: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike C. Fletcher (mcfletch) Summary: Creating ~8000 VBOs crashes python with PyOpenGL-accelerate Initial Comment: Allocating ~8000 VBOs causes python to exit with the message "Fatal Python error: deallocating None" when PyOpenGL-accelerate is installed. It's easy to hit this limit with rapidly changing content, e.g. incoming experimental data. Uninstalling PyOpenGL-accelerate avoids this crash, and the code seems to work fine in that case. This is a reasonable workaround for the moment, but it would be nice to be able to use PyOpenGL-accelerate in the long term. System: Ubuntu 9.10, AMD_64, PyOpenGL 3.0.1b1, Intel X3100 graphics Here's a minimal reproduction case: from OpenGL.arrays import vbo import numpy as np data = np.arange(1000).astype(np.float32) for i in range(1000000): new_vbo = vbo.VBO(data) # optional: new_vbo.delete ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2980896&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-03-22 23:54:19
|
Bugs item #2943244, was opened at 2010-01-31 07:16 Message generated for change (Comment added) made by aschoeke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2943244&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: 3 Private: No Submitted By: jfpacker (jfpacker) Assigned to: Mike C. Fletcher (mcfletch) Summary: PyOpenGL-accelerate and numpy 1.4 numpy_formathandler error Initial Comment: importing OpenGL.GL gives the error: "ValueError: numpy.dtype does not appear to be the correct type object". To reproduce this bug, install python 2.6 (my minor version 4, ie: 2.6.4), PyOpenGL 3.0.1b2-py26-win32 and PyOpenGL-accelerate-3.0.1b2-py26-win32 and numpy 1.4. In the interpreter type: import OpenGL from OpenGL import GL This gives the output: File "C:\Python26\lib\site-packages\GLavish\library\locals.py", line 7, in <mo dule> from OpenGL import GL File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\GL \__init__.py", line 2, in <module> from OpenGL.raw.GL import * File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ra w\GL\__init__.py", line 6, in <module> from OpenGL.raw.GL.constants import * File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ra w\GL\constants.py", line 7, in <module> from OpenGL import platform, arrays File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar rays\__init__.py", line 22, in <module> formathandler.FormatHandler.loadAll() File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar rays\formathandler.py", line 37, in loadAll cls.loadPlugin( entrypoint ) File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar rays\formathandler.py", line 44, in loadPlugin plugin_class = entrypoint.load() File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\pl ugins.py", line 14, in load return importByName( self.import_path ) File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\pl ugins.py", line 28, in importByName module = __import__( ".".join(moduleName), {}, {}, moduleName) File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar rays\numpymodule.py", line 25, in <module> from OpenGL_accelerate.numpy_formathandler import NumpyHandler File "c:\users\jeff\appdata\local\temp\easy_install-uwdslx\PyOpenGL_accelerate -3.0.1b2-py2.6-win32.egg.tmp\OpenGL_accelerate\numpy_formathandler.py", line 7, in <module> File "c:\users\jeff\appdata\local\temp\easy_install-uwdslx\PyOpenGL_accelerate -3.0.1b2-py2.6-win32.egg.tmp\OpenGL_accelerate\numpy_formathandler.py", line 6, in __bootstrap__ File "numpy.pxd", line 30, in OpenGL_accelerate.numpy_formathandler (src\numpy _formathandler.c:3543) ValueError: numpy.dtype does not appear to be the correct type object ---------------------------------------------------------------------- Comment By: Andrej Schoeke (aschoeke) Date: 2010-03-22 16:54 Message: Same problem on Mac OS X 10.5 with MacPorts. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 12:29 Message: Hrm. Sounds like we have a problem with the numpy version changes. Argh. Seems we need to be patching setuptools to allow for checking against the numpy version. I'd hoped we'd seen the back of patching setup scripts. I'll attempt to fix it when I'm on Win32 again. ---------------------------------------------------------------------- Comment By: jfpacker (jfpacker) Date: 2010-01-31 07:23 Message: This only occurs if you easy_install PyOpenGL-accelerate as it downloads the pre-built version win32 version. I downloaded the source and installed from source and it works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2943244&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-03-08 23:08:43
|
Bugs item #2965754, was opened at 2010-03-09 00:08 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2965754&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: Open Resolution: None Priority: 5 Private: No Submitted By: Miguel Perez () Assigned to: Nobody/Anonymous (nobody) Summary: Loading textures from another thread causes segfault Initial Comment: Whenever I try to load or unload textures from a different thread than the main one, I get a segmentation fault in an PyOpenGL call, even if PyOpenGL calls are properly protected by locking. Loading and unloading textures from a different thread is necessary for my project, a high-performance image viewer. I'm using PyOpenGL 3.0.1~b2-1 with PyGame 1.8.1release-1.1+b1 from Debian Sid with an nVidia graphics card with the official driver (190.53) on GNU/Linux 2.6.31. I've also verified the problem with PyOpenGL and PyGame in Ubuntu GNU/Linux 8.04 Hardy with the official stable packages using an ATi embedded graphics card with the free software ati driver. I've crafted a program to demonstrate it, which I'm attaching to this bug in tar+gzip format. Upon uncompressing the file you'll get a directory; inside it you'll find a Python program and a PNG image it'll load. First it'll load and move it around for 4 seconds in the main thread, which you'll see working fine. Then it'll do exactly the same, only the image is loaded in a second thread and shared with the first one. Before the first thread resumes control, however, it'll crash, right in glGenTextures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2965754&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-25 18:42:33
|
Bugs item #2817196, was opened at 2009-07-05 23:46 Message generated for change (Comment added) made by astraw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2817196&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: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Straw (astraw) Assigned to: Nobody/Anonymous (nobody) Summary: regression: multitexturing broken in 3.0.0 Initial Comment: I've been trying to track down a regression in multitexturing that happens on Windows with PyOpenGL3. I get the same issue with Python2.5 and Python2.6, and it goes away when I test on Python2.5 with PyOpenGL 2.0.2.01. I don't get this error on Linux. Running the old NeHe demo "lesson6-multi.py" I found in a local copy of PyOpenGL-2.0.1.09 (in PyOpenGL-2.0.1.09/OpenGL/Demo/NeHe/), I get this traceback: Z:\test>c:\python25\python lesson6-multi.py Hit ESC key to quit. Traceback (most recent call last): File "c:\python25\lib\site-packages\OpenGL\GLUT\special.py", line 113, in safe Call return function( *args, **named ) File "lesson6-multi.py", line 189, in DrawGLScene glEnd(); # Done Drawing The Cube File "c:\python25\lib\site-packages\OpenGL\lazywrapper.py", line 9, in __call_ _ return wrapper( baseFunction, *args, **named ) File "c:\python25\lib\site-packages\OpenGL\GL\exceptional.py", line 57, in glE nd return baseFunction( ) File "c:\python25\lib\site-packages\OpenGL\error.py", line 194, in glCheckErro r baseOperation = baseOperation, GLError: GLError( err = 1282, description = 'invalid operation', baseOperation = glEnd, cArguments = () ) GLUT Idle callback <function DrawGLScene at 0x00D47830> with (),{} failed: retur ning None GLError( err = 1282, description = 'invalid operation', baseOperation = glEnd, cArguments = () ) ---------------------------------------------------------------------- >Comment By: Andrew Straw (astraw) Date: 2010-02-25 18:42 Message: Thanks for looking into this. I tried, but I got lost in the code. This is important for the current and past incarnations of the Vision Egg library, which is useful for vision research experiments. In the future, the VE will move to shaders, but multi-texturing worked fine for years until PyOpenGL 3. I am happy to test. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-25 18:04 Message: Urgh, *Windows*, sorry. Guess I need to get over to windows to test this. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-25 18:03 Message: Have just tested with the Demo/NeHe/lesson6-multi.py from PyOpenGL 2.0.1.09 with PyOpenGL 3.0.1 (about to be released). Works as expected. We also have a PyOpenGL-Demo package which includes the updated version of the demo, which works fine. We have lots of other scripts that use multi-texturing, both with the legacy and shader APIs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2817196&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-25 18:04:44
|
Bugs item #2817196, was opened at 2009-07-05 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=2817196&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: Open >Resolution: None Priority: 5 Private: No Submitted By: Andrew Straw (astraw) Assigned to: Nobody/Anonymous (nobody) Summary: regression: multitexturing broken in 3.0.0 Initial Comment: I've been trying to track down a regression in multitexturing that happens on Windows with PyOpenGL3. I get the same issue with Python2.5 and Python2.6, and it goes away when I test on Python2.5 with PyOpenGL 2.0.2.01. I don't get this error on Linux. Running the old NeHe demo "lesson6-multi.py" I found in a local copy of PyOpenGL-2.0.1.09 (in PyOpenGL-2.0.1.09/OpenGL/Demo/NeHe/), I get this traceback: Z:\test>c:\python25\python lesson6-multi.py Hit ESC key to quit. Traceback (most recent call last): File "c:\python25\lib\site-packages\OpenGL\GLUT\special.py", line 113, in safe Call return function( *args, **named ) File "lesson6-multi.py", line 189, in DrawGLScene glEnd(); # Done Drawing The Cube File "c:\python25\lib\site-packages\OpenGL\lazywrapper.py", line 9, in __call_ _ return wrapper( baseFunction, *args, **named ) File "c:\python25\lib\site-packages\OpenGL\GL\exceptional.py", line 57, in glE nd return baseFunction( ) File "c:\python25\lib\site-packages\OpenGL\error.py", line 194, in glCheckErro r baseOperation = baseOperation, GLError: GLError( err = 1282, description = 'invalid operation', baseOperation = glEnd, cArguments = () ) GLUT Idle callback <function DrawGLScene at 0x00D47830> with (),{} failed: retur ning None GLError( err = 1282, description = 'invalid operation', baseOperation = glEnd, cArguments = () ) ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-25 13:04 Message: Urgh, *Windows*, sorry. Guess I need to get over to windows to test this. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-25 13:03 Message: Have just tested with the Demo/NeHe/lesson6-multi.py from PyOpenGL 2.0.1.09 with PyOpenGL 3.0.1 (about to be released). Works as expected. We also have a PyOpenGL-Demo package which includes the updated version of the demo, which works fine. We have lots of other scripts that use multi-texturing, both with the legacy and shader APIs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2817196&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-25 18:03:37
|
Bugs item #2817196, was opened at 2009-07-05 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=2817196&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: Works For Me Priority: 5 Private: No Submitted By: Andrew Straw (astraw) Assigned to: Nobody/Anonymous (nobody) Summary: regression: multitexturing broken in 3.0.0 Initial Comment: I've been trying to track down a regression in multitexturing that happens on Windows with PyOpenGL3. I get the same issue with Python2.5 and Python2.6, and it goes away when I test on Python2.5 with PyOpenGL 2.0.2.01. I don't get this error on Linux. Running the old NeHe demo "lesson6-multi.py" I found in a local copy of PyOpenGL-2.0.1.09 (in PyOpenGL-2.0.1.09/OpenGL/Demo/NeHe/), I get this traceback: Z:\test>c:\python25\python lesson6-multi.py Hit ESC key to quit. Traceback (most recent call last): File "c:\python25\lib\site-packages\OpenGL\GLUT\special.py", line 113, in safe Call return function( *args, **named ) File "lesson6-multi.py", line 189, in DrawGLScene glEnd(); # Done Drawing The Cube File "c:\python25\lib\site-packages\OpenGL\lazywrapper.py", line 9, in __call_ _ return wrapper( baseFunction, *args, **named ) File "c:\python25\lib\site-packages\OpenGL\GL\exceptional.py", line 57, in glE nd return baseFunction( ) File "c:\python25\lib\site-packages\OpenGL\error.py", line 194, in glCheckErro r baseOperation = baseOperation, GLError: GLError( err = 1282, description = 'invalid operation', baseOperation = glEnd, cArguments = () ) GLUT Idle callback <function DrawGLScene at 0x00D47830> with (),{} failed: retur ning None GLError( err = 1282, description = 'invalid operation', baseOperation = glEnd, cArguments = () ) ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-25 13:03 Message: Have just tested with the Demo/NeHe/lesson6-multi.py from PyOpenGL 2.0.1.09 with PyOpenGL 3.0.1 (about to be released). Works as expected. We also have a PyOpenGL-Demo package which includes the updated version of the demo, which works fine. We have lots of other scripts that use multi-texturing, both with the legacy and shader APIs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2817196&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-25 17:31:53
|
Bugs item #2829309, was opened at 2009-07-29 19:02 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&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: Luca Bruno (lethalman) Assigned to: Mike C. Fletcher (mcfletch) Summary: glCallLists calls lists twice Initial Comment: Hello, I'm using pyopengl 3.0.0~c1 from debian and mesa 7.6 from git. I'm almost pretty sure that glCallLists ([1]) calls the list 1 twice, so it happens for more than one list. Reproduce as follows: 1. glRenderMode(GL_SELECT) 2. ... glCallLists([1]) 3. glRenderMode(GL_RENDER) If the list 1 pushed only one name, you get two hits. This doesn't happen if you glCallList(1), you only get one hit as expected. I'm currently doing (glCallList(list) for list in lists) instead of glCallLists as temporarly workaround. I don't know if this happens with C++ directly, couldn't test so I've reported it here. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-25 12:31 Message: Okay, closing for now. ---------------------------------------------------------------------- Comment By: Luca Bruno (lethalman) Date: 2010-02-22 16:38 Message: I'm sorry for the reply, I'm not used to read comments from the bottom up. Apologies. If you think it can be closed, feel free to close it. I have no time to investigate on it back again. In the worst case, I'll reopen it. Thanks for your help. ---------------------------------------------------------------------- Comment By: Luca Bruno (lethalman) Date: 2010-02-22 16:36 Message: I've already added a test case which fails on my platform, I don't know why you are using another test made by you which it's clearly different than mine, most of all because I said it only happens in COMPILE AND EXECUTE. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 15:53 Message: Any news as to whether the test case fails on your machine? I haven't been able to reproduce yet. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-08-02 18:33 Message: Not getting records was just because of interference from previous test case for the same problem (duh!) With current test case I pass on both Win32 and Linux AMD64 (two different Linux AMD64 machines, with ATI and nVidia cards). Test case is in the 3.0.1a2 release if you wish to download that and test on your machine (tests/test_core.py script). ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 10:34 Message: Hmm, I'm seeing exactly the same behaviour from both call-types, namely I'm not getting any records at all (just ([],) don't have time to investigate why just now. ---------------------------------------------------------------------- Comment By: Luca Bruno (lethalman) Date: 2009-07-30 01:41 Message: I rectify, it happens with GL_COMPILE_AND_EXECUTE (not necessary other lists) and glCallLists must be in a list to call other lists: glMatrixMode(GL_PROJECTION) glLoadIdentity() gluPerspective(40.0, 1.0, 1.0, 10.0) glTranslatef (0, 0, -3) glMatrixMode (GL_MODELVIEW) glLoadIdentity () glNewList(1, GL_COMPILE_AND_EXECUTE) glInitNames () glCallLists([2]) # replace with gCallList(2) glEndList () glNewList(2, GL_COMPILE) glPushName (1) glBegin (GL_POINTS) glVertex3f (0, 0, 0) glEnd () glPopName () glEndList () glSelectBuffer (100) glRenderMode (GL_SELECT) glCallList(1) print glRenderMode (GL_RENDER) ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 00:53 Message: I can't replicate this failure condition. I am using this code, on an Ubuntu 3.0.1 Jaunty Linux Box with current BZR head of PyOpenGL: def test_glCallLists_twice( self ): """SF#2829309 report that glCallLists doubles operation""" l = glGenLists(1) try: glEnd() except error.GLerror, err: pass glSelectBuffer( 23 ) glRenderMode( GL_SELECT ) glNewList( l, GL_COMPILE ) glPushName( 222 ) glEndList() depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (0,), depth # shouldn't have added in compile mode glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (1,), depth # should have a single record glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (2,), depth # should have a second (identical) record glPopName() glPopName() glRenderMode( GL_RENDER ) which test passes. Please provide a test that fails on your platform so I can test whether we're looking at a bug that was fixed in the meantime or an error in usage or a subtle corner case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 21:38:16
|
Bugs item #2829309, was opened at 2009-07-30 01:02 Message generated for change (Comment added) made by lethalman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&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: Luca Bruno (lethalman) Assigned to: Mike C. Fletcher (mcfletch) Summary: glCallLists calls lists twice Initial Comment: Hello, I'm using pyopengl 3.0.0~c1 from debian and mesa 7.6 from git. I'm almost pretty sure that glCallLists ([1]) calls the list 1 twice, so it happens for more than one list. Reproduce as follows: 1. glRenderMode(GL_SELECT) 2. ... glCallLists([1]) 3. glRenderMode(GL_RENDER) If the list 1 pushed only one name, you get two hits. This doesn't happen if you glCallList(1), you only get one hit as expected. I'm currently doing (glCallList(list) for list in lists) instead of glCallLists as temporarly workaround. I don't know if this happens with C++ directly, couldn't test so I've reported it here. ---------------------------------------------------------------------- >Comment By: Luca Bruno (lethalman) Date: 2010-02-22 22:38 Message: I'm sorry for the reply, I'm not used to read comments from the bottom up. Apologies. If you think it can be closed, feel free to close it. I have no time to investigate on it back again. In the worst case, I'll reopen it. Thanks for your help. ---------------------------------------------------------------------- Comment By: Luca Bruno (lethalman) Date: 2010-02-22 22:36 Message: I've already added a test case which fails on my platform, I don't know why you are using another test made by you which it's clearly different than mine, most of all because I said it only happens in COMPILE AND EXECUTE. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 21:53 Message: Any news as to whether the test case fails on your machine? I haven't been able to reproduce yet. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-08-03 00:33 Message: Not getting records was just because of interference from previous test case for the same problem (duh!) With current test case I pass on both Win32 and Linux AMD64 (two different Linux AMD64 machines, with ATI and nVidia cards). Test case is in the 3.0.1a2 release if you wish to download that and test on your machine (tests/test_core.py script). ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 16:34 Message: Hmm, I'm seeing exactly the same behaviour from both call-types, namely I'm not getting any records at all (just ([],) don't have time to investigate why just now. ---------------------------------------------------------------------- Comment By: Luca Bruno (lethalman) Date: 2009-07-30 07:41 Message: I rectify, it happens with GL_COMPILE_AND_EXECUTE (not necessary other lists) and glCallLists must be in a list to call other lists: glMatrixMode(GL_PROJECTION) glLoadIdentity() gluPerspective(40.0, 1.0, 1.0, 10.0) glTranslatef (0, 0, -3) glMatrixMode (GL_MODELVIEW) glLoadIdentity () glNewList(1, GL_COMPILE_AND_EXECUTE) glInitNames () glCallLists([2]) # replace with gCallList(2) glEndList () glNewList(2, GL_COMPILE) glPushName (1) glBegin (GL_POINTS) glVertex3f (0, 0, 0) glEnd () glPopName () glEndList () glSelectBuffer (100) glRenderMode (GL_SELECT) glCallList(1) print glRenderMode (GL_RENDER) ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 06:53 Message: I can't replicate this failure condition. I am using this code, on an Ubuntu 3.0.1 Jaunty Linux Box with current BZR head of PyOpenGL: def test_glCallLists_twice( self ): """SF#2829309 report that glCallLists doubles operation""" l = glGenLists(1) try: glEnd() except error.GLerror, err: pass glSelectBuffer( 23 ) glRenderMode( GL_SELECT ) glNewList( l, GL_COMPILE ) glPushName( 222 ) glEndList() depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (0,), depth # shouldn't have added in compile mode glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (1,), depth # should have a single record glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (2,), depth # should have a second (identical) record glPopName() glPopName() glRenderMode( GL_RENDER ) which test passes. Please provide a test that fails on your platform so I can test whether we're looking at a bug that was fixed in the meantime or an error in usage or a subtle corner case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 21:36:15
|
Bugs item #2829309, was opened at 2009-07-30 01:02 Message generated for change (Comment added) made by lethalman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&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: Luca Bruno (lethalman) Assigned to: Mike C. Fletcher (mcfletch) Summary: glCallLists calls lists twice Initial Comment: Hello, I'm using pyopengl 3.0.0~c1 from debian and mesa 7.6 from git. I'm almost pretty sure that glCallLists ([1]) calls the list 1 twice, so it happens for more than one list. Reproduce as follows: 1. glRenderMode(GL_SELECT) 2. ... glCallLists([1]) 3. glRenderMode(GL_RENDER) If the list 1 pushed only one name, you get two hits. This doesn't happen if you glCallList(1), you only get one hit as expected. I'm currently doing (glCallList(list) for list in lists) instead of glCallLists as temporarly workaround. I don't know if this happens with C++ directly, couldn't test so I've reported it here. ---------------------------------------------------------------------- Comment By: Luca Bruno (lethalman) Date: 2010-02-22 22:36 Message: I've already added a test case which fails on my platform, I don't know why you are using another test made by you which it's clearly different than mine, most of all because I said it only happens in COMPILE AND EXECUTE. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 21:53 Message: Any news as to whether the test case fails on your machine? I haven't been able to reproduce yet. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-08-03 00:33 Message: Not getting records was just because of interference from previous test case for the same problem (duh!) With current test case I pass on both Win32 and Linux AMD64 (two different Linux AMD64 machines, with ATI and nVidia cards). Test case is in the 3.0.1a2 release if you wish to download that and test on your machine (tests/test_core.py script). ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 16:34 Message: Hmm, I'm seeing exactly the same behaviour from both call-types, namely I'm not getting any records at all (just ([],) don't have time to investigate why just now. ---------------------------------------------------------------------- Comment By: Luca Bruno (lethalman) Date: 2009-07-30 07:41 Message: I rectify, it happens with GL_COMPILE_AND_EXECUTE (not necessary other lists) and glCallLists must be in a list to call other lists: glMatrixMode(GL_PROJECTION) glLoadIdentity() gluPerspective(40.0, 1.0, 1.0, 10.0) glTranslatef (0, 0, -3) glMatrixMode (GL_MODELVIEW) glLoadIdentity () glNewList(1, GL_COMPILE_AND_EXECUTE) glInitNames () glCallLists([2]) # replace with gCallList(2) glEndList () glNewList(2, GL_COMPILE) glPushName (1) glBegin (GL_POINTS) glVertex3f (0, 0, 0) glEnd () glPopName () glEndList () glSelectBuffer (100) glRenderMode (GL_SELECT) glCallList(1) print glRenderMode (GL_RENDER) ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 06:53 Message: I can't replicate this failure condition. I am using this code, on an Ubuntu 3.0.1 Jaunty Linux Box with current BZR head of PyOpenGL: def test_glCallLists_twice( self ): """SF#2829309 report that glCallLists doubles operation""" l = glGenLists(1) try: glEnd() except error.GLerror, err: pass glSelectBuffer( 23 ) glRenderMode( GL_SELECT ) glNewList( l, GL_COMPILE ) glPushName( 222 ) glEndList() depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (0,), depth # shouldn't have added in compile mode glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (1,), depth # should have a single record glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (2,), depth # should have a second (identical) record glPopName() glPopName() glRenderMode( GL_RENDER ) which test passes. Please provide a test that fails on your platform so I can test whether we're looking at a bug that was fixed in the meantime or an error in usage or a subtle corner case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 20:53:59
|
Bugs item #2829309, was opened at 2009-07-29 19:02 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&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: Luca Bruno (lethalman) Assigned to: Mike C. Fletcher (mcfletch) Summary: glCallLists calls lists twice Initial Comment: Hello, I'm using pyopengl 3.0.0~c1 from debian and mesa 7.6 from git. I'm almost pretty sure that glCallLists ([1]) calls the list 1 twice, so it happens for more than one list. Reproduce as follows: 1. glRenderMode(GL_SELECT) 2. ... glCallLists([1]) 3. glRenderMode(GL_RENDER) If the list 1 pushed only one name, you get two hits. This doesn't happen if you glCallList(1), you only get one hit as expected. I'm currently doing (glCallList(list) for list in lists) instead of glCallLists as temporarly workaround. I don't know if this happens with C++ directly, couldn't test so I've reported it here. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 15:53 Message: Any news as to whether the test case fails on your machine? I haven't been able to reproduce yet. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-08-02 18:33 Message: Not getting records was just because of interference from previous test case for the same problem (duh!) With current test case I pass on both Win32 and Linux AMD64 (two different Linux AMD64 machines, with ATI and nVidia cards). Test case is in the 3.0.1a2 release if you wish to download that and test on your machine (tests/test_core.py script). ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 10:34 Message: Hmm, I'm seeing exactly the same behaviour from both call-types, namely I'm not getting any records at all (just ([],) don't have time to investigate why just now. ---------------------------------------------------------------------- Comment By: Luca Bruno (lethalman) Date: 2009-07-30 01:41 Message: I rectify, it happens with GL_COMPILE_AND_EXECUTE (not necessary other lists) and glCallLists must be in a list to call other lists: glMatrixMode(GL_PROJECTION) glLoadIdentity() gluPerspective(40.0, 1.0, 1.0, 10.0) glTranslatef (0, 0, -3) glMatrixMode (GL_MODELVIEW) glLoadIdentity () glNewList(1, GL_COMPILE_AND_EXECUTE) glInitNames () glCallLists([2]) # replace with gCallList(2) glEndList () glNewList(2, GL_COMPILE) glPushName (1) glBegin (GL_POINTS) glVertex3f (0, 0, 0) glEnd () glPopName () glEndList () glSelectBuffer (100) glRenderMode (GL_SELECT) glCallList(1) print glRenderMode (GL_RENDER) ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-07-30 00:53 Message: I can't replicate this failure condition. I am using this code, on an Ubuntu 3.0.1 Jaunty Linux Box with current BZR head of PyOpenGL: def test_glCallLists_twice( self ): """SF#2829309 report that glCallLists doubles operation""" l = glGenLists(1) try: glEnd() except error.GLerror, err: pass glSelectBuffer( 23 ) glRenderMode( GL_SELECT ) glNewList( l, GL_COMPILE ) glPushName( 222 ) glEndList() depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (0,), depth # shouldn't have added in compile mode glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (1,), depth # should have a single record glCallLists( [l] ) depth = glGetIntegerv( GL_NAME_STACK_DEPTH ) assert depth == (2,), depth # should have a second (identical) record glPopName() glPopName() glRenderMode( GL_RENDER ) which test passes. Please provide a test that fails on your platform so I can test whether we're looking at a bug that was fixed in the meantime or an error in usage or a subtle corner case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2829309&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 20:51:44
|
Bugs item #2844174, was opened at 2009-08-25 07:18 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2844174&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: Leith Bade (ljbade) Assigned to: Mike C. Fletcher (mcfletch) Summary: Bug in glGetShaderiv on Windows Initial Comment: I am using 3.0.1.a3 on Windows 7 with Python 2.5.4, and get this error whenever I use glCompileShader(): File "opengl.py", line 97, in main glCompileShader(self.basicVert) File "C:\Python25\Lib\site-packages\OpenGL\GL\VERSION\GL_2_0.py", line 98, in GLSLCheckError getter( cArguments[0], key, ctypes.byref(status)) File "C:\Python25\Lib\site-packages\OpenGL\lazywrapper.py", line 19, in __call __ return wrapper( baseFunction, *args, **named ) TypeError: glGetShaderiv() takes exactly 3 arguments (4 given) Seems to be similar to bug #2645723 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 15:51 Message: Okay, this seems to have been fixed a while ago, closing, please reopen if the problem is discovered with 3.0.1 final. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-11-07 23:22 Message: Thanks for the bug report. Should be fixed in trunk and released with the 3.0.1b1 release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2844174&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 20:50:40
|
Bugs item #2895081, was opened at 2009-11-10 04:04 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2895081&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: https://www.google.com/accounts () Assigned to: Mike C. Fletcher (mcfletch) Summary: Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS Initial Comment: Running: print 'Max texture image units ', glGetInteger(GL_MAX_TEXTURE_IMAGE_UNITS) Produces the following error: File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 1282, in __call__ return self._finalCall( *args, **named ) File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 552, in wrapperCall cArgs = tuple(calculate_cArgs( pyArgs )) File "/usr/lib/python2.6/site-packages/OpenGL/wrapper.py", line 355, in calculate_cArgs yield converter( pyArgs, index, self ) File "/usr/lib/python2.6/site-packages/OpenGL/converters.py", line 195, in __call__ return self.arrayType.zeros( self.getSize(pyArgs) ) File "/usr/lib/python2.6/site-packages/OpenGL/converters.py", line 234, in getSize raise KeyError( """Unknown specifier %s"""%( specifier )) KeyError: ('Unknown specifier GL_MAX_TEXTURE_IMAGE_UNITS (34930)', 'Failure in cConverter <OpenGL.converters.SizedOutput object at 0x187a140>', (GL_MAX_TEXTURE_IMAGE_UNITS,), 1, <OpenGL.wrapper.glGetIntegerv object at 0x1872f38>) ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 15:50 Message: Okay, the particular bug should be fixed in the 3.0.1 release going out today. There may be more bugs in missing glGet constants, but we'll have to cross that bridge when we get there. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-11-13 11:16 Message: Just implemented the first suite of truly automated tests, but they wouldn't have caught this, as I don't have any code exercising the missing features. As for an ugly workaround, you can call OpenGL.GL.glget.addGLGetConstant( constant, (1,) ) where (1,) is the dimension of the array to be created for the constant, so e.g. (4,4) for most matrices. I've also added a script that goes ahead and attempts to use glGet on *every* constant in the core, but that's limited by the hardware/drivers I have available. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2009-11-10 23:12 Message: Some automated tests might be helpful too =) Is there some ugly workaround for this? I am not sure that people running my software will have the desire/ability to upgrade to 3.0.1? ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-11-10 11:48 Message: Wow, there were a *lot* of bugs hiding behind that one. Any non-extension glGet constant over about GL 1.1 was going to raise an error. I've updated the code to have all GL 2.1 constants, but there's going to be 3.0, 3.1 and 3.2 constants missing. Need to get a better mechanism for determining what can be used with glGet to make this automatic. 3.0.1 should have the fix for the particular bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2895081&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 20:48:21
|
Bugs item #2897786, was opened at 2009-11-14 14:25 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2897786&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: Mike C. Fletcher (mcfletch) Summary: glTexImage Initial Comment: glTexImage does not accept the external pixel data type (last parameter of glTexImage) GL_UNSIGNED_INT_24_8 for GL_DEPTH24_STENCIL8 textures. Get a key error in images.TYPE_TO_ARRAYTYPE ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 15:48 Message: This is part of the final release that should be going out today. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-11-14 19:14 Message: Image-type registrations were missing for the 3 variants (NV, EXT and ARB). Added in bzr head. Thanks. Example registration should you wish to do a work-around (note, don't have any test case, so have not been able to test that this does what it's supposed to do): --- OpenGL/GL/ARB/framebuffer_object.py 2009-08-30 02:28:09 +0000 +++ OpenGL/GL/ARB/framebuffer_object.py 2009-11-14 19:48:04 +0000 @@ -30,4 +30,9 @@ if framebuffers is None: framebuffers = arrays.GLuintArray.asArray( n ) n = arrays.GLuintArray.arraySize( framebuffers ) - return baseOperation( n, framebuffers ) \ No newline at end of file + return baseOperation( n, framebuffers ) + +# Setup the GL_UNSIGNED_INT_24_8 image type +from OpenGL import images +images.TYPE_TO_ARRAYTYPE[ GL_UNSIGNED_INT_24_8 ] = GL_UNSIGNED_INT +images.TIGHT_PACK_FORMATS[ GL_UNSIGNED_INT_24_8 ] = 4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2897786&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 20:45:20
|
Bugs item #2935298, was opened at 2010-01-19 18:04 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2935298&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 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike C. Fletcher (mcfletch) Summary: glShaderSource wrapper fail on ATI card ? Initial Comment: Hi everyone, I got a problem on my framework with Shader + ATI card. By switching from pyglet to pyopengl, shader just not working anymore. After investigation, it seem that the wrapper on glShaderSource is not working properly. If i use the pyopengl wrapper (glShaderSource(shader, source)), i got an error at glLinkProgram() : Fragment shader was successfully compiled to run on hardware. Fragment shader(s) failed to link, vertex shader(s) failed to link. ERROR: 1:1: error(#132) Syntax error: 'v' parse error ERROR: error(#273) 1 compilation errors. No code generated ERROR: 1:1: error(#132) Syntax error: 'v' parse error ERROR: error(#273) 1 compilation errors. No code generated If i'm doing ctype myself like: glShaderSource = platform.createBaseFunction( 'glShaderSource', dll=platform.GL, resultType=None, argTypes=(constants.GLhandle, constants.GLsizei, ctypes.POINTER(ctypes.c_char_p), arrays.GLintArray,), doc = 'glShaderSource( GLhandle(shaderObj), str( string) ) -> None', argNames = ('shaderObj', 'count', 'string', 'length',), ) from ctypes import * source = c_char_p(source) length = c_int(-1) glShaderSource(shader, 1, byref(source), byref(length)) -> no more error message at glLinkProgram. Where i can debug more the wrapper function ? Is it a converter problem ? Thanks, Mathieu Note: i'm running the 3.0.0-0ubuntu1 from Ubuntu Karmic. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 15:45 Message: This is almost certainly the case where you are specifying the source as a single string. The function actually takes a list-of-strings. Some implementations work perfectly well with the sequence-of-one-character-strings (concatenating them before compiling), others run the syntax check/compile before concatenation. I've just added code to convert to a list before doing the conversion if you pass in a string. Hopefully this will avoid these problems in the future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2935298&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 20:30:51
|
Bugs item #2939786, was opened at 2010-01-25 17:47 Message generated for change (Settings changed) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2939786&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: Mike C. Fletcher (mcfletch) Summary: glColor wrapper doesn't handle tuple of floats properly Initial Comment: In the following fragment of exceptional.py Either GLdoubleArray should be used or colorDispatch should refer to glColorXfv not glColorXdv. In simpler words types should match or there is no effect to glColor call colorDispatch = { 3: annotations.glColor3dv, 4: annotations.glColor4dv, } def glColor( *args ): """glColor*f* -- convenience function to dispatch on argument type dispatches to glColor3f, glColor2f, glColor4f, glColor3f, glColor2f, glColor4f depending on the arguments passed... """ arglen = len(args) if arglen == 1: arg = arrays.GLfloatArray.asArray( args[0] ) function = glColorDispatch[arrays.GLfloatArray.arraySize( arg )] return function( arg ) elif arglen == 2: return simple.glColor2d( *args ) elif arglen == 3: return simple.glColor3d( *args ) elif arglen == 4: return simple.glColor4d( *args ) else: raise ValueError( """Don't know how to handle arguments: %s"""%(args,)) Tested on Gentoo linux, PyOpengl 3.0.1_beta1 and beta2 Python 2.6.4 email: de...@gm... ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 15:30 Message: Revision 346 in bzr should fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2939786&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 20:29:06
|
Bugs item #2943244, was opened at 2010-01-31 10:16 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2943244&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: 3 Private: No Submitted By: jfpacker (jfpacker) Assigned to: Mike C. Fletcher (mcfletch) Summary: PyOpenGL-accelerate and numpy 1.4 numpy_formathandler error Initial Comment: importing OpenGL.GL gives the error: "ValueError: numpy.dtype does not appear to be the correct type object". To reproduce this bug, install python 2.6 (my minor version 4, ie: 2.6.4), PyOpenGL 3.0.1b2-py26-win32 and PyOpenGL-accelerate-3.0.1b2-py26-win32 and numpy 1.4. In the interpreter type: import OpenGL from OpenGL import GL This gives the output: File "C:\Python26\lib\site-packages\GLavish\library\locals.py", line 7, in <mo dule> from OpenGL import GL File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\GL \__init__.py", line 2, in <module> from OpenGL.raw.GL import * File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ra w\GL\__init__.py", line 6, in <module> from OpenGL.raw.GL.constants import * File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ra w\GL\constants.py", line 7, in <module> from OpenGL import platform, arrays File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar rays\__init__.py", line 22, in <module> formathandler.FormatHandler.loadAll() File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar rays\formathandler.py", line 37, in loadAll cls.loadPlugin( entrypoint ) File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar rays\formathandler.py", line 44, in loadPlugin plugin_class = entrypoint.load() File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\pl ugins.py", line 14, in load return importByName( self.import_path ) File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\pl ugins.py", line 28, in importByName module = __import__( ".".join(moduleName), {}, {}, moduleName) File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\ar rays\numpymodule.py", line 25, in <module> from OpenGL_accelerate.numpy_formathandler import NumpyHandler File "c:\users\jeff\appdata\local\temp\easy_install-uwdslx\PyOpenGL_accelerate -3.0.1b2-py2.6-win32.egg.tmp\OpenGL_accelerate\numpy_formathandler.py", line 7, in <module> File "c:\users\jeff\appdata\local\temp\easy_install-uwdslx\PyOpenGL_accelerate -3.0.1b2-py2.6-win32.egg.tmp\OpenGL_accelerate\numpy_formathandler.py", line 6, in __bootstrap__ File "numpy.pxd", line 30, in OpenGL_accelerate.numpy_formathandler (src\numpy _formathandler.c:3543) ValueError: numpy.dtype does not appear to be the correct type object ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 15:29 Message: Hrm. Sounds like we have a problem with the numpy version changes. Argh. Seems we need to be patching setuptools to allow for checking against the numpy version. I'd hoped we'd seen the back of patching setup scripts. I'll attempt to fix it when I'm on Win32 again. ---------------------------------------------------------------------- Comment By: jfpacker (jfpacker) Date: 2010-01-31 10:23 Message: This only occurs if you easy_install PyOpenGL-accelerate as it downloads the pre-built version win32 version. I downloaded the source and installed from source and it works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2943244&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 19:31:04
|
Bugs item #2946226, was opened at 2010-02-04 17:59 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2946226&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: glFramebufferTexture2DEXT causes error , etc. Initial Comment: I using PyOpenGL 3.0.1b2 on Windows 7 on a Dell XT 2 tablet PC (http://www.dell.com/tablet). The tablet has a intel GMA 4500MHD graphics chip with the newest drivers from intel installed. I'm having problems creating a Framebuffer object using pyOpenGL. The following code runs fine on every machine I have access to except for this one. I know the graphics chip has FBO support, and have successfully compiled and run various C programs using FBO's. The problem occurs when I call glFramebufferTexture2DEXT, to attach my texture to the FBO. The program crashes and prints a traceback with GL error code 1286, which I believe is INVALID_FRAMEBUFFER_OPERATION_EXT. If anyone knows what I am doing wrong, has a workaround, or even just a suggestion of identifying the problem better, I would be very thankful. I'm posting a code snippet and the output it produces. I know teh code isnt complete and nothing is actually done with the fbo etc. but its enough to crash the program, and demonstrates the first problem I encounter on this machine. The code: ======================================================================= import pygame from pygame.locals import * from OpenGL.GL import * from OpenGL.GL.EXT.framebuffer_object import * def draw (): glClearColor(0.0,0.0,0.0,0.0) glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) #draw stuff here pygame.display.flip() pygame.init() pygame.display.set_mode((512,512),OPENGL | DOUBLEBUF) #setup a texture tex = glGenTextures(1); glBindTexture(GL_TEXTURE_2D, tex); glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 512, 512, 0, GL_RGBA, GL_UNSIGNED_BYTE, None); glBindTexture(GL_TEXTURE_2D, 0); #setup teh fbo fbo = glGenFramebuffersEXT(1) glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo) glBindTexture(GL_TEXTURE_2D, tex) #this call produces an error! glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,GL_TEXTURE_2D, tex, 0) while 1: event=pygame.event.poll () if event.type is QUIT: sys.exit(0) draw() Here is the output: =================================================================== Traceback (most recent call last): File "test.py", line 29, in <module> glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,GL_TEXTURE_2D, tex, 0) File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\platform\baseplatform.py", line 335, in __call__ return self( *args, **named ) File "C:\Python26\lib\site-packages\pyopengl-3.0.1b2-py2.6-win32.egg\OpenGL\error.py", line 208, in glCheckError baseOperation = baseOperation, OpenGL.error.GLError: GLError( err = 1286, baseOperation = glFramebufferTexture2DEXT, cArguments = ( GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, 1L, 0, ) ) So I think I figured out whats going on: in pyOpenGL error.py from line 202, you guys have: =========================================== err = self._currentChecker() if err: # GL_NO_ERROR's guaranteed value is 0 raise GLError( err, result, cArguments = cArguments, baseOperation = baseOperation, ) =========================================== Now, GL_NO_ERROR might always be 0. but getting teh error code after e.g. attaching a texture to an FBO, using glFramebufferTexture2DEXT does not return GL_NO_ERROR, even though everything went great. It's supposed to return GL_FRAMEBUFFER_COMPLETE_EXT (36053 int value), which is what I get if i turn of ERROR_CHECK and check manually after attaching the texture. So I think the code generates an error, where there is none. Not sure why it works fine on my nvidia gpu's..maybe teh openGL spec isn't definitive on this one? Still not sure why I get a NullFunctionError for glDeleteFrameBuffersEXT when I turn on ERROR_CHECK (again works fine without). Also, bool(glGenFrameBuffersEXT) returns False, although the function is available. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 14:30 Message: glError() should not return GL_FRAMEBUFFER_COMPLETE_EXT on any conformant system. http://www.opengl.org/registry/specs/EXT/framebuffer_object.txt adds GL_FRAMEBUFFER_INCOMPLETE_EXT to the glError enum. Basically it sounds like we've got a driver error here. The nVidia cards are doing the right thing. wrt the null-function error: the error checking *also* checks for NULL functions, so if you're getting bool() == False you'd expect the error-raising behaviour. The bool() checks are quite simple, so if bool( entrypoint ) is giving False I'd suspect we're seeing a real failure to resolve the entry point. Why that would happen I can't say just now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2946226&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 17:14:26
|
Bugs item #2903797, was opened at 2009-11-25 10:33 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2903797&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: Silverstein (herc111) Assigned to: Mike C. Fletcher (mcfletch) Summary: 3.0.1a3 imports throw OSError Initial Comment: We recently upgraded to 3.0.1a3 from 2.0.2.01. In v2 if the underlying GL library was missing the import of OpenGL.GL would raise an ImportError. With v3.0 it now raises an OSError. Shouldn't this throw an ImportError? We distribute our software including Python and PyOpenGL but we do not distribute GL libraries (as we want any native hardware accelerated GL libraries/drivers to be used). There are situations where users run our software and don't have GL libraries (like on a head node of a cluster). To handle these circumstances we have been checking for ImportError's. Unless I'm missing something this seems like the correct exception to raise. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 12:14 Message: I believe we've fixed this, I'm closing, please re-open or re-submit if there's something missing. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-02-22 03:25 Message: 7WdxGn <a href="http://piclnsjhsfkg.com/">piclnsjhsfkg</a>, [url=http://thbtiuizqofy.com/]thbtiuizqofy[/url], [link=http://xghvtjahrsti.com/]xghvtjahrsti[/link], http://efevnryauvnd.com/ ---------------------------------------------------------------------- Comment By: Silverstein (herc111) Date: 2009-11-25 15:36 Message: Mike, ImportError for GL and null func errors for GLU sounds great. With the holiday this week I won't get to test this until next week at the earliest. Will post back the results. ---------------------------------------------------------------------- Comment By: Silverstein (herc111) Date: 2009-11-25 15:08 Message: I guess this change in behavior between pyopengl 2 and 3 is due to the use of ctypes where ctypes is throwing an OSError whereas prior to using ctypes it threw an ImportError. Unfortunately, for us we can't control where users will run our software. Some of our software requires OpenGL (and in those cases it isn't an issue). In some of our tools the use of OpenGL is a nice additional feature, but if for some reason it isn't available, then we try, as much as possible, to continue to allow the python scripts to work (ie be usable by the user but with somewhat diminished feature sets). In these cases we need to trap the failed imports of the GL/GLU libraries. It sounds like you don't want to catch and then throw an ImportError and that you feel the right way to do this would be to NULL out the functions, but that this is a lot of work (which I can see). I take that to mean that this won't be fixed. If that's the case, we'll try to put our own try-except catches into our own python classes. BTW, we've been very happy with PyOpenGL. So thanks! Herc ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-11-25 15:07 Message: Okay, I'm going to punt on the "No GL" case and raise an ImportError. The no GLU case on GLX and WGL platforms will now produce null-function errors on attempts to call GLU functions (as with GLUT or GLE). This is all in bzr head now, if you could test in environments where this can actually happen it would be helpful to me. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-11-25 14:51 Message: Hmm, I can see where the error is coming from, but it seems that the correct approach would be that taken for the rest of the libraries (GLE and GLUT), i.e. no import error, just a lot of NULL functions... thing is there's lots of code that is going to fail because e.g. it tries to load error handling functions. Quite frankly I never considered the failure case of "no GL" or a "GL without GLU" platform. ---------------------------------------------------------------------- Comment By: Silverstein (herc111) Date: 2009-11-25 14:17 Message: Sorry about that. I should have added that to the case. I've done that now. Note that this is being run through our run-time environment, but this would happen even if we did a direct OpenGL.GL import (which can be seen in the stack trace). The culprit seems to be that the _dlopen generates an OSError. While strictly speaking that may be the case, as a user of the module I would have simply expected an ImportError.s. On a perhaps somewhat related note I noticed that if I try to import just GL but don't have a valid GLU library, that it complains. I would have thought that importing just GL would not try to load the GLU library. Should I file a separate bug case for that? Thanks, Herc ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2009-11-25 14:06 Message: Hmm, can you tell me *where* the OSError comes from (precisely, as in a traceback). It would make it much easier to catch the OSError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2903797&group_id=5988 |
32 messages has been excluded from this view by a project administrator.
