When the NURBS tesselation facility of SGI-GLU is used, the OpenGL context that is active at the time of tesselation loses the ability to draw NURBS. The problem can be tracked down to /Mesa/src/glu/sgi/libnurbs/interface/glsurfeval.cc and glcurveval.cc where in bgnmap2f() and endmap2f() (bgnmap1f(), endmap1f()) no glPushAttrib(); glPopAttrib(); takes place in the case of tesselating (not drawing, read, output_triangles is true). If those functions do glPushAttrib(); glPopAttrib(); regardless of the value of output_triangles, the OpenGL context continues to be able to draw NURBS, even after the tesselation facility was in use. best regards, Randolf, -- http://www.ayam3d.org/ Ayam, where skins are skins!
Would it be better to add a new flag that's set iff glPushAttrib() is called, then in endmap2f(), check if the flag is set to determine if glPopAttrib() should be called? glPush/PopAttrib() is kind of expensive.
Since glPushAttrib((GLbitfield) GL_EVAL_BIT);/glPopAttrib(); also are done here when drawing NURBS, the performance impact can not be that high; furthermore, when just tesselating, performance is not a critical issue. But of course it is nice, when things can be made efficient with only small effort. One more efficient way would be to use a flag to let push/pop happen only once per NURBS primitive (but this approach is maybe too complicated: how to detect the last call to endmap2f()?), another way would be to generally do a push/pop per NURBS primitive in a higher level of GLU, e.g. in glinterface.cc/gluBeginSurface(),gluEndSurface(). How about that? best regards, Randolf, -- http://www.ayam3d.org/ Ayam, we take NURBS seriously!
Why don't you just submit a patch for what you think is best. I've never looked at this code in any detail and I don't have time to study it now. Thanks.
Created attachment 5925 [details] [review] patch to fix GLU Bug 6891
I have attached a patch that changes glusurfeval.cc as I think best. kind regards, Randolf, -- http://www.ayam3d.org/ Ayam, parametric NURBS modeling.
I've patched glsurfeval.cc. Is a similar fix needed for glcurveval.cc?
Hello Brian, contrary to my first posting, glcurveval.cc does not need to be patched as it never uses the OpenGL evaluator but only the GLU internal one (in case of tesselation, not drawing). best regards, Randolf, -- http://www.ayam3d.org/ Ayam, where sweeps don't flip.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.