Bug 6891

Summary:	SGI-GLU, NURBS tesselator confuses OpenGL attribute state
Product:	Mesa	Reporter:	Randolf Schultz <rschultz>
Component:	GLU	Assignee:	mesa-dev
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	high
Version:	6.5
Hardware:	All
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	patch to fix GLU Bug 6891

Description Randolf Schultz 2006-05-11 15:07:20 UTC

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!

Comment 1 Brian Paul 2006-05-12 00:00:04 UTC

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.

Comment 2 Randolf Schultz 2006-05-12 11:52:55 UTC

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!

Comment 3 Brian Paul 2006-05-13 00:04:44 UTC

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.

Comment 4 Randolf Schultz 2006-06-15 20:09:28 UTC

Created attachment 5925 [details] [review]
patch to fix GLU Bug 6891

Comment 5 Randolf Schultz 2006-06-15 20:10:47 UTC

I have attached a patch that changes glusurfeval.cc as I think best.

kind regards,
Randolf,
-- 
http://www.ayam3d.org/    Ayam, parametric NURBS modeling.

Comment 6 Brian Paul 2006-06-16 06:46:11 UTC

I've patched glsurfeval.cc.  Is a similar fix needed for glcurveval.cc?

Comment 7 Randolf Schultz 2006-06-16 07:08:59 UTC

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.