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

[Ralph G. <ral...@em...>]

Thanks for the fast answer.


On Friday, Mar 12, 2004, at 14:36 Europe/Berlin, Mike C. Fletcher wrote:
>

> 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).
>

The script I am running right now is a little to big, but I will try to 
get a minimal script and send it ASAP.
As to the datapoints I am passing, it is a list of 4 lists with three 
float values each.  Like that

     glMap1f(GL_MAP1_VERTEX_3, 0.0, 1.0, 
[[0.0,0.0,0.0],[100.0,100.0,0.0],[100.0,100.0,0.0],[200.0,200.0,0.0]])
OpenGL.GL.GLerror: [Errno 1281] invalid value

I also tried a lot of other combinations, but nothing worked so far. Is 
this matrix wrong?

Ralph

> 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/
>
>