Re: [PyOpenGL-Users] glGenVertexArrays producing 'invalid enumerant' error.

[Mike C. F. <vrp...@gm...>]

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