Thread: [PyOpenGL-Users] glGenVertexArrays producing 'invalid enumerant' error.
Brought to you by:
mcfletch
From: Gordon W. <go...@to...> - 2011-10-13 07:56:40
|
Version stuff: Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. import OpenGL OpenGL.__version__ '3.0.2a1' I'm using FORWARD_COMPATIBLE_ONLY, context version 3.3 and GLUT_CORE_PROFILE. I'm porting a working (same machine and environment etc) C program to Python, and the glGenVertexArrays function is giving me grief. The pythonic form: vao = glGenVertexArrays(1) produces "TypeError: this function takes at least 2 arguments" which I presume means it hasn't been wrapped yet. The ctypes form: vao = GLuint() glGenVertexArrays(1, ctypes.byref(vao)) produces: Traceback (most recent call last): File "main.py", line 230, in <module> main(sys.argv) File "main.py", line 221, in main init() File "main.py", line 155, in init glGenVertexArrays(1, ctypes.byref(vao)) File "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", line 372, in __call__ return self( *args, **named ) File "/usr/local/lib/python2.7/dist-packages/OpenGL/error.py", line 208, in glCheckError baseOperation = baseOperation, OpenGL.error.GLError: GLError( err = 1280, description = 'invalid enumerant', baseOperation = glGenVertexArrays, cArguments = (1, <cparam 'P' (0xb74b9b48)>) ) I've no idea what could be causing that and googling hasn't turned up anything useful. Does anyone have any suggestions as to where to look? Are there any known working examples of using vertex array objects and pyopengl that I could cross check against? G |
From: tolomea <go...@to...> - 2011-10-12 07:35:18
|
Version stuff: Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. import OpenGL OpenGL.__version__ '3.0.2a1' I'm using FORWARD_COMPATIBLE_ONLY, context version 3.3 and GLUT_CORE_PROFILE. I'm porting a working (same machine and environment etc) C program to Python, and the glGenVertexArrays function is giving me grief. The pythonic form: vao = glGenVertexArrays(1) produces "TypeError: this function takes at least 2 arguments" which I presume means it hasn't been wrapped yet. The ctypes form: vao = GLuint() glGenVertexArrays(1, ctypes.byref(vao)) produces: Traceback (most recent call last): File "main.py", line 230, in <module> main(sys.argv) File "main.py", line 221, in main init() File "main.py", line 155, in init glGenVertexArrays(1, ctypes.byref(vao)) File "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", line 372, in __call__ return self( *args, **named ) File "/usr/local/lib/python2.7/dist-packages/OpenGL/error.py", line 208, in glCheckError baseOperation = baseOperation, OpenGL.error.GLError: GLError( err = 1280, description = 'invalid enumerant', baseOperation = glGenVertexArrays, cArguments = (1, <cparam 'P' (0xb74b9b48)>) ) I've no idea what could be causing that and googling hasn't turned up anything useful. Does anyone have any suggestions as to where to look? Are there any known working examples of using vertex array objects and pyopengl that I could cross check against? G |
From: Mike C. F. <mcf...@vr...> - 2011-10-17 17:56:52
|
On 11-10-12 03:34 AM, tolomea wrote: > Version stuff: > Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) > [GCC 4.5.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > import OpenGL > OpenGL.__version__ > '3.0.2a1' > I'm using FORWARD_COMPATIBLE_ONLY, context version 3.3 and GLUT_CORE_PROFILE. > > > I'm porting a working (same machine and environment etc) C program to Python, > and the glGenVertexArrays function is giving me grief. > > The pythonic form: > vao = glGenVertexArrays(1) > produces "TypeError: this function takes at least 2 arguments" which I presume > means it hasn't been wrapped yet. Yes. > I've no idea what could be causing that and googling hasn't turned up anything > useful. > > Does anyone have any suggestions as to where to look? > Are there any known working examples of using vertex array objects and pyopengl > that I could cross check against? My go-to guess with almost any Python-differs-from-C problems during init is to look at the error-checking code. PyOpenGL's biggest difference from C code is that it runs error checking after every call. I'm guessing either your context isn't quite ready-to-go and you're getting an error from the error checking, or that the line before had an error and the error checking picked it up a line late. import OpenGL OpenGL.USE_ACCELERATE = False OpenGL.ERROR_CHECKING = False at the top of your script should let you quickly determine a) where the problem is b) whether the problem is with error checking. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Gordon W. <go...@to...> - 2011-11-05 19:28:47
|
The plot thickens, if I bypass pyopengl and do the glGenVertexArrays call direct through ctypes the "invalid enumerant" error moves to the subsequent glBindVertexArray call, if I use cytpes for that as well then everything starts working. G On Fri, Nov 4, 2011 at 11:30 PM, Gordon Wrigley <go...@to...> wrote: > I just got a chance to get back to this and I've made a little head way, > far enough that I have something on screen. > Specifying GLUT_COMPATIBILITY_PROFILE instead of GLUT_CORE_PROFILE got > round the glGenVertexArrays error. > I also had to do ctypes stuff to work around the lack of wrapper for that > function. > And the function glVertexAttribPointer was getting cast errors on the last > argument so I had to ctypes around that as well. > I believe that's the only dirty stuff I have so far. > > G > > > On Tue, Oct 25, 2011 at 1:56 AM, Mike C. Fletcher <mcf...@vr...>wrote: > >> ** >> On 11-10-20 06:41 AM, Gordon Wrigley wrote: >> >> And I attached the wrong log, here's the correct one. >> >> >> Hrm, not much to go on there. The call to createShader() does not appear >> in the stack, which is a bit weird. Is this code I could trace through to >> try to find the error (i.e. not something proprietary?) >> >> Good luck, >> Mike >> >> >> >> On Thu, Oct 20, 2011 at 9:39 PM, Gordon Wrigley <go...@to...>wrote: >> >>> On Tue, Oct 18, 2011 at 4:56 AM, Mike C. Fletcher < >>> mcf...@vr...> wrote: >>> >>>> On 11-10-12 03:34 AM, tolomea wrote: >>>> > Version stuff: >>>> > Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) >>>> > [GCC 4.5.2] on linux2 >>>> > Type "help", "copyright", "credits" or "license" for more information. >>>> > import OpenGL >>>> > OpenGL.__version__ >>>> > '3.0.2a1' >>>> > I'm using FORWARD_COMPATIBLE_ONLY, context version 3.3 and >>>> GLUT_CORE_PROFILE. >>>> > >>>> > >>>> > I'm porting a working (same machine and environment etc) C program to >>>> Python, >>>> > and the glGenVertexArrays function is giving me grief. >>>> > >>>> > The pythonic form: >>>> > vao = glGenVertexArrays(1) >>>> > produces "TypeError: this function takes at least 2 arguments" which >>>> I presume >>>> > means it hasn't been wrapped yet. >>>> Yes. >>>> > I've no idea what could be causing that and googling hasn't turned up >>>> anything >>>> > useful. >>>> > >>>> > Does anyone have any suggestions as to where to look? >>>> > Are there any known working examples of using vertex array objects >>>> and pyopengl >>>> > that I could cross check against? >>>> My go-to guess with almost any Python-differs-from-C problems during >>>> init is to look at the error-checking code. PyOpenGL's biggest >>>> difference from C code is that it runs error checking after every call. >>>> I'm guessing either your context isn't quite ready-to-go and you're >>>> getting an error from the error checking, or that the line before had an >>>> error and the error checking picked it up a line late. >>>> >>>> import OpenGL >>>> OpenGL.USE_ACCELERATE = False >>>> OpenGL.ERROR_CHECKING = False >>>> >>>> at the top of your script should let you quickly determine a) where the >>>> problem is b) whether the problem is with error checking. >>>> >>>> >>> If I turn error checking off it dies much earlier on a glCreateShader >>> call with: >>> >>> WARNING:OpenGL.errors:Failure on glCreateShader: Traceback (most >>> recent call last): >>> File "/usr/local/lib/python2.7/dist-packages/OpenGL/logs.py", line 74, >>> in __call__ >>> return function( *args, **named ) >>> ArgumentError: argument 3: <type 'exceptions.TypeError'>: Don't know how >>> to convert parameter 3 >>> >>> Traceback (most recent call last): >>> File "main.py", line 237, in <module> >>> main(sys.argv) >>> File "main.py", line 227, in main >>> init() >>> File "main.py", line 147, in init >>> init_program() >>> File "main.py", line 122, in init_program >>> vert = gl.VertexShader("data/shaders/basic.vert") >>> File "/mnt/drive1/home/gordon/code/spacecraft2/gl.py", line 50, in >>> __init__ >>> _Shader.__init__(self, fname, VERTEX_SHADER) >>> File "/mnt/drive1/home/gordon/code/spacecraft2/gl.py", line 37, in >>> __init__ >>> self.shader = createShader(shader_type) >>> File >>> "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", >>> line 372, in __call__ >>> return self( *args, **named ) >>> File "/usr/local/lib/python2.7/dist-packages/OpenGL/logs.py", line >>> 74, in __call__ >>> return function( *args, **named ) >>> ctypes.ArgumentError: argument 3: <type 'exceptions.TypeError'>: Don't >>> know how to convert parameter 3 >>> >>> >>> That doesn't seem like progress. >>> >>> With error checking on calling glGetError right before the >>> glGenVertexArrays call returns 0. >>> >>> Toggling use accelerate hasn't made any noticeable difference. >>> >>> I don't know if it helps any but I turned on full logging and attached >>> a dump of the output. >>> >>> G >>> >>> >>> >> >> >> -- >> ________________________________________________ >> Mike C. Fletcher >> Designer, VR Plumber, Coder >> http://www.vrplumber.com >> http://blog.vrplumber.com >> >> > |
From: Mike C. F. <vrp...@gm...> - 2011-11-08 05:27:01
|
On 11-11-05 03:28 PM, Gordon Wrigley wrote: > The plot thickens, if I bypass pyopengl and do the glGenVertexArrays > call direct through ctypes the "invalid enumerant" error moves to the > subsequent glBindVertexArray call, if I use cytpes for that as well > then everything starts working. Sounds like there's an error being hidden in there somewhere, would have to try to reproduce it to see what it was. I suspect it's actually the glGenVertexArrays call, or more likely, the call before it that is producing the error. The two uses of direct ctypes are simply ignoring the error being set, most likely. > > On Fri, Nov 4, 2011 at 11:30 PM, Gordon Wrigley <go...@to... > <mailto:go...@to...>> wrote: > > I just got a chance to get back to this and I've made a little > head way, far enough that I have something on screen. > Specifying GLUT_COMPATIBILITY_PROFILE instead of GLUT_CORE_PROFILE > got round the glGenVertexArrays error. > I also had to do ctypes stuff to work around the lack of wrapper > for that function. > And the function glVertexAttribPointer was getting cast errors on > the last argument so I had to ctypes around that as well. > I believe that's the only dirty stuff I have so far. > > G > You *should* be able to specify core profile, I'd like to get that working some day. glVertexAttrib pointer errors seems strange. I'm pretty sure I use that in some of my sample code, but maybe something has regressed? Hopefully will get some time next week to work on it, Mike > > > > On Tue, Oct 25, 2011 at 1:56 AM, Mike C. Fletcher > <mcf...@vr... <mailto:mcf...@vr...>> wrote: > > On 11-10-20 06:41 AM, Gordon Wrigley wrote: >> And I attached the wrong log, here's the correct one. > > Hrm, not much to go on there. The call to createShader() does > not appear in the stack, which is a bit weird. Is this code I > could trace through to try to find the error (i.e. not > something proprietary?) > > Good luck, > Mike > > >> >> On Thu, Oct 20, 2011 at 9:39 PM, Gordon Wrigley >> <go...@to... <mailto:go...@to...>> wrote: >> >> On Tue, Oct 18, 2011 at 4:56 AM, Mike C. Fletcher >> <mcf...@vr... <mailto:mcf...@vr...>> >> wrote: >> >> On 11-10-12 03:34 AM, tolomea wrote: >> > Version stuff: >> > Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) >> > [GCC 4.5.2] on linux2 >> > Type "help", "copyright", "credits" or "license" >> for more information. >> > import OpenGL >> > OpenGL.__version__ >> > '3.0.2a1' >> > I'm using FORWARD_COMPATIBLE_ONLY, context version >> 3.3 and GLUT_CORE_PROFILE. >> > >> > >> > I'm porting a working (same machine and environment >> etc) C program to Python, >> > and the glGenVertexArrays function is giving me grief. >> > >> > The pythonic form: >> > vao = glGenVertexArrays(1) >> > produces "TypeError: this function takes at least 2 >> arguments" which I presume >> > means it hasn't been wrapped yet. >> Yes. >> > I've no idea what could be causing that and >> googling hasn't turned up anything >> > useful. >> > >> > Does anyone have any suggestions as to where to look? >> > Are there any known working examples of using >> vertex array objects and pyopengl >> > that I could cross check against? >> My go-to guess with almost any Python-differs-from-C >> problems during >> init is to look at the error-checking code. >> PyOpenGL's biggest >> difference from C code is that it runs error checking >> after every call. >> I'm guessing either your context isn't quite >> ready-to-go and you're >> getting an error from the error checking, or that the >> line before had an >> error and the error checking picked it up a line late. >> >> import OpenGL >> OpenGL.USE_ACCELERATE = False >> OpenGL.ERROR_CHECKING = False >> >> at the top of your script should let you quickly >> determine a) where the >> problem is b) whether the problem is with error checking. >> >> >> If I turn error checking off it dies much earlier on a >> glCreateShader call with: >> >> WARNING:OpenGL.errors:Failure on glCreateShader: >> Traceback (most recent call last): >> File >> "/usr/local/lib/python2.7/dist-packages/OpenGL/logs.py", >> line 74, in __call__ >> return function( *args, **named ) >> ArgumentError: argument 3: <type 'exceptions.TypeError'>: >> Don't know how to convert parameter 3 >> >> Traceback (most recent call last): >> File "main.py", line 237, in <module> >> main(sys.argv) >> File "main.py", line 227, in main >> init() >> File "main.py", line 147, in init >> init_program() >> File "main.py", line 122, in init_program >> vert = gl.VertexShader("data/shaders/basic.vert") >> File "/mnt/drive1/home/gordon/code/spacecraft2/gl.py", >> line 50, in __init__ >> _Shader.__init__(self, fname, VERTEX_SHADER) >> File "/mnt/drive1/home/gordon/code/spacecraft2/gl.py", >> line 37, in __init__ >> self.shader = createShader(shader_type) >> File >> "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", >> line 372, in __call__ >> return self( *args, **named ) >> File >> "/usr/local/lib/python2.7/dist-packages/OpenGL/logs.py", >> line 74, in __call__ >> return function( *args, **named ) >> ctypes.ArgumentError: argument 3: <type >> 'exceptions.TypeError'>: Don't know how to convert >> parameter 3 >> >> >> That doesn't seem like progress. >> >> With error checking on calling glGetError right before >> the glGenVertexArrays call returns 0. >> >> Toggling use accelerate hasn't made >> any noticeable difference. >> >> I don't know if it helps any but I turned on full logging >> and attached a dump of the output. >> >> G >> >> >> > > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > > -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Gordon W. <go...@to...> - 2011-11-08 11:46:24
Attachments:
broke.py
|
+list ---------- Forwarded message ---------- From: Gordon Wrigley <go...@to...> Date: Tue, Nov 8, 2011 at 10:45 PM Subject: Re: [PyOpenGL-Users] glGenVertexArrays producing 'invalid enumerant' error. To: "Mike C. Fletcher" <vrp...@gm...> I stripped my program right down to the bare minimum and condensed it into a single file, just 150 lines and 5 separate issues. The file as attached doesn't run for me. There are 5 if statements marked with XXX comments as you toggle each one another problem is resolved / worked around. After all 5 are toggled it runs and displays a single white triangle. In order those problems are: 1: enabling ERROR_CHECKING after importing OpenGL.GL causes glShaderSource to error with "Don't know how to convert parameter 3" 2: glGenVertexArrays is not wrapped 3: calling glGenVertexArrays through pyopengl causes a 1280 invalid enumerant 4: which moves to the following glBindVertexArray call when you call glGenVertexArrays through ctypes 5: glVertexAttribPointer will only accept a pointer for the last argument not the integer value you pass when using it with GL_ARRAY_BUFFER bound. I hope this aids in tracking down and resolving some of these problems. And I am by no means a GL expert so it wouldn't surprise me at all if one or more of these were my fault. G |
From: Gordon W. <go...@to...> - 2011-11-09 03:38:21
|
On an impulse I tried broke.py on another linux machine I have access to that has Nvidia drivers on it, the result was the same but the details differed. Particularly problems 2, 3 & 4 were replaced by this: Traceback (most recent call last): File "broke.py", line 145, in <module> main(sys.argv) File "broke.py", line 115, in main glBindVertexArray(vao) File "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", line 371, in __call__ if self.load(): File "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", line 351, in load if not platform.PLATFORM.checkExtension( self.extension ): File "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", line 246, in checkExtension result = extensions.hasGLExtension( name ) File "/usr/local/lib/python2.7/dist-packages/OpenGL/extensions.py", line 54, in hasGLExtension AVAILABLE_GL_EXTENSIONS[:] = glGetString( GL_EXTENSIONS ).split() AttributeError: 'NoneType' object has no attribute 'split' Version stuff for that machine: Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import OpenGL >>> OpenGL.__version__ '3.0.2a1' Linux gordonw-laptop 2.6.38-11-generic-pae #50-Ubuntu SMP Mon Sep 12 22:21:04 UTC 2011 i686 i686 i386 GNU/Linux OpenGL renderer string: Quadro NVS 160M/PCI/SSE2 OpenGL version string: 3.3.0 NVIDIA 270.41.06 OpenGL shading language version string: 3.30 NVIDIA via Cg compiler G On Tue, Nov 8, 2011 at 10:46 PM, Gordon Wrigley <go...@to...> wrote: > +list > > ---------- Forwarded message ---------- > From: Gordon Wrigley <go...@to...> > Date: Tue, Nov 8, 2011 at 10:45 PM > Subject: Re: [PyOpenGL-Users] glGenVertexArrays producing 'invalid > enumerant' error. > To: "Mike C. Fletcher" <vrp...@gm...> > > > I stripped my program right down to the bare minimum and condensed it into > a single file, just 150 lines and 5 separate issues. > The file as attached doesn't run for me. > There are 5 if statements marked with XXX comments as you toggle each one > another problem is resolved / worked around. > After all 5 are toggled it runs and displays a single white triangle. > > In order those problems are: > 1: enabling ERROR_CHECKING after importing OpenGL.GL causes glShaderSource > to error with "Don't know how to convert parameter 3" > 2: glGenVertexArrays is not wrapped > 3: calling glGenVertexArrays through pyopengl causes a 1280 invalid > enumerant > 4: which moves to the following glBindVertexArray call when you > call glGenVertexArrays through ctypes > 5: glVertexAttribPointer will only accept a pointer for the last argument > not the integer value you pass when using it with GL_ARRAY_BUFFER bound. > > I hope this aids in tracking down and resolving some of these problems. > And I am by no means a GL expert so it wouldn't surprise me at all if one > or more of these were my fault. > > G > > > |
From: Mike C. F. <vrp...@gm...> - 2011-11-09 04:33:44
Attachments:
broke.py
|
On 11-11-08 06:45 AM, Gordon Wrigley wrote: > I stripped my program right down to the bare minimum and condensed it > into a single file, just 150 lines and 5 separate issues. > The file as attached doesn't run for me. > There are 5 if statements marked with XXX comments as you toggle each > one another problem is resolved / worked around. > After all 5 are toggled it runs and displays a single white triangle. > > In order those problems are: > 1: enabling ERROR_CHECKING after importing OpenGL.GL > causes glShaderSource to error with "Don't know how to convert > parameter 3" Ouch, now I see what you are saying. Okay, that's actually not supported, and I would *expect* it to blow up. All of the config flags in the top-level OpenGL module are write-once and *must* be written before any sub-modules are imported. I need to document that more clearly and/or make a mechanism that can avoid having a half-configured system result if the flag is changed after load. You've got half the system configured to do error checking and the other half not; that's definitely going to blow up. > 2: glGenVertexArrays is not wrapped Ah, it is lacking a .output call, added to bzr trunk. Scanning the source tree there seem to be quite a few other glGen* operations that likely need some output wrapping, and the output wrappers likely want some love to make them less cumbersome to write (the lambdas just to create a tuple are a little silly). > 3: calling glGenVertexArrays through pyopengl causes a 1280 invalid > enumerant I'm pretty sure this is just an error showing up from elsewhere, on my machine with ERROR_CHECKING turned on I do not see the error. > 4: which moves to the following glBindVertexArray call when you > call glGenVertexArrays through ctypes Again, this seems to be because the error checking is reporting errors from earlier due to a wrapping failure. > 5: glVertexAttribPointer will only accept a pointer for the last > argument not the integer value you pass when using it > with GL_ARRAY_BUFFER bound. Yes, this is normally handled by either using GL.arrays.vbo.VBO instances (where vbo+offset gives you an offset pointer), or by manually creating a pointer using ctypes. Probably should look at having a special array handler type/method which does *not* convert integers into single-value arrays, but instead passes as a void_p to that address. > I hope this aids in tracking down and resolving some of these problems. > And I am by no means a GL expert so it wouldn't surprise me at all if > one or more of these were my fault. With the various fixes and changes in trunk, I can run the modified code (attached) without any errors on my machine, and it displays the expected triangle. Note: the changes to use the shaders module and the vbo.VBO class aren't required, they were just me eliminating sources of possible errors as I tested. Thank you very much for the effort and time taken to provide the test case. It was most helpful. Enjoy, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mike C. F. <vrp...@gm...> - 2011-11-10 02:44:58
|
On 11-11-08 10:38 PM, Gordon Wrigley wrote: > On an impulse I tried broke.py on another linux machine I have access > to that has Nvidia drivers on it, the result was the same but the > details differed. Particularly problems 2, 3 & 4 were replaced by this: > > Traceback (most recent call last): > File "broke.py", line 145, in <module> > main(sys.argv) > File "broke.py", line 115, in main > glBindVertexArray(vao) > File > "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", > line 371, in __call__ > if self.load(): > File > "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", > line 351, in load > if not platform.PLATFORM.checkExtension( self.extension ): > File > "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", > line 246, in checkExtension > result = extensions.hasGLExtension( name ) > File "/usr/local/lib/python2.7/dist-packages/OpenGL/extensions.py", > line 54, in hasGLExtension > AVAILABLE_GL_EXTENSIONS[:] = glGetString( GL_EXTENSIONS ).split() > AttributeError: 'NoneType' object has no attribute 'split' Hmm, without error checking that will return None if the entry point is not provided by the context (i.e. a core/forward-compatible-only context). That definitely will break. Thanks, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Gordon W. <go...@to...> - 2011-11-10 03:42:50
|
Enabling error checking did not change that particular failure. Are you suggesting that that machine may not have glBindVertexArray? That's a core function and the driver reports itself as 3.3.0 via glxinfo and lets me acquire a core 3.3 context via pyopengl glut. G On Thu, Nov 10, 2011 at 1:44 PM, Mike C. Fletcher <vrp...@gm...>wrote: > On 11-11-08 10:38 PM, Gordon Wrigley wrote: > > On an impulse I tried broke.py on another linux machine I have access > > to that has Nvidia drivers on it, the result was the same but the > > details differed. Particularly problems 2, 3 & 4 were replaced by this: > > > > Traceback (most recent call last): > > File "broke.py", line 145, in <module> > > main(sys.argv) > > File "broke.py", line 115, in main > > glBindVertexArray(vao) > > File > > "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", > > line 371, in __call__ > > if self.load(): > > File > > "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", > > line 351, in load > > if not platform.PLATFORM.checkExtension( self.extension ): > > File > > "/usr/local/lib/python2.7/dist-packages/OpenGL/platform/baseplatform.py", > > line 246, in checkExtension > > result = extensions.hasGLExtension( name ) > > File "/usr/local/lib/python2.7/dist-packages/OpenGL/extensions.py", > > line 54, in hasGLExtension > > AVAILABLE_GL_EXTENSIONS[:] = glGetString( GL_EXTENSIONS ).split() > > AttributeError: 'NoneType' object has no attribute 'split' > Hmm, without error checking that will return None if the entry point is > not provided by the context (i.e. a core/forward-compatible-only > context). That definitely will break. > > Thanks, > Mike > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > |
From: Mike C. F. <mcf...@vr...> - 2011-11-10 04:55:10
|
On 11-11-09 10:42 PM, Gordon Wrigley wrote: > Enabling error checking did not change that particular failure. > > Are you suggesting that that machine may not have glBindVertexArray? > That's a core function and the driver reports itself as 3.3.0 via > glxinfo and lets me acquire a core 3.3 context via pyopengl glut. Hmm, no, was suggesting that your machine was not providing a result from glGetString() because core doesn't support that, and instead wants you to use glGetStringi. However, if the result is not changing with error checking then my assumption is wrong. Possibly your driver is just ignoring the bad request, but not signalling an error? Well, something to guard against no matter what... and when I look at it, there *is* a guard against it that I would have expected to be in the current release (that is, AttributeError is explicitly checked on that line in the code). A bit stumped on that one, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |