pyopengl-devel Mailing List for PyOpenGL (Page 2)
Brought to you by:
mcfletch
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: Rik <ric...@ya...> - 2014-05-22 22:54:05
|
Can someone point me to, or send a test program? I'm on a windows box, also? I have been reading the "red-book" how well does it translate to Py? I luv Py! But was learning c\c++ to learn opengl thanks for adding me Oh, if there is a FAQ's??? I didn't see it? Sorry. {/•Rik•\} |
From: Mike C. F. <mcf...@vr...> - 2013-11-20 02:36:50
|
On 11/08/2013 09:13 AM, Roman Valov wrote: > Hello, Mike. Hi Roman, I'm afraid I've rather hacked up your patch as I made it fit into the xml generation branch. The biggest changes made: * I made the API-specific version/extension querying use a plug-in mechanism, with each API expected to provide the code in its own namespace (_types.py) * Currently this is *not* properly context/display/screen/HDC specific, but the idea is that each sub-class should be able to specify how to scope the caching * I added the concept of an assumed version for each plugin, so e.g. we assume at least glX [1,1] and gl [1,1] * I tried to provide a fallback for glXGetCurrentDisplay() (basically using raw X11) * I added an EGL version * I started on a WGL version of the plugin, but I haven't actually booted into Windows to work on it That's rather more changes than I was intending, but hopefully it makes the result cleaner (e.g. there's just one entry point to check for any extension being supported now, and all of the APIs use the same basic code for managing their extension/version querying). > In addition, I've removed one of calls to 'checkExtension' in > 'constructFunction' method, > because it seems redundant for me. Fix me, if I wrong. You were correct, there was an extraneous call in there. Thanks, and enjoy, Mike > > On Mon, Nov 4, 2013 at 8:46 PM, Mike C. Fletcher > <mcf...@vr... <mailto:mcf...@vr...>> wrote: > > On 11/02/2013 10:11 AM, Roman Valov wrote: > > Ok, Mike.. the actual question to you is in last paragraph. > > > Here is update with my review of the problem with > wglSwapIntervalEXT and wglGetSwapIntervalEXT. > Seems that problem is driven by two diffrent factors: > > 1) Wrapper code generator (gengl.py) doesn't set 'extension' > parameter for 'createBaseFunction'. > > Thus OpenGL/platform/baseplatform.py code tries to load > extension functions from platform.GL library > which actually doesn't have them in common case and as a > result I've got these functions unresolved. > > 2) BasePlatform.checkExtension code relies only on > glGetString(GL_EXTENSIONS). > > I've tested extension WGL_EXT_swap_control on NV and Intel gpu > platforms. In fact only > on NV platform this extension was listed in > glGetString(GL_EXTENSIONS) result. According > to specs: > > http://www.opengl.org/registry/specs/EXT/wgl_extensions_string.txt > http://www.opengl.org/registry/specs/ARB/wgl_extensions_string.txt > http://www.opengl.org/wiki/Load_OpenGL_Functions#Platform-specific_Extensions > > one would to use wglGetExtensionsStringXXX to check for WGL > extensions. On both platforms I've used > required extension was listed in wglGetGetExtensionsString > output. As I see on GLX there is similar > functionality provided by glXQueryExtensionsString. Which also > aren't taken into account in PyOpenGL. > > > > So, my plan is firstly to fix gengl.py and later add method > for platform-specific extensions check. > But now I'm stuck with gengl.py doesn't produce the same > _WGL_NV.py that is commited to bzr. > Besides header file path in comments (which is minor issue), I > see whitespaces differences and > moreover, in myself-generated _WGL_NV.py there are no 'GLAPI' > symbol. Could you say anything > about that symbol? Was it added by hand or was it included in > previous versions of wglext.h? > > > > gengl.py was probably last run many years ago now, and the > versions of the underlying libraries you're using (basically > pyglet) are likely different than the ones I used way back then. > GLAPI is basically a macro that marks a function for DLL export, > it *shouldn't* affect anything in our wrappers. > > Note that I'm about 50% of the way through an API generator based > on the Khronos XML API spec, i.e. generating the wrappers from the > thing that defines these APIs formally (and which is used to > generate the headers that gengl and get_gl_extensions are > parsing). That *should* generate all of WGL, GLX, EGL, GL, and > GLES in full, and should keep them up-to-date going forward in a > robust and maintainable fashion. I'll integrate your changes for > wglGetExtensionsString and glXQueryExtensionsString when I get to > the point of generating the WGL, GLX and EGL wrappers from the > specs. The new generators won't actually alter the support code > (e.g. platform), so a patch to those *should* carry across. > > I *wouldn't* suggest spending much time on fixing gengl.py based > generation, because it has always proven rather fragile (which is > why I don't use it for the core), even if it were working today, > I'm unlikely to keep using it if I can use the XML registry to > generate the functions. > > The WGL, GLX and the like extensions will be declared in the same > manner as the GL ones, so you'll get the "extension" parameter set > properly when regenerated. > > Hope that helps, > Mike > > -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Roman V. <red...@gm...> - 2013-11-08 14:14:22
|
Hello, Mike. Here is a preview of patch for platform-specific extensions. It supports only GLX platform, since I want to get your review of my design decisions. Once it will be done, I will update the patch with WGL support and put stubs for other platforms. So, each platform implementation should provide 'getExtensionsString' method to list available platform-specific extensions in space-separated string. Both, GLX and WGL ways provide this list in this form. In case of GLX implementation definition of method is surrounded with try-except block, because code tries to import 'glXQueryExtensionsString' and 'glXGetCurrentDisplay' functions from GL-dll and according to spec these functions are defined in version 1.1 and 1.2 of GLX-spec respectively. Thus in case GLX implementation doesn't provide a method for querying extensions, code will define a method returning empty string. Non-extensible and stub platforms should do the same. Next, base platform implementation defines 'hasPlatformExtension' method which acts like 'extensions.hasGLExtension' function except it won't perform logging. I was trying to avoid platform-specific code and circular dependencies with 'OpenGL.platform' in 'OpenGL.extensions' module, thus all code resides in 'OpenGL.platform' sub-package. However, cached 'contextdata' for 'GL_EXTENSIONS' will also be used for platform-specific extensions. Once notable difference between 'hasGLExtension' and 'hasPlatformExtension' is that buffer for extensions list is by default initialized with 'None' to distinguish with '[]' which means no extensions available. In addition, I've removed one of calls to 'checkExtension' in 'constructFunction' method, because it seems redundant for me. Fix me, if I wrong. Best Regards, Roman. On Mon, Nov 4, 2013 at 8:46 PM, Mike C. Fletcher <mcf...@vr...>wrote: > On 11/02/2013 10:11 AM, Roman Valov wrote: > >> Ok, Mike.. the actual question to you is in last paragraph. >> >> >> Here is update with my review of the problem with wglSwapIntervalEXT and >> wglGetSwapIntervalEXT. >> Seems that problem is driven by two diffrent factors: >> >> 1) Wrapper code generator (gengl.py) doesn't set 'extension' parameter >> for 'createBaseFunction'. >> >> Thus OpenGL/platform/baseplatform.py code tries to load extension >> functions from platform.GL library >> which actually doesn't have them in common case and as a result I've got >> these functions unresolved. >> >> 2) BasePlatform.checkExtension code relies only on >> glGetString(GL_EXTENSIONS). >> >> I've tested extension WGL_EXT_swap_control on NV and Intel gpu platforms. >> In fact only >> on NV platform this extension was listed in glGetString(GL_EXTENSIONS) >> result. According >> to specs: >> >> http://www.opengl.org/registry/specs/EXT/wgl_extensions_string.txt >> http://www.opengl.org/registry/specs/ARB/wgl_extensions_string.txt >> http://www.opengl.org/wiki/Load_OpenGL_Functions# >> Platform-specific_Extensions >> >> one would to use wglGetExtensionsStringXXX to check for WGL extensions. >> On both platforms I've used >> required extension was listed in wglGetGetExtensionsString output. As I >> see on GLX there is similar >> functionality provided by glXQueryExtensionsString. Which also aren't >> taken into account in PyOpenGL. >> >> >> >> So, my plan is firstly to fix gengl.py and later add method for >> platform-specific extensions check. >> But now I'm stuck with gengl.py doesn't produce the same _WGL_NV.py that >> is commited to bzr. >> Besides header file path in comments (which is minor issue), I see >> whitespaces differences and >> moreover, in myself-generated _WGL_NV.py there are no 'GLAPI' symbol. >> Could you say anything >> about that symbol? Was it added by hand or was it included in previous >> versions of wglext.h? >> > > > gengl.py was probably last run many years ago now, and the versions of the > underlying libraries you're using (basically pyglet) are likely different > than the ones I used way back then. GLAPI is basically a macro that marks > a function for DLL export, it *shouldn't* affect anything in our wrappers. > > Note that I'm about 50% of the way through an API generator based on the > Khronos XML API spec, i.e. generating the wrappers from the thing that > defines these APIs formally (and which is used to generate the headers that > gengl and get_gl_extensions are parsing). That *should* generate all of > WGL, GLX, EGL, GL, and GLES in full, and should keep them up-to-date going > forward in a robust and maintainable fashion. I'll integrate your changes > for wglGetExtensionsString and glXQueryExtensionsString when I get to the > point of generating the WGL, GLX and EGL wrappers from the specs. The new > generators won't actually alter the support code (e.g. platform), so a > patch to those *should* carry across. > > I *wouldn't* suggest spending much time on fixing gengl.py based > generation, because it has always proven rather fragile (which is why I > don't use it for the core), even if it were working today, I'm unlikely to > keep using it if I can use the XML registry to generate the functions. > > The WGL, GLX and the like extensions will be declared in the same manner > as the GL ones, so you'll get the "extension" parameter set properly when > regenerated. > > Hope that helps, > Mike > > |
From: Mike C. F. <mcf...@vr...> - 2013-11-04 17:05:10
|
On 11/02/2013 10:11 AM, Roman Valov wrote: > Ok, Mike.. the actual question to you is in last paragraph. > > > Here is update with my review of the problem with wglSwapIntervalEXT > and wglGetSwapIntervalEXT. > Seems that problem is driven by two diffrent factors: > > 1) Wrapper code generator (gengl.py) doesn't set 'extension' parameter > for 'createBaseFunction'. > > Thus OpenGL/platform/baseplatform.py code tries to load extension > functions from platform.GL library > which actually doesn't have them in common case and as a result I've > got these functions unresolved. > > 2) BasePlatform.checkExtension code relies only on > glGetString(GL_EXTENSIONS). > > I've tested extension WGL_EXT_swap_control on NV and Intel gpu > platforms. In fact only > on NV platform this extension was listed in glGetString(GL_EXTENSIONS) > result. According > to specs: > > http://www.opengl.org/registry/specs/EXT/wgl_extensions_string.txt > http://www.opengl.org/registry/specs/ARB/wgl_extensions_string.txt > http://www.opengl.org/wiki/Load_OpenGL_Functions#Platform-specific_Extensions > > one would to use wglGetExtensionsStringXXX to check for WGL > extensions. On both platforms I've used > required extension was listed in wglGetGetExtensionsString output. As > I see on GLX there is similar > functionality provided by glXQueryExtensionsString. Which also aren't > taken into account in PyOpenGL. > > > > So, my plan is firstly to fix gengl.py and later add method for > platform-specific extensions check. > But now I'm stuck with gengl.py doesn't produce the same _WGL_NV.py > that is commited to bzr. > Besides header file path in comments (which is minor issue), I see > whitespaces differences and > moreover, in myself-generated _WGL_NV.py there are no 'GLAPI' symbol. > Could you say anything > about that symbol? Was it added by hand or was it included in previous > versions of wglext.h? gengl.py was probably last run many years ago now, and the versions of the underlying libraries you're using (basically pyglet) are likely different than the ones I used way back then. GLAPI is basically a macro that marks a function for DLL export, it *shouldn't* affect anything in our wrappers. Note that I'm about 50% of the way through an API generator based on the Khronos XML API spec, i.e. generating the wrappers from the thing that defines these APIs formally (and which is used to generate the headers that gengl and get_gl_extensions are parsing). That *should* generate all of WGL, GLX, EGL, GL, and GLES in full, and should keep them up-to-date going forward in a robust and maintainable fashion. I'll integrate your changes for wglGetExtensionsString and glXQueryExtensionsString when I get to the point of generating the WGL, GLX and EGL wrappers from the specs. The new generators won't actually alter the support code (e.g. platform), so a patch to those *should* carry across. I *wouldn't* suggest spending much time on fixing gengl.py based generation, because it has always proven rather fragile (which is why I don't use it for the core), even if it were working today, I'm unlikely to keep using it if I can use the XML registry to generate the functions. The WGL, GLX and the like extensions will be declared in the same manner as the GL ones, so you'll get the "extension" parameter set properly when regenerated. Hope that helps, Mike |
From: Roman V. <red...@gm...> - 2013-11-02 14:12:27
|
Ok, Mike.. the actual question to you is in last paragraph. Here is update with my review of the problem with wglSwapIntervalEXT and wglGetSwapIntervalEXT. Seems that problem is driven by two diffrent factors: 1) Wrapper code generator (gengl.py) doesn't set 'extension' parameter for 'createBaseFunction'. Thus OpenGL/platform/baseplatform.py code tries to load extension functions from platform.GL library which actually doesn't have them in common case and as a result I've got these functions unresolved. 2) BasePlatform.checkExtension code relies only on glGetString(GL_EXTENSIONS). I've tested extension WGL_EXT_swap_control on NV and Intel gpu platforms. In fact only on NV platform this extension was listed in glGetString(GL_EXTENSIONS) result. According to specs: http://www.opengl.org/registry/specs/EXT/wgl_extensions_string.txt http://www.opengl.org/registry/specs/ARB/wgl_extensions_string.txt http://www.opengl.org/wiki/Load_OpenGL_Functions#Platform-specific_Extensions one would to use wglGetExtensionsStringXXX to check for WGL extensions. On both platforms I've used required extension was listed in wglGetGetExtensionsString output. As I see on GLX there is similar functionality provided by glXQueryExtensionsString. Which also aren't taken into account in PyOpenGL. So, my plan is firstly to fix gengl.py and later add method for platform-specific extensions check. But now I'm stuck with gengl.py doesn't produce the same _WGL_NV.py that is commited to bzr. Besides header file path in comments (which is minor issue), I see whitespaces differences and moreover, in myself-generated _WGL_NV.py there are no 'GLAPI' symbol. Could you say anything about that symbol? Was it added by hand or was it included in previous versions of wglext.h? Regards, Roman. |
From: Roman V. <red...@gm...> - 2013-10-29 19:48:24
|
Hello, Mike. Recently I've started to work on application that requires to dynamically control over vsync. This functionality is implemented via platform-specific GL calls. Particulary, on windows functions to control vsync called wglSwapIntervalEXT and wglGetSwapIntervalEXT. These functions can be imported from OpenGL.WGL, however they are actually unresolved. After further review I've found that all platform-specific functions are generated from C header files and calls mentioned above are declared in file _WGL_NV.py as: (I perform my tests on nvidia graphic card): wglSwapIntervalEXT = platform.createBaseFunction( 'wglSwapIntervalEXT', dll=platform.GL, resultType=BOOL, argTypes=[c_int], doc='wglSwapIntervalEXT( c_int(None) ) -> BOOL', argNames=['None'], ) wglGetSwapIntervalEXT = platform.createBaseFunction( 'wglGetSwapIntervalEXT', dll=platform.GL, resultType=c_int, argTypes=[], doc='wglGetSwapIntervalEXT( ) -> c_int', argNames=[], ) Actually, the issue could be fixed just by adding 'extension' parameter to the createBaseFunction arguments: wglSwapIntervalEXT = platform.createBaseFunction( 'wglSwapIntervalEXT', dll=platform.GL, resultType=BOOL, argTypes=[c_int], doc='wglSwapIntervalEXT( c_int(None) ) -> BOOL', argNames=['None'], extension='WGL_EXT_swap_control', ) wglGetSwapIntervalEXT = platform.createBaseFunction( 'wglGetSwapIntervalEXT', dll=platform.GL, resultType=c_int, argTypes=[], doc='wglGetSwapIntervalEXT( ) -> c_int', argNames=[], extension='WGL_EXT_swap_control', ) So, since wrapper files was originally generated by gengl.py script, I've tried to patch this script to fill extension parameter like original gengl.py from pyglet does. But as a result I've got only mentioned functions to be resolved with extension parameter. Thus, could these changes (adding extension parameter) added directly to the _WGL_NV.py without patching gengl.py? Regards, Roman. |
From: Mike C. F. <mcf...@vr...> - 2013-09-05 13:03:41
|
On 13-09-04 08:05 PM, Tim Sheerman-Chase wrote: ... > > That seems sensible to me. However, I am still having problems with the > current trunk version #623 when using glReadPixels in the previously > described situation. I did a quick hack to try to fix it but I am unsure > if this does not break something else. > https://code.launchpad.net/~thetourist/pyopengl/tim2 > > My code breaks if the ctypes pointer created by ctypes.c_void_p is > passed through arrayType.voidDataPointer. I have skipped this step. I am > a little unclear as to what what would be returned in each of the cases > and it might be worth checking. Ah, the problems of fixing code without a test case to run :D . You are correct, the voidDataPointer call should only be happening in cases where the data is *not* a c_void_p, the whole point of that being to create a c_void_p out of an array data type. Merged, thanks, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Tim Sheerman-C. <ord...@sh...> - 2013-09-05 00:05:55
|
On 04/09/13 22:05, pyo...@li... wrote: > On 13-09-02 01:59 PM, Tim Sheerman-Chase wrote: >> >Hi all, >> > >> >I had problems when using glReadPixels when the data buffer pointer >> >passed to the function is zero: >> > >> >glReadPixels(0, 0, capSize[0], capSize[1], GL_BGRA, GL_UNSIGNED_BYTE, 0) > Hi Tim, > > I've merged your patch into bzr head, though with some modifications, as > "if array != 0:" will trigger "cannot determine the scalar value of an > array" errors when array is a numpy array (it creates a boolean array of > size of array then attempts to determine whether array is True/False and > blows up). > That seems sensible to me. However, I am still having problems with the current trunk version #623 when using glReadPixels in the previously described situation. I did a quick hack to try to fix it but I am unsure if this does not break something else. https://code.launchpad.net/~thetourist/pyopengl/tim2 My code breaks if the ctypes pointer created by ctypes.c_void_p is passed through arrayType.voidDataPointer. I have skipped this step. I am a little unclear as to what what would be returned in each of the cases and it might be worth checking. Thanks, Tim |
From: Mike C. F. <mcf...@vr...> - 2013-09-04 21:05:15
|
On 13-09-02 01:59 PM, Tim Sheerman-Chase wrote: > Hi all, > > I had problems when using glReadPixels when the data buffer pointer > passed to the function is zero: > > glReadPixels(0, 0, capSize[0], capSize[1], GL_BGRA, GL_UNSIGNED_BYTE, 0) Hi Tim, I've merged your patch into bzr head, though with some modifications, as "if array != 0:" will trigger "cannot determine the scalar value of an array" errors when array is a numpy array (it creates a boolean array of size of array then attempts to determine whether array is True/False and blows up). With the modified code *any* integer/long passed in will be converted to a ctypes.c_void_p( value ). I believe that should be fine for all normal use cases of the function. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Tim Sheerman-C. <ord...@sh...> - 2013-09-02 18:54:22
|
Hi all, I had problems when using glReadPixels when the data buffer pointer passed to the function is zero: glReadPixels(0, 0, capSize[0], capSize[1], GL_BGRA, GL_UNSIGNED_BYTE, 0) I was doing this while reading from a pixel buffer object. This caused a segmentation fault in OpenGL/GL/images.py when simple.glReadPixels is called. I found a way to fix this by setting the variable to ensure it is a "None" pointer. if array is None: array = images.SetupPixelRead( format, (width,height), type ) else: if array != 0: array = arrayType.asArray( array ) else: array = arrayType.asArray( None ) imageData = arrayType.voidDataPointer( array ) simple.glReadPixels( x,y, width, height, format,type, imageData This branch fixes the segfault problem: https://code.launchpad.net/~thetourist/pyopengl/tim Regards, Tim Sheerman-Chase |
From: Mike C. F. <mcf...@vr...> - 2013-07-25 02:49:40
|
On 13-07-24 01:28 AM, Almar Klein wrote: > It uses "long", which is not available in py3k. > > GL/VERSION/GL_1_5.py, line 77 > > I propose to use "integer_types" as in six.py: > > if sys.version_info[0] >= 3: > integer_types = int, > else: > integer_types = int, long Thanks for the heads-up. I've made the change to use integer_types throughout the codebase in bzr. Enjoy, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Almar K. <alm...@gm...> - 2013-07-24 05:28:11
|
It uses "long", which is not available in py3k. GL/VERSION/GL_1_5.py, line 77 I propose to use "integer_types" as in six.py: if sys.version_info[0] >= 3: integer_types = int, else: integer_types = int, long Regards, Almar |
From: Matt W. <li...@mi...> - 2013-07-11 10:24:18
|
On 11 July 2013 05:43, Mike C. Fletcher <mcf...@vr...> wrote: > Hi all, > > I seriously doubt this will affect anyone, but just a heads-up that I'm > planning to remove Numeric array support from PyOpenGL and > OpenGLContext. Note, *numpy* support will remain, this is the > incredibly ancient long-since-deprecated Numeric module that no-one has > used for ages and ages (and I doubt it's even compatible with modern > Pythons, for that matter). The only reason to remove it is to reduce > the amount of maintenance and streamline some code paths. Sounds like a good idea to me. Anything that can make maintainence easier has got to be a good thing. Matt |
From: Mike C. F. <mcf...@vr...> - 2013-07-11 04:43:52
|
Hi all, I seriously doubt this will affect anyone, but just a heads-up that I'm planning to remove Numeric array support from PyOpenGL and OpenGLContext. Note, *numpy* support will remain, this is the incredibly ancient long-since-deprecated Numeric module that no-one has used for ages and ages (and I doubt it's even compatible with modern Pythons, for that matter). The only reason to remove it is to reduce the amount of maintenance and streamline some code paths. Enjoy, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Tcll <tcl...@gm...> - 2013-07-05 12:34:34
|
if the solution is a simple fix involving platform, please let me know. :) On 7/5/13, Tcll <tcl...@gm...> wrote: > well, like I said, I've managed to fix this issue, but ran directly > into another one... > > the error: > file - .../OpenGL/raw/GL/__init__.py > line - 152 > code - glCallLists = platform.createBaseFunction( > info - supplied inputs > > the problem: > unable to cast objects of type 'IronPython.Runtime.Types.PythonType' > to type 'INativeType' > > this is actually an IPy issue, but I'm contacting you about it for 2 > reasons: > - you may be able to implament a workaround (since the release I have > is their latest and last) > - I can't report it to them using their issue tracker... I'm on wii > > > I'm still researching the issue for other possible fixes rather than > adding new support to GL. > (there's most likely a chain that needs to be worked with) > > > the fix to the last issue was to simply use gle32.dll instead of vc9. > > I've removed the vc9 check from .../platform/win32.py since ctypes (Py > or IPy) seems to have a problem working with it. > |
From: Tcll <tcl...@gm...> - 2013-07-05 12:31:18
|
well, like I said, I've managed to fix this issue, but ran directly into another one... the error: file - .../OpenGL/raw/GL/__init__.py line - 152 code - glCallLists = platform.createBaseFunction( info - supplied inputs the problem: unable to cast objects of type 'IronPython.Runtime.Types.PythonType' to type 'INativeType' this is actually an IPy issue, but I'm contacting you about it for 2 reasons: - you may be able to implament a workaround (since the release I have is their latest and last) - I can't report it to them using their issue tracker... I'm on wii I'm still researching the issue for other possible fixes rather than adding new support to GL. (there's most likely a chain that needs to be worked with) the fix to the last issue was to simply use gle32.dll instead of vc9. I've removed the vc9 check from .../platform/win32.py since ctypes (Py or IPy) seems to have a problem working with it. |
From: Tcll <tcl...@gm...> - 2013-07-05 02:56:56
|
you know you guys are REALLY hard to report a bug to. XD in any case, as the error states, I'm having quite a runtime issue here... file: opengle32.vc9.dll I've had an issue before with python 2.7.2 and another library that used GLE... I've found a work-around though and ignored the issue... now I'm using the same src with IronPython 2.7.3 and am getting the same error... just to confirm that the src worked I've only just switched about an hour ago from running a dev on python 2.7.5 w/o changing a thing. with 2.7.5 (or just python in general) I've never used GLE sinced the last time I had the issue. but now IronPython seems to use it by default and is causing quite a hastle... the traceback: OSError: IronPython. ... .OSException: cannot load library C:\...\DLLS\opengle32.vc9.dll (only typing out the important parts (I'm on wii, compy can't connect yet)) yes, I placed it in the DLLS directory because this IPy is portable. but it makes no difference if placed in the system32 directory. OS: -- WinXP (Black), SP3, .NET 4.5E machine: CPU: intel celeron x86 (single core) 2.6GHz extra notes: I've tried 2 copies of the vc9.dll: - obtained from a GCode project - obtained from SharpDevelop which also includes it's own IPy both of which have their own PyOpenGL with the included dll I hope I've provided enough info, and I hope a decent report can be made as to who's ill-support problem it is. :P I will continue to try other methods to get this thing working. |
From: Max M. <max...@gm...> - 2013-05-31 09:22:32
|
2013/5/30 Mike C. Fletcher <mcf...@vr...> > On 13-05-28 03:45 PM, Max Mustermann wrote: > > Hi there, > > I'm new to PyOpenGL. It seems as if there are some functions related > > to direct_state_access's vertex arrays missing, for example > > glVertexArrayVertexAttribOffsetEXT. Or did I miss something? > The entry points don't exist in the official/canonical glext.h file. > The glhpp library maintains a header with the declarations, so I've > added that header to the PyOpenGL generation process. That should > produce the entry points that glhpp has identified as missing (including > this one). Current bzr head has the modification and the generated > wrappers with the entry points, if you would like to test it. > > HTH, > Mike > Great, thank you. The functions are available now. Sadly I've no working use case yet, I could check them working. The code in the repository somehow contains the functions in http://bazaar.launchpad.net/~mcfletch/pyopengl/trunk/view/head:/OpenGL/raw/GL/NV/draw_texture.py (last change rev. 574) instead of http://bazaar.launchpad.net/~mcfletch/pyopengl/trunk/view/head:/OpenGL/raw/GL/EXT/direct_state_access.py (last change rev. 572). But my local rebuild placed them correctly in direct_state_access.py. There are still some more unavailable functions in the extension that were introduced as aliases due to some of OpenGL 3.0's new naming conventions ("Indexed" -> "i"): {'glEnableClientStateiEXT', 'glGetDoublei_vEXT', 'glGetPointeri_vEXT', 'glGetFloati_vEXT', 'glDisableClientStateiEXT'} (those definitely and at least those, as only checked for those in the specs after comparison to the file resulting from my butterfly-effect hack replacing glext.h with glew.h). Regards, thank you |
From: Mike C. F. <mcf...@vr...> - 2013-05-30 19:09:21
|
On 13-05-28 03:45 PM, Max Mustermann wrote: > Hi there, > I'm new to PyOpenGL. It seems as if there are some functions related > to direct_state_access's vertex arrays missing, for example > glVertexArrayVertexAttribOffsetEXT. Or did I miss something? The entry points don't exist in the official/canonical glext.h file. The glhpp library maintains a header with the declarations, so I've added that header to the PyOpenGL generation process. That should produce the entry points that glhpp has identified as missing (including this one). Current bzr head has the modification and the generated wrappers with the entry points, if you would like to test it. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Max M. <max...@gm...> - 2013-05-28 19:45:18
|
Hi there, I'm new to PyOpenGL. It seems as if there are some functions related to direct_state_access's vertex arrays missing, for example glVertexArrayVertexAttribOffsetEXT. Or did I miss something? Thank you, regards maxmstrmnn |
From: Kang Z. <zha...@gm...> - 2013-05-24 01:13:38
|
Hello PyOpenGL developers, Thanks for your great work in developing pyOpenGL. I love it a lot. I have some questions regarding to pyOpenGL 3.0.2: 1. PyInstaller seems not working with pyOpenGL 3.0.2, but works fine with pyOpenGL 3.0.1b. I got this information from below discussion and I also confirmed this by my own tests (PS, 3.0.1 doesn't work either). http://stackoverflow.com/questions/11011373/pyopengl-exe-made-with-pyinstaller-gives-attributeerror My question is: are we going to do anything to fix this in pyOpenGL or shall we let PyInstaller team worry about it? 2. Is there any reason pyOpenGL 3.0.2 files are not available for downloading on sourceforge, but available on Python website? https://pypi.python.org/pypi/PyOpenGL/3.0.2 3. There is some internet restriction (not sure from the stupid China govenment or sourceforge), which makes users from China not able to access URLs starting with 'pyopengl.sourceforge.net' (e.g. pyopengl.sourceforge.net/documentation), but I can access URLs like ' http://sourceforge.net/projects/pyopengl/files/'. Is it possible to put the pyOpenGL documents somewhere else on internet (e.g. https://pypi.python.org/pypi/PyOpenGL/), so that people in China could workaround such internet reistrictions. I believe that would be a great help for pyOpenGL users in China. Thanks a lot in advance. Kang |
From: SourceForge.net <no...@so...> - 2013-04-26 03:00:43
|
Bugs item #3611878, was opened at 2013-04-25 19:50 Message generated for change (Comment added) made by xwize You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3611878&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: xwize (xwize) Assigned to: Mike C. Fletcher (mcfletch) Summary: compileProgram validates against opengl state Initial Comment: The compileProgram function calls check_validate on the newly linked program object which can lead to a situation where validation fails due to an incompatible gl state, yet there are no errors reported in either compiling or linking. Validation should only be performed before *using* the shader program - so as to check whether or not the shader will execute correctly with the current opengl state and not to be used as an indication of compilation success. If validation fails due to an incompatible state, but shader compilation and linking succeeds, it causes a catch-22 because the function throws an error and you can't change the state if you aren't returned the linked program. ---------------------------------------------------------------------- >Comment By: xwize (xwize) Date: 2013-04-25 20:00 Message: "RuntimeError: Validation failure (0): Validation failed! - Different sampler types for same sample texture unit in fragment shader." <- Validation can fail despite there being nothing wrong with shader compilation or linking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3611878&group_id=5988 |
From: SourceForge.net <no...@so...> - 2013-04-26 02:50:40
|
Bugs item #3611878, was opened at 2013-04-25 19:50 Message generated for change (Tracker Item Submitted) made by xwize You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3611878&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: xwize (xwize) Assigned to: Mike C. Fletcher (mcfletch) Summary: compileProgram validates against opengl state Initial Comment: The compileProgram function calls check_validate on the newly linked program object which can lead to a situation where validation fails due to an incompatible gl state, yet there are no errors reported in either compiling or linking. Validation should only be performed before *using* the shader program - so as to check whether or not the shader will execute correctly with the current opengl state and not to be used as an indication of compilation success. If validation fails due to an incompatible state, but shader compilation and linking succeeds, it causes a catch-22 because the function throws an error and you can't change the state if you aren't returned the linked program. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3611878&group_id=5988 |
From: SourceForge.net <no...@so...> - 2013-04-12 03:13:34
|
Bugs item #3526361, was opened at 2012-05-13 11:38 Message generated for change (Comment added) made by balintseeber You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3526361&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: GL.glGenLists not returning int on OSX 64 bit Initial Comment: I'm using py27-opengl 3.0.1_0 and py27-opengl-accelerate 3.0.1_0 on MacOS 10.7.3 64 bit via macports. I'm also using wxWidgets-devel 2.9.3_0+sdl if that's relevant. I've installed the wxgui component of gnuradio and am getting the following error when I try and use an openGL widget: Traceback (most recent call last): File "/opt/local/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py", line 187, in _on_paint for fcn in self._draw_fcns: fcn[1]() File "/opt/local/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py", line 58, in draw GL.glNewList(self._grid_compiled_list_id, GL.GL_COMPILE) ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type The code is at http://pastebin.com/ezLmgYv2 Please make sure GL.glGenLists is returning what you expect it to return (namely an unsigned int). On some platforms I've seen PyOpenGL bindings not returning the generated value but rather expecting to assign it to the second parameter in a similar fashion than that of the C API. Hope this helps! Alejandro.- Hi Alejandro, self._grid_compiled_list_id = GL.glGenLists(1) print self._grid_compiled_list_id returns 'None' ---------------------------------------------------------------------- Comment By: Balint Seeber (balintseeber) Date: 2013-04-11 20:13 Message: I found an issue with the (lack of) implicit OpenGL context in gr-wxgui's plotter_base. This bug has been fixed here: https://github.com/balint256/gnuradio/commit/5f0aaf3d5397675d6f87acd7ab20526ac1fb0d4e ---------------------------------------------------------------------- Comment By: Boolean (b001ean) Date: 2013-03-28 09:23 Message: I am running a 32 bit OS (Leopard 10.5.8) and I have this exact same problem, so it is not a 64 bit only issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3526361&group_id=5988 |
From: SourceForge.net <no...@so...> - 2013-03-28 16:23:29
|
Bugs item #3526361, was opened at 2012-05-13 11:38 Message generated for change (Comment added) made by b001ean You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3526361&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: GL.glGenLists not returning int on OSX 64 bit Initial Comment: I'm using py27-opengl 3.0.1_0 and py27-opengl-accelerate 3.0.1_0 on MacOS 10.7.3 64 bit via macports. I'm also using wxWidgets-devel 2.9.3_0+sdl if that's relevant. I've installed the wxgui component of gnuradio and am getting the following error when I try and use an openGL widget: Traceback (most recent call last): File "/opt/local/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py", line 187, in _on_paint for fcn in self._draw_fcns: fcn[1]() File "/opt/local/lib/python2.7/site-packages/gnuradio/wxgui/plotter/plotter_base.py", line 58, in draw GL.glNewList(self._grid_compiled_list_id, GL.GL_COMPILE) ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type The code is at http://pastebin.com/ezLmgYv2 Please make sure GL.glGenLists is returning what you expect it to return (namely an unsigned int). On some platforms I've seen PyOpenGL bindings not returning the generated value but rather expecting to assign it to the second parameter in a similar fashion than that of the C API. Hope this helps! Alejandro.- Hi Alejandro, self._grid_compiled_list_id = GL.glGenLists(1) print self._grid_compiled_list_id returns 'None' ---------------------------------------------------------------------- Comment By: Boolean (b001ean) Date: 2013-03-28 09:23 Message: I am running a 32 bit OS (Leopard 10.5.8) and I have this exact same problem, so it is not a 64 bit only issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3526361&group_id=5988 |