Thread: [PyOpenGL-Users] Setting Up on New Machine
Brought to you by:
mcfletch
From: Ian M. <geo...@gm...> - 2012-02-02 15:45:30
|
Hi, I just got a new laptop (64 bit, Py2.6), and am going through the cursory install-everything phase. I'm having trouble with PyOpenGL. Standard OpenGL calls appear to be undefined. The following minimal example: from OpenGL.GL import * from OpenGL.GLU import * from OpenGL.GLUT import * import pygame from pygame.locals import * pygame.init() Screen = (640,480) pygame.display.set_mode(Screen,OPENGL|DOUBLEBUF) glEnable(GL_LIGHTING) . . . produces (after creating a window, and, therefore hopefully, a context): Traceback (most recent call last): File "C:\Users\Ian Mallett\Desktop\t.py", line 11, in <module> glEnable(GL_LIGHTING) File "C:\dev\Python26\lib\site-packages\pyopengl-3.0.2a3-py2.6.egg\OpenGL\platform\baseplatform.py", line 377, in __call__ self.__name__, self.__name__, NullFunctionError: Attempt to call an undefined function glEnable, check for bool(glEnable) before calling Help? Thanks, Ian |
From: Mike C. F. <mcf...@vr...> - 2012-02-02 16:47:02
|
On 12-02-02 10:45 AM, Ian Mallett wrote: > Hi, > > I just got a new laptop (64 bit, Py2.6), and am going through the > cursory install-everything phase. > > I'm having trouble with PyOpenGL. Standard OpenGL calls appear to be > undefined. The following minimal example: > > from OpenGL.GL import * > from OpenGL.GLU import * > from OpenGL.GLUT import * > import pygame > from pygame.locals import * > pygame.init() > > Screen = (640,480) > pygame.display.set_mode(Screen,OPENGL|DOUBLEBUF) > > glEnable(GL_LIGHTING) > > > . . . produces (after creating a window, and, therefore hopefully, a > context): > > Traceback (most recent call last): > File "C:\Users\Ian Mallett\Desktop\t.py", line 11, in <module> > glEnable(GL_LIGHTING) > File > "C:\dev\Python26\lib\site-packages\pyopengl-3.0.2a3-py2.6.egg\OpenGL\platform\baseplatform.py", > line 377, in __call__ > self.__name__, self.__name__, > NullFunctionError: Attempt to call an undefined function glEnable, > check for bool(glEnable) before calling > > Help? Thanks, > Ian That sounds like a failure in the platform module, that is, either it doesn't find the DLL, or finds the wrong DLL. The most likely cause there is the "64-bit" ness of the machine, as I don't have a 64-bit Windows machine on which to test/work... actually, scratch that, just realized that my server *did* come with a 64-bit Windows... just need to give up the server for an afternoon. My guess is that opengl32, glut32, glu32 are renamed to something like opengl64 or the like. Guess I should fire up Win64 and find out. OpenGL_accelerate is definitely going to be broken/MIA, as it requires compilation and I haven't done that for Win64 before. You could probably put a pdb call in platform/win32.py and figure it out before I get there (I'm going to have to pick up my son in a few minutes), but if not I'll try to get to it this afternoon. Thanks, Mike |
From: Mike C. F. <mcf...@vr...> - 2012-02-02 22:10:55
|
On 12-02-02 11:47 AM, Mike C. Fletcher wrote: > On 12-02-02 10:45 AM, Ian Mallett wrote: ... >> glEnable(GL_LIGHTING) >> >> >> . . . produces (after creating a window, and, therefore hopefully, a >> context): >> ... >> NullFunctionError: Attempt to call an undefined function glEnable, >> check for bool(glEnable) before calling >> >> Help? Thanks, >> Ian > That sounds like a failure in the platform module, that is, either it It was actually a failure in the refactoring done for the raw hierarchy auto-generation. It worked fine on OS-X and Linux, but failed on Windows, where there is a distinction between core and extension procedures. I'm still seeing a test failure in the GLU tessellation mechanism (on both Win64 and Linux64), but I've fixed a crashing problem there on Win64. I'll release another alpha in a few moments to pick up those fixes, but expect we'll need another fairly soon to pick up the tess fixes when I get them. Take care, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Ian M. <geo...@gm...> - 2012-02-03 06:30:51
|
Hi, On Thu, Feb 2, 2012 at 3:10 PM, Mike C. Fletcher <mcf...@vr...>wrote: > > That sounds like a failure in the platform module, that is, either it > It was actually a failure in the refactoring done for the raw hierarchy > auto-generation. It worked fine on OS-X and Linux, but failed on > Windows, where there is a distinction between core and extension > procedures. > > I'm still seeing a test failure in the GLU tessellation mechanism (on > both Win64 and Linux64), but I've fixed a crashing problem there on > Win64. I'll release another alpha in a few moments to pick up those > fixes, but expect we'll need another fairly soon to pick up the tess > fixes when I get them. > Where can I get current source/builds? I couldn't find anything recent on SourceForge. > Take care, > Mike Thanks! Ian |
From: Mike C. F. <mcf...@vr...> - 2012-02-03 18:09:23
|
On 12-02-03 01:30 AM, Ian Mallett wrote: > Hi, > On Thu, Feb 2, 2012 at 3:10 PM, Mike C. Fletcher > <mcf...@vr... <mailto:mcf...@vr...>> wrote: > > > That sounds like a failure in the platform module, that is, > either it > It was actually a failure in the refactoring done for the raw > hierarchy > auto-generation. It worked fine on OS-X and Linux, but failed on > Windows, where there is a distinction between core and extension > procedures. > > I'm still seeing a test failure in the GLU tessellation mechanism (on > both Win64 and Linux64), but I've fixed a crashing problem there on > Win64. I'll release another alpha in a few moments to pick up those > fixes, but expect we'll need another fairly soon to pick up the tess > fixes when I get them. > > Where can I get current source/builds? I couldn't find anything > recent on SourceForge. Releases/downloads: http://pypi.python.org/pypi/PyOpenGL Source code: https://code.launchpad.net/pyopengl The tess issues seem to have been there for a long time; it works perfectly well in OpenGLContext' usage and tests, and even works if I copy the OpenGLContext test into a raw test, but the original test doesn't generate vertices (it wasn't checking for that previously). At this point I'm assuming this is just a test-setup issue, so not a critical fix. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Ian M. <geo...@gm...> - 2012-02-26 00:19:22
|
On Fri, Feb 3, 2012 at 11:09 AM, Mike C. Fletcher <mcf...@vr...>wrote: > The tess issues seem to have been there for a long time; it works > perfectly well in OpenGLContext' usage and tests, and even works if I copy > the OpenGLContext test into a raw test, but the original test doesn't > generate vertices (it wasn't checking for that previously). At this point > I'm assuming this is just a test-setup issue, so not a critical fix. > Yeah, I'm not too concerned about gluTess* stuff; there's hardware support for tessellation now, which is better. And I can honestly say, I've not had need for either. I am having a new problem, however. glutInit is failing. The error looks something like: Traceback (most recent call last): File "<pyshell#2>", line 1, in <module> glutInit() File "C:\dev\Python26\lib\site-packages\pyopengl-3.0.2a4-py2.6.egg\OpenGL\GLUT\special.py", line 324, in glutInit _base_glutInit( ctypes.byref(count), holder ) TypeError: 'NoneType' object is not callable There are similar problems with other GLUT functions. I read somewhere that this may be due to 64 bit issues (i.e., PyOpenGL is trying to use a glut32.dll compiled for 32 bit platforms). Is this the case? And is there a way to solve it for the general case? Thanks, Ian |
From: Mike C. F. <mcf...@vr...> - 2012-02-27 14:04:17
|
On 12-02-25 07:19 PM, Ian Mallett wrote: > On Fri, Feb 3, 2012 at 11:09 AM, Mike C. Fletcher > <mcf...@vr... <mailto:mcf...@vr...>> wrote: > > The tess issues seem to have been there for a long time; it works > perfectly well in OpenGLContext' usage and tests, and even works > if I copy the OpenGLContext test into a raw test, but the original > test doesn't generate vertices (it wasn't checking for that > previously). At this point I'm assuming this is just a test-setup > issue, so not a critical fix. > > Yeah, I'm not too concerned about gluTess* stuff; there's hardware > support for tessellation now, which is better. And I can honestly > say, I've not had need for either. > > I am having a new problem, however. glutInit is failing. The error > looks something like: > > Traceback (most recent call last): > File "<pyshell#2>", line 1, in <module> > glutInit() > File > "C:\dev\Python26\lib\site-packages\pyopengl-3.0.2a4-py2.6.egg\OpenGL\GLUT\special.py", > line 324, in glutInit > _base_glutInit( ctypes.byref(count), holder ) > TypeError: 'NoneType' object is not callable > > There are similar problems with other GLUT functions. I read > somewhere that this may be due to 64 bit issues (i.e., PyOpenGL is > trying to use a glut32.dll compiled for 32 bit platforms). Is this > the case? And is there a way to solve it for the general case? > > Thanks, > Ian Likely need to recompile all of the glut, gle, accelerate etc DLLs if that's the case. I'll see if I can get some time to do that today. Don't know if I have all of the compilation tools set up properly for the 64-bit Windows, so that might be a bit of a challenge (hopefully mingw64 exists and will work with 2.6). Python 2.7 *should* IIRC work with the currently-available free compiler, so *that* should be straightforward. Always more work than time, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Henry G. <he...@ca...> - 2012-02-27 14:08:12
|
On Mon, 2012-02-27 at 09:05 -0500, Mike C. Fletcher wrote: > Likely need to recompile all of the glut, gle, accelerate etc DLLs if > that's the case. I'll see if I can get some time to do that today. > Don't know if I have all of the compilation tools set up properly for > the 64-bit Windows, so that might be a bit of a challenge (hopefully > mingw64 exists and will work with 2.6). Python 2.7 *should* IIRC > work > with the currently-available free compiler, so *that* should be > straightforward. This: https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows might be useful for the gle bit. cheers, Henry |
From: Alejandro S. <as...@gm...> - 2012-02-27 14:30:30
|
Hi all, Theoretically, it should be possible to use cygwin to generate 64-bit binaries. Let me know if you decide to move forward in this direction, I might be able to help. Best, Alejandro.- 2012/2/27 Henry Gomersall <he...@ca...> > On Mon, 2012-02-27 at 09:05 -0500, Mike C. Fletcher wrote: > > Likely need to recompile all of the glut, gle, accelerate etc DLLs if > > that's the case. I'll see if I can get some time to do that today. > > Don't know if I have all of the compilation tools set up properly for > > the 64-bit Windows, so that might be a bit of a challenge (hopefully > > mingw64 exists and will work with 2.6). Python 2.7 *should* IIRC > > work > > with the currently-available free compiler, so *that* should be > > straightforward. > > This: > https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows > > might be useful for the gle bit. > > cheers, > > Henry > > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > -- http://alejandrosegovia.net |
From: Mike C. F. <mcf...@vr...> - 2012-02-27 15:17:54
|
On 12-02-27 09:29 AM, Alejandro Segovia wrote: > Hi all, > > Theoretically, it should be possible to use cygwin to generate 64-bit > binaries. Let me know if you decide to move forward in this direction, > I might be able to help. What I'm reading is saying that Mingw64 (i.e. Cygwin without the Cygwin DLL) isn't a good option (yet). http://wiki.cython.org/64BitCythonExtensionsOnWindows The Python 2.6 win32 releases were all Mingw32 compiles, as that let me use Mingw32 for 2.6 and VC++ Express for the 2.7 version. I'll likely go with the SDK approach for the 2.7 releases on 64-bit, not sure what I'll do for the 64-bit 2.6 compiles yet. If this wasn't a pay-per-install OS I'd just set up a VM branch for the 2.6 release, but I only have the one (real) machine with a Win64 license. Enjoy, Mike > 2012/2/27 Henry Gomersall <he...@ca... <mailto:he...@ca...>> > > On Mon, 2012-02-27 <tel:2012-02-27> at 09:05 -0500, Mike C. > Fletcher wrote: > > Likely need to recompile all of the glut, gle, accelerate etc > DLLs if > > that's the case. I'll see if I can get some time to do that today. > > Don't know if I have all of the compilation tools set up > properly for > > the 64-bit Windows, so that might be a bit of a challenge (hopefully > > mingw64 exists and will work with 2.6). Python 2.7 *should* IIRC > > work > > with the currently-available free compiler, so *that* should be > > straightforward. > > This: > https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows > > might be useful for the gle bit. > > cheers, > > Henry > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft > developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, > MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > <mailto:PyO...@li...> > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > > > > -- > http://alejandrosegovia.net > -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Henry G. <he...@ca...> - 2012-02-27 15:24:02
|
On Mon, 2012-02-27 at 10:18 -0500, Mike C. Fletcher wrote: > > Theoretically, it should be possible to use cygwin to generate > 64-bit > > binaries. Let me know if you decide to move forward in this > direction, > > I might be able to help. > > What I'm reading is saying that Mingw64 (i.e. Cygwin without the > Cygwin > DLL) isn't a good option (yet). > > http://wiki.cython.org/64BitCythonExtensionsOnWindows > > The Python 2.6 win32 releases were all Mingw32 compiles, as that let > me > use Mingw32 for 2.6 and VC++ Express for the 2.7 version. I'll > likely > go with the SDK approach for the 2.7 releases on 64-bit, not sure > what > I'll do for the 64-bit 2.6 compiles yet. If this wasn't a > pay-per-install OS I'd just set up a VM branch for the 2.6 release, > but > I only have the one (real) machine with a Win64 license. There is more info on the distutils page on cross compiling: http://docs.python.org/distutils/builtdist.html I don't know how that tallies with the emphatic "Do not use MinGW-w64". I'm assuming distutils uses mingw (though I don't really know). cheers, Henry |
From: Mike C. F. <mcf...@vr...> - 2012-02-27 15:23:08
|
On 12-02-27 09:08 AM, Henry Gomersall wrote: > On Mon, 2012-02-27 at 09:05 -0500, Mike C. Fletcher wrote: >> Likely need to recompile all of the glut, gle, accelerate etc DLLs if >> that's the case. I'll see if I can get some time to do that today. >> Don't know if I have all of the compilation tools set up properly for >> the 64-bit Windows, so that might be a bit of a challenge (hopefully >> mingw64 exists and will work with 2.6). Python 2.7 *should* IIRC >> work >> with the currently-available free compiler, so *that* should be >> straightforward. > This: > https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows > > might be useful for the gle bit. > > cheers, > > Henry Do you happen to know what the changes were? Is this something I should fold back into PyOpenGL's build process? Were there changes that make non-64-bit no longer work? Seem the history starts with your adding it to the repository there. Thanks, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Henry G. <he...@ca...> - 2012-02-27 15:31:16
|
On Mon, 2012-02-27 at 10:23 -0500, Mike C. Fletcher wrote: > > This: > > https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows > > > > might be useful for the gle bit. > > > > cheers, > > > > Henry > Do you happen to know what the changes were? Is this something I > should > fold back into PyOpenGL's build process? Were there changes that > make > non-64-bit no longer work? Seem the history starts with your adding > it > to the repository there. The changes were so it would build, which were all done by Alejandro. I pretty certain it's unmodified from that code he sent me. I don't *even* think that I built it - the dll was from Alejandro's efforts. (sorry I can't be more useful!). Cheers, Henry |
From: Alejandro S. <as...@gm...> - 2012-02-27 15:35:36
|
2012/2/27 Henry Gomersall <he...@ca...> > On Mon, 2012-02-27 at 10:23 -0500, Mike C. Fletcher wrote: > > > This: > > > https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows > > > > > > might be useful for the gle bit. > > > > > > cheers, > > > > > > Henry > > Do you happen to know what the changes were? Is this something I > > should > > fold back into PyOpenGL's build process? Were there changes that > > make > > non-64-bit no longer work? Seem the history starts with your adding > > it > > to the repository there. > > The changes were so it would build, which were all done by Alejandro. I > pretty certain it's unmodified from that code he sent me. > > I don't *even* think that I built it - the dll was from Alejandro's > efforts. (sorry I can't be more useful!). > I remember rebuilding the GLE DLL on Windows so it would link against a newer MSVCRT version. I don't remember making any other changes. Alejandro.- ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ PyOpenGL Homepage http://pyopengl.sourceforge.net _______________________________________________ PyOpenGL-Users mailing list PyO...@li... https://lists.sourceforge.net/lists/listinfo/pyopengl-users -- http://alejandrosegovia.net |
From: Mike C. F. <mcf...@vr...> - 2012-02-29 13:53:22
|
On 12-02-25 07:19 PM, Ian Mallett wrote: > On Fri, Feb 3, 2012 at 11:09 AM, Mike C. Fletcher > <mcf...@vr... <mailto:mcf...@vr...>> wrote: > > The tess issues seem to have been there for a long time; it works > perfectly well in OpenGLContext' usage and tests, and even works > if I copy the OpenGLContext test into a raw test, but the original > test doesn't generate vertices (it wasn't checking for that > previously). At this point I'm assuming this is just a test-setup > issue, so not a critical fix. > > Yeah, I'm not too concerned about gluTess* stuff; there's hardware > support for tessellation now, which is better. And I can honestly > say, I've not had need for either. > > I am having a new problem, however. glutInit is failing. The error > looks something like: > > Traceback (most recent call last): > File "<pyshell#2>", line 1, in <module> > glutInit() > File > "C:\dev\Python26\lib\site-packages\pyopengl-3.0.2a4-py2.6.egg\OpenGL\GLUT\special.py", > line 324, in glutInit > _base_glutInit( ctypes.byref(count), holder ) > TypeError: 'NoneType' object is not callable > > There are similar problems with other GLUT functions. I read > somewhere that this may be due to 64 bit issues (i.e., PyOpenGL is > trying to use a glut32.dll compiled for 32 bit platforms). Is this > the case? And is there a way to solve it for the general case? > > Thanks, > Ian Alright, I'm now set up and able to build GLUT and GLE in both 32 and 64-bit configurations. I'm working on making the build process for both of those automatic so that maintaining them won't be a royal pain when e.g. we need to build for Python 3.x compiler as well. I've also got the latest (trunk) PyOpenGL accelerate modules built for 32 and 64-bit. Not really sure about the 32-bit/64-bit issues for GLUT and GLE. From what I read you can't load the 32-bit DLLS at all in a 64-bit build (and vice versa), so it seems we'll need to provide completely separate 32 and 64-bit DLLS packages/directories or have the DLLS be e.g. glut64.dll and opengle64.dll. My preference is for the latter, as that way you can still run PyOpenGL from a bzr checkout. The idea would be to use platform.architecture() to query the DLL size *only* on Windows (apparently .architecture has problems on OSX). Using sys.maxint does not *appear* to work, as on both my 64-bit build of Python it seems to return 2**31-1, which makes me think "WTF, is this the wrong Python"?. If anyone sees any problems with that (glut64.dll, opengle64.dll), let me know, otherwise I'll try to finish up the build process and integrate the 64-bit DLLs into the packages. Have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mike C. F. <mcf...@vr...> - 2012-02-29 16:04:32
|
On 12-02-29 08:53 AM, Mike C. Fletcher wrote: > On 12-02-25 07:19 PM, Ian Mallett wrote: >> On Fri, Feb 3, 2012 at 11:09 AM, Mike C. Fletcher >> <mcf...@vr...<mailto:mcf...@vr...>> wrote: >> >> The tess issues seem to have been there for a long time; it works >> perfectly well in OpenGLContext' usage and tests, and even works >> if I copy the OpenGLContext test into a raw test, but the original >> test doesn't generate vertices (it wasn't checking for that >> previously). At this point I'm assuming this is just a test-setup >> issue, so not a critical fix. >> >> Yeah, I'm not too concerned about gluTess* stuff; there's hardware >> support for tessellation now, which is better. And I can honestly >> say, I've not had need for either. >> >> I am having a new problem, however. glutInit is failing. The error >> looks something like: >> >> Traceback (most recent call last): >> File "<pyshell#2>", line 1, in<module> >> glutInit() >> File >> "C:\dev\Python26\lib\site-packages\pyopengl-3.0.2a4-py2.6.egg\OpenGL\GLUT\special.py", >> line 324, in glutInit >> _base_glutInit( ctypes.byref(count), holder ) >> TypeError: 'NoneType' object is not callable >> >> There are similar problems with other GLUT functions. I read >> somewhere that this may be due to 64 bit issues (i.e., PyOpenGL is >> trying to use a glut32.dll compiled for 32 bit platforms). Is this >> the case? And is there a way to solve it for the general case? >> >> Thanks, >> Ian > Alright, I'm now set up and able to build GLUT and GLE in both 32 and > 64-bit configurations. I'm working on making the build process for both > of those automatic so that maintaining them won't be a royal pain when > e.g. we need to build for Python 3.x compiler as well. I've also got > the latest (trunk) PyOpenGL accelerate modules built for 32 and 64-bit. Hrm, and now I can't get GLUT to build 64-bit again. For now I'm using the prebuilt 32 + 64 package. Both 32-bit and 64-bit python are able to run basic glutinit tests. I haven't done any testing with GLE yet. If people with 64-bit Windows want to test it: bzr branch lp:pyopengl cd pyopengl python setup.py develop cd tests python test_glutinit.py should produce a blank black window with a lot of debug blather on the console. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |