pyopengl-devel Mailing List for PyOpenGL (Page 7)
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: Mike C. F. <mcf...@vr...> - 2011-06-20 12:48:45
|
On 11-06-18 06:01 AM, Przemysław Lib wrote: >> In *theory* all the entry points are >> there, but I expect there will be broken wrappers somewhere. > Unfortunately, not all functions are declared in extensions. (checked > that in gl3.h, and others). > So there is need to parse at least also gl3.h and gl3ext.h, to get full OGL 4.1. > > I'll have some free time in near future so ill play a bit. > > I'm writing to both mailing-lists but in future ill write only to devel list. Hmm, surprised about that; but it would certainly be possible, I only do spot checks, I don't review everything that is generated. If we are seeing missing entry points we may want to consider using the gl.spec file to do the generation, or potentially going back to re-investigate sharing the pyglet generator code. Currently the pyglet generator I have seems out-of-date enough not to be able to parse my Maverick machine's gl.h, but in theory it should be able to parse almost any header and generate wrappers. IIRC back when it was able to parse the files it was only failing due to some fairly subtle errors wrt pointer and array types. The gl.spec file should, in theory, always be up to date and include all entry points and constants, as it is the place where new entry points/constants should be registered. It is not as "C-friendly" as the header files, but it is, I believe, what the headers are generated from. The current generator is very sensitive to the format of the generated .h files, so likely won't easily parse other header files. I'll probably be working on PyOpenGL or OpenGLContext development tomorrow (Monday), and will hang out in #pyopengl on freenode. I may try to get the pyglet generator or a spec-based generator working to cover the missing entry points. I'd like to get 4.x support in before releasing 3.0.2b1, hopefully sometime in early July. Have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: SourceForge.net <no...@so...> - 2011-06-20 08:37:24
|
Bugs item #2946226, was opened at 2010-02-04 22:59 Message generated for change (Comment added) made by nobody 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: Nobody/Anonymous (nobody) Date: 2011-06-20 08:37 Message: i0JeBJ <a href="http://omuvzagdafpf.com/">omuvzagdafpf</a>, [url=http://jhknieunhttm.com/]jhknieunhttm[/url], [link=http://fxcswseceghi.com/]fxcswseceghi[/link], http://wlllhxwwowdl.com/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-06-06 11:10 Message: LTt2UF <a href="http://qliwugxokplr.com/">qliwugxokplr</a>, [url=http://qprrkrlnsobz.com/]qprrkrlnsobz[/url], [link=http://aglhzqhucanw.com/]aglhzqhucanw[/link], http://tdserxexphjv.com/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-04-07 19:12 Message: GoBq28 <a href="http://xgzlmfcoichk.com/">xgzlmfcoichk</a>, [url=http://bulkmyoywvrs.com/]bulkmyoywvrs[/url], [link=http://hxztksvkrior.com/]hxztksvkrior[/link], http://cfnlymbmybna.com/ ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 19: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...> - 2011-06-20 06:23:20
|
Bugs item #3081957, was opened at 2010-10-06 09:11 Message generated for change (Comment added) made by przemoli You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLUT Group: OpenGLContext v2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Mike C. Fletcher (mcfletch) Summary: OpenGL.error.NullFunctionError: Attempt to call an undefined Initial Comment: Trying to run this simple example here: http://blog.vrplumber.com/index.php?/archives/2324-Sphere-rendering-with-numpy....html I get: C:\Users\Greg\Downloads>shader_sphere.py WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler accelerator from OpenGL_accelerate WARNING:context:Python Image Library (PIL) not installed, no Image support available http://www.pythonware.com/products/pil/index.htm WARNING:context:Unable to load node implementation for MMImageTexture: 'module' object has no attribute 'MMImageTexture' Traceback (most recent call last): File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module> TestContext.ContextMainLoop() File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 154, in ContextMainLoop render = cls( *args, **named) File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 30, in __init__ glutInitDisplayMode( self.DISPLAYMODE ) File "C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py", line 340, in __call__ self.__name__, self.__name__, OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling ---------------------------------------------------------------------- Comment By: Przemysaw Lib (przemoli) Date: 2011-06-20 08:23 Message: Oh, and check if you have glu32.dll in Windows/SysWOW64 (if not copy it from Windows/System32), it can help (as i 64bit system there are too folders for libs, and sometimes Win do not care to check them both) ---------------------------------------------------------------------- Comment By: Przemysaw Lib (przemoli) Date: 2011-06-20 07:57 Message: Hi! This source code do not import GLUT! http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/annotate/head%3A/tests/shader_sphere.py Do you add: from OpenGL.GLUT import * in your code? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-06-19 23:17 Message: 7mcw9D <a href="http://dxgzfsgwjqfn.com/">dxgzfsgwjqfn</a>, [url=http://fcfughgxpein.com/]fcfughgxpein[/url], [link=http://ccipjepamzzz.com/]ccipjepamzzz[/link], http://apaokgbvwuyu.com/ ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-10-18 14:57 Message: Then you will need a 64-bit build of GLUT, I'm guessing. FreeGLUT or GLUT32 should work. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-10-18 11:31 Message: This is Windows 7 x64 with 64-bit Python. The PyOpenGL installer does not work with 64 bit Python (no installers do. see: http://bugs.python.org/issue6792 ) Instead I did: easy_install pyopengl ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-10-18 11:27 Message: You are missing GLUT, though why I can't say, as it is supposed to be installed with PyOpenGL in the windows installer. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-10-06 09:13 Message: I installed PIL, but I still get: C:\Users\Greg\Downloads>shader_sphere.py WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler accelerator from OpenGL_accelerate Traceback (most recent call last): File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module> TestContext.ContextMainLoop() File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 154, in ContextMainLoop render = cls( *args, **named) File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 30, in __init__ glutInitDisplayMode( self.DISPLAYMODE ) File "C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py", line 340, in __call__ self.__name__, self.__name__, OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-06-20 05:57:57
|
Bugs item #3081957, was opened at 2010-10-06 09:11 Message generated for change (Comment added) made by przemoli You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLUT Group: OpenGLContext v2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Mike C. Fletcher (mcfletch) Summary: OpenGL.error.NullFunctionError: Attempt to call an undefined Initial Comment: Trying to run this simple example here: http://blog.vrplumber.com/index.php?/archives/2324-Sphere-rendering-with-numpy....html I get: C:\Users\Greg\Downloads>shader_sphere.py WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler accelerator from OpenGL_accelerate WARNING:context:Python Image Library (PIL) not installed, no Image support available http://www.pythonware.com/products/pil/index.htm WARNING:context:Unable to load node implementation for MMImageTexture: 'module' object has no attribute 'MMImageTexture' Traceback (most recent call last): File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module> TestContext.ContextMainLoop() File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 154, in ContextMainLoop render = cls( *args, **named) File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 30, in __init__ glutInitDisplayMode( self.DISPLAYMODE ) File "C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py", line 340, in __call__ self.__name__, self.__name__, OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling ---------------------------------------------------------------------- Comment By: Przemysaw Lib (przemoli) Date: 2011-06-20 07:57 Message: Hi! This source code do not import GLUT! http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/annotate/head%3A/tests/shader_sphere.py Do you add: from OpenGL.GLUT import * in your code? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-06-19 23:17 Message: 7mcw9D <a href="http://dxgzfsgwjqfn.com/">dxgzfsgwjqfn</a>, [url=http://fcfughgxpein.com/]fcfughgxpein[/url], [link=http://ccipjepamzzz.com/]ccipjepamzzz[/link], http://apaokgbvwuyu.com/ ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-10-18 14:57 Message: Then you will need a 64-bit build of GLUT, I'm guessing. FreeGLUT or GLUT32 should work. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-10-18 11:31 Message: This is Windows 7 x64 with 64-bit Python. The PyOpenGL installer does not work with 64 bit Python (no installers do. see: http://bugs.python.org/issue6792 ) Instead I did: easy_install pyopengl ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-10-18 11:27 Message: You are missing GLUT, though why I can't say, as it is supposed to be installed with PyOpenGL in the windows installer. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-10-06 09:13 Message: I installed PIL, but I still get: C:\Users\Greg\Downloads>shader_sphere.py WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler accelerator from OpenGL_accelerate Traceback (most recent call last): File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module> TestContext.ContextMainLoop() File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 154, in ContextMainLoop render = cls( *args, **named) File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 30, in __init__ glutInitDisplayMode( self.DISPLAYMODE ) File "C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py", line 340, in __call__ self.__name__, self.__name__, OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-06-19 21:17:06
|
Bugs item #3081957, was opened at 2010-10-06 07:11 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLUT Group: OpenGLContext v2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Mike C. Fletcher (mcfletch) Summary: OpenGL.error.NullFunctionError: Attempt to call an undefined Initial Comment: Trying to run this simple example here: http://blog.vrplumber.com/index.php?/archives/2324-Sphere-rendering-with-numpy....html I get: C:\Users\Greg\Downloads>shader_sphere.py WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler accelerator from OpenGL_accelerate WARNING:context:Python Image Library (PIL) not installed, no Image support available http://www.pythonware.com/products/pil/index.htm WARNING:context:Unable to load node implementation for MMImageTexture: 'module' object has no attribute 'MMImageTexture' Traceback (most recent call last): File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module> TestContext.ContextMainLoop() File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 154, in ContextMainLoop render = cls( *args, **named) File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 30, in __init__ glutInitDisplayMode( self.DISPLAYMODE ) File "C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py", line 340, in __call__ self.__name__, self.__name__, OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-06-19 21:17 Message: 7mcw9D <a href="http://dxgzfsgwjqfn.com/">dxgzfsgwjqfn</a>, [url=http://fcfughgxpein.com/]fcfughgxpein[/url], [link=http://ccipjepamzzz.com/]ccipjepamzzz[/link], http://apaokgbvwuyu.com/ ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-10-18 12:57 Message: Then you will need a 64-bit build of GLUT, I'm guessing. FreeGLUT or GLUT32 should work. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-10-18 09:31 Message: This is Windows 7 x64 with 64-bit Python. The PyOpenGL installer does not work with 64 bit Python (no installers do. see: http://bugs.python.org/issue6792 ) Instead I did: easy_install pyopengl ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-10-18 09:27 Message: You are missing GLUT, though why I can't say, as it is supposed to be installed with PyOpenGL in the windows installer. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-10-06 07:13 Message: I installed PIL, but I still get: C:\Users\Greg\Downloads>shader_sphere.py WARNING:OpenGL.arrays.numpymodule:Unable to load numpy_formathandler accelerator from OpenGL_accelerate Traceback (most recent call last): File "C:\Users\Greg\Downloads\shader_sphere.py", line 116, in <module> TestContext.ContextMainLoop() File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 154, in ContextMainLoop render = cls( *args, **named) File "C:\Python27\lib\site-packages\openglcontext-2.1.0a11-py2.7.egg\OpenGLContext\glutcontext.py", line 30, in __init__ glutInitDisplayMode( self.DISPLAYMODE ) File "C:\Python27\lib\site-packages\pyopengl-3.0.1-py2.7.egg\OpenGL\platform\baseplatform.py", line 340, in __call__ self.__name__, self.__name__, OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3081957&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-06-16 14:40:54
|
Bugs item #2943244, was opened at 2010-01-31 15:16 Message generated for change (Comment added) made by nobody 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: Nobody/Anonymous (nobody) Date: 2011-06-16 14:40 Message: zmVDVG <a href="http://smwzxlxkmkhu.com/">smwzxlxkmkhu</a>, [url=http://bculerputyyq.com/]bculerputyyq[/url], [link=http://skoydrbjloib.com/]skoydrbjloib[/link], http://hufvpxgfcfgd.com/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-04-07 03:31 Message: Kq5Acn <a href="http://umbmjcuegdeh.com/">umbmjcuegdeh</a>, [url=http://iqquspbismqt.com/]iqquspbismqt[/url], [link=http://gryulfjfwfpj.com/]gryulfjfwfpj[/link], http://tmrtwczsqytf.com/ ---------------------------------------------------------------------- Comment By: Andrej Schoeke (aschoeke) Date: 2010-03-22 23:54 Message: Same problem on Mac OS X 10.5 with MacPorts. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 20: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 15: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...> - 2011-06-15 00:26:29
|
Patches item #3316500, was opened at 2011-06-14 23:56 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=3316500&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 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Pythonic wrapper for glGenVertexArray Initial Comment: I'd like to use glGenVertexArrays like glGenBuffers. Please add the following wrapper to GL/ARB/vertex_array_object.py glGenVertexArrays = wrapper.wrapper( glGenVertexArrays ).setOutput( 'buffers', lambda n: (n,), 'n', ) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-06-15 00:26 Message: Sorry, I've made a mistake. The correct wrapper is here: glGenVertexArrays = wrapper.wrapper( glGenVertexArrays ).setOutput( 'arrays', lambda n: (n,), 'n', ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=3316500&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-06-14 23:56:51
|
Patches item #3316500, was opened at 2011-06-14 23:56 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=3316500&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 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Pythonic wrapper for glGenVertexArray Initial Comment: I'd like to use glGenVertexArrays like glGenBuffers. Please add the following wrapper to GL/ARB/vertex_array_object.py glGenVertexArrays = wrapper.wrapper( glGenVertexArrays ).setOutput( 'buffers', lambda n: (n,), 'n', ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=3316500&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-06-14 22:40:29
|
Bugs item #3316474, was opened at 2011-06-14 22:40 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3316474&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: glBegin, glColor*, etc. are not marked as deprecated. Initial Comment: I set "ONLY_FORWARD_COMPATIBLE = True", however many deprecated functions such as glBegin, glColor* were still loaded and able to be called. I think "src/generateraw.py" doesn't consider the OpenGL 3.1 deprecation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3316474&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-06-08 16:40:36
|
Bugs item #3313855, was opened at 2011-06-08 18:40 Message generated for change (Tracker Item Submitted) made by skrat2eee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3313855&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLU Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: skrat (skrat2eee) Assigned to: Mike C. Fletcher (mcfletch) Summary: Segmentation fault by gluNewTess Initial Comment: Calling gluNewTess causes segmentation fault, due to call to glGetError. GLU tesselator doesn't need any GL context at all, so glGetError causes segfault on some platforms (GNU/Linux), or is silently swallowed by others (Darwin). Test case: from OpenGL.GLU import gluNewTess tess = gluNewTess() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3313855&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-06-06 13:52:28
|
Bugs item #2872257, was opened at 2009-10-03 15:29 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2872257&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLUT Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (reirrac) Assigned to: Mike C. Fletcher (mcfletch) Summary: glutInit fails on windows 64-bit Initial Comment: On a 64-bit Windows 7 machine, GLUT fails on glutInit with the following traceback: Traceback (most recent call last): File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 287, in <module> visualizer.main() File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 233, in main glutInit(sys.argv) File "c:\Python26\Lib\site-packages\OpenGL\GLUT\special.py", line 322, in glutInit _base_glutInit( ctypes.byref(count), holder ) TypeError: 'NoneType' object is not callable I tried copying the glut and gle dll's to my c:\windows\system32\ directory but that didn't change anything. If I comment out the glutInit function, I get this: Traceback (most recent call last): File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 287, in <module> visualizer.main() File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 240, in main glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_ALPHA | GLUT_DEPTH) File "c:\Python26\Lib\site-packages\OpenGL\platform\baseplatform.py", line 336, in __call__ self.__name__, self.__name__, OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling I get the same error with any of the NeHe opengl lesson code. It works fine on my linux machine and my windows 32-bit machine, so I think it's something to do with windows 64-bit. Are there 64-bit versions of the glut and gle DLLs? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-06-06 13:52 Message: 7SwI1Z <a href="http://wapdljbblpji.com/">wapdljbblpji</a>, [url=http://peiyilrdvqdr.com/]peiyilrdvqdr[/url], [link=http://aaslyurencjo.com/]aaslyurencjo[/link], http://xcvfolcrnhji.com/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-04-07 14:32 Message: 530L0R <a href="http://pqfqsxbkqaxt.com/">pqfqsxbkqaxt</a>, [url=http://tbabnelmqqbw.com/]tbabnelmqqbw[/url], [link=http://cjxvuqkghtdd.com/]cjxvuqkghtdd[/link], http://czlwxnvoiuwm.com/ ---------------------------------------------------------------------- Comment By: Christoph Gohlke (cjgohlke) Date: 2009-11-13 05:55 Message: I had the same problem on Python 2.6.4 64-bit, PyOpenGL-3.0.1b1, Windows 7. Turned out there was a 32-bit glut32.dll file in the PATH, which was used instead of the correct 64-bit glut32.dll in Python26\Lib\site-packages\OpenGL\DLLS. Everything worked once I cleaned the PATH environment variable. You can download a 64-bit version of PyOpenGL for Windows at <http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyopengl> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2872257&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-06-06 11:10:18
|
Bugs item #2946226, was opened at 2010-02-04 22:59 Message generated for change (Comment added) made by nobody 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: Nobody/Anonymous (nobody) Date: 2011-06-06 11:10 Message: LTt2UF <a href="http://qliwugxokplr.com/">qliwugxokplr</a>, [url=http://qprrkrlnsobz.com/]qprrkrlnsobz[/url], [link=http://aglhzqhucanw.com/]aglhzqhucanw[/link], http://tdserxexphjv.com/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-04-07 19:12 Message: GoBq28 <a href="http://xgzlmfcoichk.com/">xgzlmfcoichk</a>, [url=http://bulkmyoywvrs.com/]bulkmyoywvrs[/url], [link=http://hxztksvkrior.com/]hxztksvkrior[/link], http://cfnlymbmybna.com/ ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 19: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...> - 2011-05-18 10:37:38
|
Bugs item #3127034, was opened at 2010-12-04 00:00 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3127034&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: VBO deletion happening in another thread than Main thread Initial Comment: Hi pyopengl dudes, I got a bug with VBO. It seem that the deletion of VBO (the one that involve glDeleteBuffers) is happening sometimes inside another thread than Main thread, and lead to a segfault. I've added a call to threading.currentThread() + traceback.print_stack() just before the call of glDeleteBuffers() in arrays/vbo.py. And normal case, i got: glDeleteBuffers() <_MainThread(MainThread, started 140737353901824)> + a traceback with last line very weird (like gc call...) And the segfault case: glDeleteBuffers() <Thread(Thread-6, started daemon 140736902752016)> Here is both traceback that look different : http://paste.pocoo.org/show/300045/ and http://paste.pocoo.org/show/300047/ It look like the callback of weakref.ref() is called when the object is deleted and finalized... but not in main thread. Do you confirm this case ? Do you have any tips about how to do ? I was thinking to use a Queue, and if the deletion happen outside the main thread, queuing the deletion for the next call. (tricky, but since pyopengl don't have clokc of callback from main thread...) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-05-18 10:37 Message: Tracker.. Bang-up :) ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-12-06 14:21 Message: ?? boggle ?? Okay, *that* is surprising. AFAIK the weakref code is just hooked into the DECREF counting so that iff count goes to < 1 then the weakrefs are called, then the __del__ method. I suppose somehow one of the callbacks might allow a thread context switch... but that still seems pretty exotic. Don't suppose you have a small test-case that shows this? ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2010-12-05 17:11 Message: Just to ensure you've understand me, i don't do any deletion of VBO in another thread than main thread. I've a reference to the VBO in a class, and when the class is gone, the vbo is gone too. All theses operations are always executed in a main thread. That's why i think this bug can happen as soon as you use thread in python no ? And that's problematic :/ ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-12-05 13:49 Message: The appropriate way to delete a VBO in a multi-threaded situation is to call .delete() on it in the rendering thread *before* you delete the VBO in another thread. The VBO's cleanup will then *not* delete the VBO. Anything I do to try to work around this will constrain the design of all pyopengl applications. That said, your approach would work fine (moving the deletions to the main thread) for your application: # non-render thread for obj in objs_to_delete: remove_from_tree(obj) to_delete_queue.push( obj ) # no garbage collection here because of this reference # render thread while: to_delete_queue: to_delete_queue.pop() # garbage collected and deleted here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3127034&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-05-17 23:50:48
|
Bugs item #3177110, was opened at 2011-02-10 06:21 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3177110&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: install Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eli Stevens (wickedgrey) Assigned to: Mike C. Fletcher (mcfletch) Summary: Windows python 2.7 installer includes dep. on msvcr71.dll Initial Comment: \Python27\Lib\site-packages\PyOpenGL-3.0.1-py2.7-win32.egg\OpenGL\DLLS\gle32.dll is trying to load msvcr71.dll instead of msvcr90.dll , which doesn't match python 2.7. This results in this when trying to import OpenGL.GL: Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import OpenGL.GL At that point, the following message appears in an alert box: python.exe - Unable To Locate Component This application has failed to start becuase MSVCR71.dll was not found. Re-installing the application may fix this problem. The same behavior occurs when trying to import OpenGL.GL from inside our application, however, aside from the alert box, the application seems to run fine (we're able to use OpenGL just fine, see 3d stuff, shaders, etc. etc.). It seems like either the egg for python 2.7 should either include the msvcr71.dll, or should only try to reference msvcr90.dll (since that's what python 2.7 uses). Original mailing list thread here: http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTimctcemkdkY4U4JyX9EibLj01ERgNhBXPbrC-Rq%40mail.gmail.com&forum_name=pyopengl-users ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-05-17 23:50 Message: 5TlgFE <a href="http://fabhqvsgqnph.com/">fabhqvsgqnph</a>, [url=http://flqzkjzsdjjq.com/]flqzkjzsdjjq[/url], [link=http://ebqwnfcgxcrj.com/]ebqwnfcgxcrj[/link], http://eeaamyeagspd.com/ ---------------------------------------------------------------------- Comment By: Christoph Gohlke (cjgohlke) Date: 2011-02-15 22:35 Message: gle32.dll, included in the PyOpenGL installers for Python 2.6 and 2.7 at <http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyopengl>, is linked against msvcr90.dll. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3177110&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-05-14 18:33:45
|
Bugs item #3287895, was opened at 2011-04-15 17:20 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3287895&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: Tk Group: v3.0.0 Status: Open Resolution: None Priority: 1 Private: No Submitted By: Nikolay Vladimirov (nvloff) Assigned to: Nobody/Anonymous (nobody) Summary: Remove shebang from Tk module Initial Comment: OpenGL/Tk/__init__.py has: #!/usr/bin/env python As PyOpenGL went trough Fedora package review ( https://bugzilla.redhat.com/show_bug.cgi?id=234121 ) it was noted that python modules should not be executable and have shebang at the begining. Currently a patch is present in the Fedora package that removes this and it will be great if we can dump the patch. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2011-05-14 14:33 Message: Have removed the shebang line in this module from bzr head. Fedora might want to review policy, however, as it is quite possible for modules to be executable intentionally. Often the executable module is a demo or tool for the functionality in the module. Later packages tend toward using setuptools or python -m for that functionality, but certainly lots of older modules follow that pattern. This module (Tk) was, I believe, at some point, following that pattern, but the demo was moved into the PyOpenGL-Demo package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3287895&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-04-15 21:20:50
|
Bugs item #3287895, was opened at 2011-04-16 00:20 Message generated for change (Settings changed) made by nvloff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3287895&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: Tk >Group: v3.0.0 Status: Open Resolution: None >Priority: 1 Private: No Submitted By: Nikolay Vladimirov (nvloff) Assigned to: Nobody/Anonymous (nobody) Summary: Remove shebang from Tk module Initial Comment: OpenGL/Tk/__init__.py has: #!/usr/bin/env python As PyOpenGL went trough Fedora package review ( https://bugzilla.redhat.com/show_bug.cgi?id=234121 ) it was noted that python modules should not be executable and have shebang at the begining. Currently a patch is present in the Fedora package that removes this and it will be great if we can dump the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3287895&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-04-15 21:20:13
|
Bugs item #3287895, was opened at 2011-04-16 00:20 Message generated for change (Tracker Item Submitted) made by nvloff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3287895&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: Nikolay Vladimirov (nvloff) Assigned to: Nobody/Anonymous (nobody) Summary: Remove shebang from Tk module Initial Comment: OpenGL/Tk/__init__.py has: #!/usr/bin/env python As PyOpenGL went trough Fedora package review ( https://bugzilla.redhat.com/show_bug.cgi?id=234121 ) it was noted that python modules should not be executable and have shebang at the begining. Currently a patch is present in the Fedora package that removes this and it will be great if we can dump the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3287895&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-04-07 23:50:24
|
Bugs item #2817196, was opened at 2009-07-05 23:46 Message generated for change (Comment added) made by nobody 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: Nobody/Anonymous (nobody) Date: 2011-04-07 23:50 Message: cgFK92 <a href="http://ktjovexvelsv.com/">ktjovexvelsv</a>, [url=http://hobwtjhjlyli.com/]hobwtjhjlyli[/url], [link=http://ibenkudkyauv.com/]ibenkudkyauv[/link], http://iyzmwjwilkxy.com/ ---------------------------------------------------------------------- Comment By: bourriquet42 (bourriquet42) Date: 2010-10-08 12:20 Message: Is there anything new about this issue? ---------------------------------------------------------------------- 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...> - 2011-04-07 19:12:13
|
Bugs item #2946226, was opened at 2010-02-04 22:59 Message generated for change (Comment added) made by nobody 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: Nobody/Anonymous (nobody) Date: 2011-04-07 19:12 Message: GoBq28 <a href="http://xgzlmfcoichk.com/">xgzlmfcoichk</a>, [url=http://bulkmyoywvrs.com/]bulkmyoywvrs[/url], [link=http://hxztksvkrior.com/]hxztksvkrior[/link], http://cfnlymbmybna.com/ ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 19: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...> - 2011-04-07 14:32:56
|
Bugs item #2872257, was opened at 2009-10-03 15:29 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2872257&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLUT Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason G (reirrac) Assigned to: Mike C. Fletcher (mcfletch) Summary: glutInit fails on windows 64-bit Initial Comment: On a 64-bit Windows 7 machine, GLUT fails on glutInit with the following traceback: Traceback (most recent call last): File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 287, in <module> visualizer.main() File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 233, in main glutInit(sys.argv) File "c:\Python26\Lib\site-packages\OpenGL\GLUT\special.py", line 322, in glutInit _base_glutInit( ctypes.byref(count), holder ) TypeError: 'NoneType' object is not callable I tried copying the glut and gle dll's to my c:\windows\system32\ directory but that didn't change anything. If I comment out the glutInit function, I get this: Traceback (most recent call last): File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 287, in <module> visualizer.main() File "C:\Programming\NE\HyperNEAT\HyperNEAT_Visualizer\src\HyperNEATVisualizer.py", line 240, in main glutInitDisplayMode(GLUT_RGBA | GLUT_DOUBLE | GLUT_ALPHA | GLUT_DEPTH) File "c:\Python26\Lib\site-packages\OpenGL\platform\baseplatform.py", line 336, in __call__ self.__name__, self.__name__, OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInitDisplayMode, check for bool(glutInitDisplayMode) before calling I get the same error with any of the NeHe opengl lesson code. It works fine on my linux machine and my windows 32-bit machine, so I think it's something to do with windows 64-bit. Are there 64-bit versions of the glut and gle DLLs? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-04-07 14:32 Message: 530L0R <a href="http://pqfqsxbkqaxt.com/">pqfqsxbkqaxt</a>, [url=http://tbabnelmqqbw.com/]tbabnelmqqbw[/url], [link=http://cjxvuqkghtdd.com/]cjxvuqkghtdd[/link], http://czlwxnvoiuwm.com/ ---------------------------------------------------------------------- Comment By: Christoph Gohlke (cjgohlke) Date: 2009-11-13 05:55 Message: I had the same problem on Python 2.6.4 64-bit, PyOpenGL-3.0.1b1, Windows 7. Turned out there was a 32-bit glut32.dll file in the PATH, which was used instead of the correct 64-bit glut32.dll in Python26\Lib\site-packages\OpenGL\DLLS. Everything worked once I cleaned the PATH environment variable. You can download a 64-bit version of PyOpenGL for Windows at <http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyopengl> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=2872257&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-04-07 03:31:59
|
Bugs item #2943244, was opened at 2010-01-31 15:16 Message generated for change (Comment added) made by nobody 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: Nobody/Anonymous (nobody) Date: 2011-04-07 03:31 Message: Kq5Acn <a href="http://umbmjcuegdeh.com/">umbmjcuegdeh</a>, [url=http://iqquspbismqt.com/]iqquspbismqt[/url], [link=http://gryulfjfwfpj.com/]gryulfjfwfpj[/link], http://tmrtwczsqytf.com/ ---------------------------------------------------------------------- Comment By: Andrej Schoeke (aschoeke) Date: 2010-03-22 23:54 Message: Same problem on Mac OS X 10.5 with MacPorts. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2010-02-22 20: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 15: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...> - 2011-02-15 22:35:52
|
Bugs item #3177110, was opened at 2011-02-09 22:21 Message generated for change (Comment added) made by cjgohlke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3177110&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: install Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eli Stevens (wickedgrey) Assigned to: Mike C. Fletcher (mcfletch) Summary: Windows python 2.7 installer includes dep. on msvcr71.dll Initial Comment: \Python27\Lib\site-packages\PyOpenGL-3.0.1-py2.7-win32.egg\OpenGL\DLLS\gle32.dll is trying to load msvcr71.dll instead of msvcr90.dll , which doesn't match python 2.7. This results in this when trying to import OpenGL.GL: Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import OpenGL.GL At that point, the following message appears in an alert box: python.exe - Unable To Locate Component This application has failed to start becuase MSVCR71.dll was not found. Re-installing the application may fix this problem. The same behavior occurs when trying to import OpenGL.GL from inside our application, however, aside from the alert box, the application seems to run fine (we're able to use OpenGL just fine, see 3d stuff, shaders, etc. etc.). It seems like either the egg for python 2.7 should either include the msvcr71.dll, or should only try to reference msvcr90.dll (since that's what python 2.7 uses). Original mailing list thread here: http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTimctcemkdkY4U4JyX9EibLj01ERgNhBXPbrC-Rq%40mail.gmail.com&forum_name=pyopengl-users ---------------------------------------------------------------------- Comment By: Christoph Gohlke (cjgohlke) Date: 2011-02-15 14:35 Message: gle32.dll, included in the PyOpenGL installers for Python 2.6 and 2.7 at <http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyopengl>, is linked against msvcr90.dll. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3177110&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2011-02-10 06:21:12
|
Bugs item #3177110, was opened at 2011-02-10 00:21 Message generated for change (Tracker Item Submitted) made by wickedgrey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3177110&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: install Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eli Stevens (wickedgrey) Assigned to: Mike C. Fletcher (mcfletch) Summary: Windows python 2.7 installer includes dep. on msvcr71.dll Initial Comment: \Python27\Lib\site-packages\PyOpenGL-3.0.1-py2.7-win32.egg\OpenGL\DLLS\gle32.dll is trying to load msvcr71.dll instead of msvcr90.dll , which doesn't match python 2.7. This results in this when trying to import OpenGL.GL: Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import OpenGL.GL At that point, the following message appears in an alert box: python.exe - Unable To Locate Component This application has failed to start becuase MSVCR71.dll was not found. Re-installing the application may fix this problem. The same behavior occurs when trying to import OpenGL.GL from inside our application, however, aside from the alert box, the application seems to run fine (we're able to use OpenGL just fine, see 3d stuff, shaders, etc. etc.). It seems like either the egg for python 2.7 should either include the msvcr71.dll, or should only try to reference msvcr90.dll (since that's what python 2.7 uses). Original mailing list thread here: http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTimctcemkdkY4U4JyX9EibLj01ERgNhBXPbrC-Rq%40mail.gmail.com&forum_name=pyopengl-users ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=3177110&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2010-12-07 03:44:38
|
Patches item #3019625, was opened at 2010-06-22 09:51 Message generated for change (Settings changed) made by mcfletch 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: Closed >Resolution: Accepted 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. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2010-12-06 22:44 Message: Sorry this took so long to integrate. Should show up in the next release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=3019625&group_id=5988 |
|
From: Mike C. F. <mcf...@vr...> - 2010-12-07 03:20:13
|
On 10-12-02 08:45 AM, rndblnch wrote: ... > def dataPointer(value): > return ctypes.cast(ctypes.c_char_p(value), ctypes.c_void_p).value > I don't see any documentation on this for CPython, for PyPy this apparently is going to create a copy of the data in value? My quick test says on CPython it doesn't copy the data, so I've swapped it into the code. > PyBuffer_FromMemory can be implemented as (not tested though, since it's > only used in experimental code for vbos): > def PyBuffer_FromMemory(address, length): > return buffer((ctypes.c_char * length).from_address(address)) > I've updated to use that one as well. > the whole thread is there for reference: > <http://codespeak.net/pipermail/pypy-dev/2010q4/006452.html> > > > 2) the second issue (missing _CDada_intput) is from pypy. the good news is that > it has already been fixed by Amaury Forgeot d'Arc in the fast-forward branch > (aiming at cpython 2.7 compatibility). the patch (requires some adaptation to > apply on pypy-1.4) can be found there: > <http://codespeak.net/pipermail/pypy-svn/2010-November/045106.html> > Hmm, that branch doesn't build on my machine, so I can't test the changes. > so far, i have managed to partially run the programs of my small opengl > tutorial, i.e. a sample program that use most of the functionalities of the > fixed pipeline and that is evolved step by step into a shader based > implementation. what runs for the moment (with minor errors): > - 01-direct.py (direct rendering, some geometry + 3d texture) > - 02-displaylist.py > - 03-array.py (use of Vertex/.../NormalPointer) > - 04-vbo.py (idem + VBOs to pass the data) > what does not run: the rest that uses shaders, but i'm pretty confident it's a > minor issue (wrong types in glShaderSource arguments) > > the programs are based on pyopengl and can be found here: > <http://bitbucket.org/rndblnch/opengl-programmable/> > I'll try to find some time to play with them. Good luck, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
32 messages has been excluded from this view by a project administrator.
