Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=6339
Summary: Proposed fixes to glu/sgi/libnurbs
Product: Mesa
Version: 6.4
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: major
Priority: P3
Component: GLU
AssignedTo: [email protected]
ReportedBy: [EMAIL PROTECTED]
I have been working with and debugging the NURBS portion of SGI's
sample implementation of GLU and propose the following changes/fixes.
- The following is a bug fix. In ArcTessellator::tessellateNonlinear,
the initial value of j in the first for loop is incorrect. The
original code only works if the stride is 2, which is not the case
for homogenous coordinates.
libnurbs/internals/arctess.cc, Line 338:
for(i=1, j=2; i<bezierArc->order; i++, j+= bezierArc->stride)
Change to:
for(i=1, j=bezierArc->stride; i<bezierArc->order; i++, j+=
bezierArc->stride)
- The function monoTriangulationFun calls
monoTriangulationRecFun with zeroes for both of the current
indices to the inc_chain and dec_chain vertex arrays. If both of
these containers are empty (which can happen--did for me with one
surface), monoTriangulationRecFun will assert. I don't know
if this indicates a flaw in the data, but to avoid the assertion, I
added the following:
libnurbs/nurbtess/monoTriangulation.cc, Insert at line 622
(before call to monoTriangulationRecFun):
if (!(0 == inc_chain.getNumElements() && 0 ==
dec_chain.getNumElements()))
- Initialization of the member variable output_triangles of
the class OpenGLCurveEvaluator was overlooked. NURBS curves
won't render in a debug build because of this. Add the following
initialization in the constructor:
libnurbs/interface/glcurveval.cc, Insert at line 77:
output_triangles = 0; //don't output triangles by default
- The following change eliminates a compiler warning (using MS VC6).
Add the following delete operator to class PooledObj:
libnurbs/internals/bufpool.h, Insert at line 131:
inline void operator delete( void *, Pool & ) { assert( 0 ); }
Another problem this library has, which I have not yet debugged (and
may not get to), is that it does not render trimmed surfaces
correctly when using GLU_PARAMETRIC_ERROR for the sampling method.
The edges of the trim lines are rendered with far too few segments
(at least with NURBS trim curves--not sure about piecewise trim
curves).
Note: I posted the above remarks to both the comp.graphics.api.opengl newsgroup
and the OpenGL cading: advanced forum at OpenGL.org.
Thank you for your consideration.
John Shell
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
