Re: [PyOpenGL-Users] problems with glMap1f in pyopengl2
Brought to you by:
mcfletch
From: Mike C. F. <mcf...@ro...> - 2004-03-12 13:47:25
|
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/ |