A followup to last year’s foray into Python and OpenGL.
I noticed today that wxPython includes a GLCanvas class which uses PyOpenGL. However, as of 126.96.36.199, wxPython’s demo crashes due to wxWidgets bug 10203 which is fixed in 2.8 wxWidgets post 2.8.9, and in 2.10.
Until a wxPython release comes out based on either of those, there is a workaround. The script update_manifest.py, which wxPython includes to change the manifest in your python.exe and pythonw.exe to use the Windows XP comctl32.dll, also fixes this problem, so even though I’ve been aware of this bug for ages, I’ve only learned about this workaround tonight by reading the wxpython mailing list archive.
Now that I’ve got that patched, and PyOpenGL installed, the GLCanvas demo in wxPython runs, and the cube demo works. The cone demo however comes back with this:
OpenGL.error.NullFunctionError: Attempt to call an undefined function __glutInitWithExit, check for bool(__glutInitWithExit) before calling
This turns out to not be a surprise, as I don’t have GLUT (glut32.dll) installed. Sadly, the wxPython demo code doesn’t test the result of the OpenGL.GLUT.glutInit method in PyOpenGL, so this exception is simply output without causing the cone window to abort.
Since the draw code for the cone calls glPushMatrix before any of its glut calls, and the glut calls throw an exception so you never call glPopMatrix, you end up filling your matrix stack, and getting a lot of error spam in your output window, where the later errors can easily push the older errors out the top of your scrollback buffer.
I turned out to be too lazy to build my own glut (it’s anecdotaly possible) but a lucky hit with Google informed me that Nvidia’s Cg Toolkit includes both a win32 and x64 version of glut32.dll. You wouldn’t be able to distribute it as there’s no license indication for glut apart from the license for the whole Cg Toolkit. The glut.h file included however is the one from normal Glut (or so it appears) so I doubt it’s anything except the win32 version of upstream glut.
On this point, it’s not obvious to me if freeglut is supposed to be a drop-in replacement for glut32.dll, or a souped-up alternative. It doesn’t help that the freeglut configure file includes an option to switch that mode on or off (producing libglut.so or libfreeglut.so) while the .mak file (for NMake) only produces freeglut.dll not glut32.dll. So I guess it’s intended to be both. The next step would be to see if freeglut can build from configure using mingw64 and produce a drop-in glut32.dll.
However, I don’t care that much. I only wanted to see the wxPython GLCanvas demo run. I won’t be using GLUT (or event GLCanvas, to be honest) myself so this has had plenty of time devoted to it anway.
I guess I hope that the main benefit of this blog posting is to allow those very occasional forum posters who go looking for glut32.dll for Vista x64 or XP x64, or even Vista 32-bit, to find it in the NVidia Cg Toolkit. So far I’ve seen several such questions when searching Google for a copy myself, but no one ever finds one for 64-bit. (There’s a 32-bit one in the bullet physics SVN repository, if you don’t want NVidia’s one.)
And for those same forum posters, a quick note. The x64 build of glut32.dll goes in %WINDIR%\system32 on x64 machines. The win32 build of glut32.dll goes in %WINDIR%\SysWOW64. If you get this wrong, you’ll get the same error messages as not having the file present at all. It’s prolly both easier and a better idea to actually drop the glut32.dll next to the program you’re running, unless you have both 32-bit and x64 versions in the same directory for some reason…