Thread: [PyOpenGL-Users] Difficulty accessing glCreateShader
Brought to you by:
mcfletch
From: Mohan <mg...@ca...> - 2009-03-17 17:01:43
|
Hi, I'm just starting with PyOpenGL (installed from PyOpenGL-3.0.0c1.win32.exe under a fresh install of Python 2.5 on Windows XP Professional; the only other package installed is pygame). I'm running into problems with the example here: http://www.pygame.org/wiki/GLSLExample I get the error: AttributeError: function 'glCreateShader' not found on line 26: glCreateShader = gl.glCreateShader glGetString(...) reports that I'm running version 2.1.2 from NVidia, and have reams of extensions available. Any help would be much appreciated! Mohan |
From: Mike C. F. <mcf...@vr...> - 2009-03-17 17:20:16
|
Mohan wrote: > Hi, > > I'm just starting with PyOpenGL (installed from PyOpenGL-3.0.0c1.win32.exe > under a fresh install of Python 2.5 on Windows XP Professional; the only > other package installed is pygame). I'm running into problems with the > example here: > > http://www.pygame.org/wiki/GLSLExample > > I get the error: > > AttributeError: function 'glCreateShader' not found > > on line 26: glCreateShader = gl.glCreateShader > That code is not really using PyOpenGL. It's just using ctypes to access the raw functionality via PyOpenGL's pointer to the OpenGL library. from OpenGL.GL import glCreateShader should get a fully functional and wrapped version of the function, as long as it's available on your machine. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mohan <mg...@ca...> - 2009-03-17 18:18:11
|
Hi Mike, Thank you very much for the (very quick!) reply. Changing the code to refer to glCreateShader = OpenGL.GL.glCreateShader etc. solved that problem. Unfortunately, there is still an error, namely ValueError: glShaderSource requires 2 arguments (shaderObj, string), received 4: (2L, 1, <cparam 'P' (0187bd28)>, <cparam 'P' (0187bd78)>) (I have kept the glShaderSource.argtypes = [c_int, c_int, POINTER(c_char_p), POINTER(c_int)] in the source.) In another post on a very similar problem (pyopengl-Bugs-1878648), you wrote >I'm guessing what's happening is that you are on Win32, and that at the point where you import the module, there's no glShaderSource function. As a result the wrappers were not being created. Later, when you tried to call them, the null-function wrapper was able to resolve the function and tried to call it directly.< Is there a workaround for this? I had a look at the example you mentioned in that post, and it references glShaderSourceARB rather than glShaderSource. I can switch to ARB extensions if need be, but I'd like to understand why the straightforward 2.0 approach isn't working, i.e. why there's no glShaderSource function when the module is imported. It sounds like I might be asking for help in an inappropriate place, in that I'm not really using the functionality of PyOpenGL. (I am very grateful for the previous assistance!) Would you happen to know of a more appropriate mailing list or forum? Thanks again, Mohan PS. My mail client is misbehaving -- I've waited half an hour to avoid double posts, but in case something went wrong I'm very sorry! |
From: Gijs <in...@bs...> - 2009-03-17 18:57:38
|
Mohan wrote: > Hi Mike, > > Thank you very much for the (very quick!) reply. Changing the code to refer > to > > glCreateShader = OpenGL.GL.glCreateShader > > etc. solved that problem. Unfortunately, there is still an error, namely > > ValueError: glShaderSource requires 2 arguments (shaderObj, string), > received 4: > (2L, 1, <cparam 'P' (0187bd28)>, <cparam 'P' (0187bd78)>) > > (I have kept the > > glShaderSource.argtypes = [c_int, c_int, POINTER(c_char_p), > POINTER(c_int)] > > in the source.) > > In another post on a very similar problem (pyopengl-Bugs-1878648), you wrote > >> I'm guessing what's > happening is that you are on Win32, and that at the point where you import > the module, there's no glShaderSource function. As a result the wrappers > were not being created. Later, when you tried to call them, the > null-function wrapper was able to resolve the function and tried to call it > directly.< > > Is there a workaround for this? I had a look at the example you mentioned > in that post, and it references glShaderSourceARB rather than > glShaderSource. I can switch to ARB extensions if need be, but I'd like to > understand why the straightforward 2.0 approach isn't working, i.e. why > there's no glShaderSource function when the module is imported. > > It sounds like I might be asking for help in an inappropriate place, in > that I'm not really using the functionality of PyOpenGL. (I am very > grateful for the previous assistance!) Would you happen to know of a more > appropriate mailing list or forum? > > Thanks again, > Mohan > > PS. My mail client is misbehaving -- I've waited half an hour to avoid > double posts, but in case something went wrong I'm very sorry! Hello Mohan, I fooled around with these kinds of problems quite a bit and the best way to make it work without too much work, is to switch all your OpenGL code to their ARB equivalents. Best thing is that it makes it portable across platforms as well. If you use the ARB function calls instead of the "normal" ones, Windows, Mac OS X and Linux usually works 99% of the time (not including driver differences). I'm not completely clear on the problem, but it has something to do with how/when the functions are bound to their OpenGL functions. Windows binds them later on, while Mac OS X and Linux bind them earlier (from what I've seen so far). Maybe Windows binds them when you call the Glut init functions, but I'm sure Mike can give you a better answer regarding the problem. Regards, Gijs |
From: Mike C. F. <mcf...@vr...> - 2009-03-17 20:30:36
|
Mohan wrote: > Hi Mike, > > Thank you very much for the (very quick!) reply. Changing the code to refer > to > > glCreateShader = OpenGL.GL.glCreateShader > > etc. solved that problem. Unfortunately, there is still an error, namely > > ValueError: glShaderSource requires 2 arguments (shaderObj, string), > received 4: > (2L, 1, <cparam 'P' (0187bd28)>, <cparam 'P' (0187bd78)>) > > (I have kept the > > glShaderSource.argtypes = [c_int, c_int, POINTER(c_char_p), > POINTER(c_int)] > > in the source.) > Sorry, I should have been more verbose in the explanation. You are using code that uses the equivalent of the "raw" PyOpenGL api, i.e. raw ctypes-coded interfaces with the C DLL. You can certainly continue to do that, or you can switch to using the PyOpenGL API. The code sample you are using as a source is from before PyOpenGL supported the 2.x (or 3.x) extension functions, so it's showing you the raw C-style API calls. Probably would be easier to use a sample written for PyOpenGL 3.x to get started faster. There's a sample in OpenGLContext, another in the proesch PyOpenGL-Demo subdirectory, and a third in the PyOpenGL-Demo/GLUT subdirectory IIRC. You shouldn't need any ctypes references to work with PyOpenGL unless you want to use ctypes data-types (arrays). You shouldn't ever need to specify argtypes for a PyOpenGL function, at least. > In another post on a very similar problem (pyopengl-Bugs-1878648), you wrote > > >> I'm guessing what's >> > happening is that you are on Win32, and that at the point where you import > the module, there's no glShaderSource function. As a result the wrappers > were not being created. Later, when you tried to call them, the > null-function wrapper was able to resolve the function and tried to call it > directly.< > > Is there a workaround for this? I had a look at the example you mentioned > in that post, and it references glShaderSourceARB rather than > glShaderSource. I can switch to ARB extensions if need be, but I'd like to > understand why the straightforward 2.0 approach isn't working, i.e. why > there's no glShaderSource function when the module is imported. > This is an allowed OpenGL operating modality, and apparently some driver writers are relying on it. Basically the work-around is to only do the calls *after* you have a rendering context available from which to retrieve the functions. It shouldn't happen with *core* functions AFAIK, it should only happen with ARB, EXT or other extension functions. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mohan <mg...@ca...> - 2009-03-18 00:40:18
|
On Mar 17 2009, Mike C. Fletcher wrote: >. You are >using code that uses the equivalent of the "raw" PyOpenGL api, i.e. raw >ctypes-coded interfaces with the C DLL. You can certainly continue to >do that, or you can switch to using the PyOpenGL API. The code sample >you are using as a source is from before PyOpenGL supported the 2.x (or >3.x) extension functions, so it's showing you the raw C-style API >calls. Probably would be easier to use a sample written for PyOpenGL >3.x to get started faster. Now I understand why the documentation provides two signatures for each function! I'll and keep trying with the (considerably nicer) non-raw interface. Thank you again. Mohan |