Re: [PyOpenGL-Users] problems with glMap1f in pyopengl2

[Mike C. F. <mcf...@ro...>]

Ralph Gauges wrote:
...

> I recently started using pyopengl. So far I have written my program in 
> Debian which uses the old pyopengl 1.5.7.
> I uses the function glMap1f to draw some simple Bezier curves. In the 
> old pyopengl 1.5.7 it works just fine, but in the new version 2.0.1.07 
> which I installed on my apple, I can't get it to work.
> Yes I know, the number of arguments has changed from 6 to 4 and I 
> already removed the two extra arguments order and stride, but it still 
> does not work. I always get an error
>
>     glMap1f(GL_MAP1_VERTEX_3, 0.0, 1.0,  curve)
> OpenGL.GL.GLerror: [Errno 1281] invalid value
>
>
> I have no clue as to which value pyopengl thinks to be invalid.
> Could someone please tell me what I am missing?

It's not actually PyOpenGL that's complaining here, it's OpenGL itself.  
PyOpenGL is just a shim layer that passes things into the lower-level 
engine.  Looking around, I can't find any test code for glMap1f, so it's 
entirely possible this is some un-exercised bug in the shim for 
glMap1f.  It would be much easier to track down if you could put 
together a minimal script that produces the error (i.e. including the 
data-points array you're passing as well).

My best guess is that order (length of points in the array) is exceeding 
the system's maximum value or that you're passing it a string (which may 
even have worked in 1.5.7, as that was a very different code-base).

 From the manual, here's the situations where invalid value gets returned:

    * GL_INVALID_VALUE is generated if u1 is equal to u2.
    * GL_INVALID_VALUE is generated if stride is less than the number of
      values in a control point.
    * GL_INVALID_VALUE is generated if order is less than 1 or greater
      than the return value of GL_MAX_EVAL_ORDER.

So, in your case

    * u1 != u2, that's fine
    * potentially stride is being mis-calculated
          o if, for instance a string were being passed (which would
            have a calculated stride of -1 if I'm reading correctly, as
            it special-cases strings to avoid infinite recursion) it
            should complain about the negative stride, though that's not
            actually documented AFAICS
    * order is too large for the system

So, assuming you're passing an X by Y matrix where X=3 and Y=order 
(which is what points[][] in the method signature says is required); the 
shim code appears to be correct. It's passing stride as dimension 1 of 
the passed matrix (size of each element) and order as dimension 0 of the 
matrix (number of elements).

HTH,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/