Thread: [PyOpenGL-Users] GLUError and gluNurbsCurve
Brought to you by:
mcfletch
From: Ivo U. <iv...@iu...> - 2009-04-02 21:48:25
|
Hi, I'm trying to port my code from 2.x to 3.0 and everything seems to work except gluNurbsCurve. The problem is that in 2.x pyopengl gluNurbsCurve would raise GLUError exception when arguments were bad, but in 3.0 it doesn't raise any exceptions ( at least I see it that way). I would appreciate any help, -- Ivo Ugrina | Jab: gro.rebbajTAanirgui www.iugrina.com | ICQ: 47508335 |
From: Mike C. F. <mcf...@vr...> - 2009-04-04 00:34:17
|
Ivo Ugrina wrote: > Hi, > > I'm trying to port my code from 2.x to 3.0 > and everything seems to work except > gluNurbsCurve. > > The problem is that in 2.x pyopengl > gluNurbsCurve would raise GLUError exception > when arguments were bad, but in 3.0 it doesn't > raise any exceptions ( at least I see it that way). > > I would appreciate any help, > Can you give me some details as to what you mean by "bad arguments"? Do you mean values that are logically inconsistent (don't match the mathematics)? Or wrong enumerants/invalid options? I wouldn't be surprised if there was less checking in the current code, just not sure what particular checks the old code was doing. Good luck, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mike C. F. <mcf...@vr...> - 2009-04-04 18:46:04
|
Ivo Ugrina wrote: > Mike C. Fletcher wrote: > >> Can you give me some details as to what you mean by "bad arguments"? Do >> you mean values that are logically inconsistent (don't match the >> mathematics)? Or wrong enumerants/invalid options? >> > > For example 5 points of control polygon and > order 13 should raise exception GLUError, "too few knots" > or when I give a decreasing knot sequence it > should raise exception GLUError, "decreasing knot sequence" > > Here is a part of Knotvector::validate > from sgi implementation of glu (knotvector.cc) > Hmm, are you saying those ints are supposed to be returned as values from gluNurbsCurve? My manual says that it is supposed to have a void return type. Or is this supposed to show up in a glGetError return value? Basically I'm wondering whether these are supposed to be part of GLU or part of the wrapper? If they are part of GLU I don't yet know how to retrieve them. For now, I've added them to the wrapper and have them controlled by OpenGL.ERROR_CHECKING, so you can turn them off when your code is no longer producing invalid values and want to reclaim the performance. You should be able to check out current head via: bzr branch lp:pyopengl and check that the code now catches your errors. Thanks for the bug report, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Ivo U. <iv...@iu...> - 2009-04-08 12:51:09
|
Mike C. Fletcher wrote: > Hmm, are you saying those ints are supposed to be returned as values > from gluNurbsCurve? My manual says that it is supposed to have a void > return type. Or is this supposed to show up in a glGetError return > value? Basically I'm wondering whether these are supposed to be part of > GLU or part of the wrapper? If they are part of GLU I don't yet know > how to retrieve them. sorry for not responding earlier Mike (but better ever than never :D) No! gluNurbsCurve does not return int (it returns void). I've tracked error through (sgi) source and it goes like this: 1) *gluNurbsCurve* calls *nurbscurve* on GLUnurbs object 2) *nurbscurve* method creates knotvector object and calls *do_check_knots* function on that object 3) *do_check_knots* calls *knotvector::validate* method (which is the one I sent you) and puts the result in the status variable. If there is any error (status!=0) *do_nurbserror(status)* is called 4) *do_nurbs_error* calls *errorHandler* 5) *errorHandler* calls *postError* with appropriate GluError after this I'm not sure what comes next :( > > For now, I've added them to the wrapper and have them controlled by > OpenGL.ERROR_CHECKING, so you can turn them off when your code is no > longer producing invalid values and want to reclaim the performance. > You should be able to check out current head via: > > bzr branch lp:pyopengl > > and check that the code now catches your errors. > > Thanks for the bug report, > Mike > Ok. I'll test it this weekend have fun, -- Ivo Ugrina | Jab: gro.rebbajTAanirgui www.iugrina.com | ICQ: 47508335 ------------------------------------ baza matematickih pojmova http://baza.iugrina.com ------------------------------------ anime, manga, Japan fanzin http://yoshi.iugrina.com |