mesa3d-dev

[Mesa3d-dev] bug in sphere normal

[Stephen T. <ste...@sf...>]

Hi Brian and all!


There seems to be a bug in calculating normals of a sphere in
src-glu/quadric.c. I cannot track down the exact problem or find a
fix, but the following screenshots (one from mesa 3.4, one from sgi
opengl of xfree86 4.0) obviously show something. Note the highlights
of the spheres.

http://www.sfu.ca/~stephent/tmp/mesa-sphere.gif
http://www.sfu.ca/~stephent/tmp/sgi-sphere.gif


The code is accanti.c from redbook. I can easily reproduce the bug
with another simplified code. Normals of spheres at origin (no
translation or rotation, quadric.c from redbook) *seem* to be okay.

http://trant.sgi.com/opengl/examples/redbook/redbook.html


Also, a (very) minor patch is to remove `TXTR_COORD' calls because of
`!qobj->TextureFlag' condition in the branches.


#define TXTR_COORD(x,y)    if (qobj->TextureFlag) glTexCoord2f(x,y);


Around line 404 in src-glu/quadric.c,

      if (!qobj->TextureFlag) {
	 /* draw +Z end as a triangle fan */
	 glBegin(GL_TRIANGLE_FAN);
	 glNormal3f(0.0, 0.0, 1.0);
	 TXTR_COORD(0.5, 1.0);


Around line 461 in src-glu/quadric.c,

      if (!qobj->TextureFlag) {
	 /* draw -Z end as a triangle fan */
	 glBegin(GL_TRIANGLE_FAN);
	 glNormal3f(0.0, 0.0, -1.0);
	 TXTR_COORD(0.5, 0.0);


Cheers,
Stephen

Re: [Mesa3d-dev] bug in sphere normal

[Brian P. <br...@va...>]

Stephen Tse wrote:
> 
> Hi Brian and all!
> 
> There seems to be a bug in calculating normals of a sphere in
> src-glu/quadric.c. I cannot track down the exact problem or find a
> fix, but the following screenshots (one from mesa 3.4, one from sgi
> opengl of xfree86 4.0) obviously show something. Note the highlights
> of the spheres.
> 
> http://www.sfu.ca/~stephent/tmp/mesa-sphere.gif
> http://www.sfu.ca/~stephent/tmp/sgi-sphere.gif

How do they compare when you enable smooth shading for the sphere?

It may be that because of the vertex order for the triangle strips
being different, that a different provoking vertex is being used
for filling each facet.

The GLU spec doesn't say exactly how the triangle (or quad) strips
are to be oriented in gluSphere so this might be an allowable
variation.


> The code is accanti.c from redbook. I can easily reproduce the bug
> with another simplified code. Normals of spheres at origin (no
> translation or rotation, quadric.c from redbook) *seem* to be okay.
> 
> http://trant.sgi.com/opengl/examples/redbook/redbook.html
> 
> Also, a (very) minor patch is to remove `TXTR_COORD' calls because of
> `!qobj->TextureFlag' condition in the branches.
> 
> #define TXTR_COORD(x,y)    if (qobj->TextureFlag) glTexCoord2f(x,y);
> 
> Around line 404 in src-glu/quadric.c,
> 
>       if (!qobj->TextureFlag) {
>          /* draw +Z end as a triangle fan */
>          glBegin(GL_TRIANGLE_FAN);
>          glNormal3f(0.0, 0.0, 1.0);
>          TXTR_COORD(0.5, 1.0);
> 
> Around line 461 in src-glu/quadric.c,
> 
>       if (!qobj->TextureFlag) {
>          /* draw -Z end as a triangle fan */
>          glBegin(GL_TRIANGLE_FAN);
>          glNormal3f(0.0, 0.0, -1.0);
>          TXTR_COORD(0.5, 0.0);
> 

Thanks.  My plan is to replace Mesa's GLU with the SI GLU someday
(when I find time).

-Brian

Re: [Mesa3d-dev] bug in sphere normal

[Stephen T. <ste...@sf...>]

Brian Paul <br...@va...> writes:

> 
> How do they compare when you enable smooth shading for the sphere?
> 

Oddly, they look the same when smooth shaded. Why?? Then, it's not the
problem of the normal?


> It may be that because of the vertex order for the triangle strips
> being different, that a different provoking vertex is being used
> for filling each facet.

Can that be fixed?

> 
> The GLU spec doesn't say exactly how the triangle (or quad) strips
> are to be oriented in gluSphere so this might be an allowable
> variation.

Variation? But this is a huge visible discrepancy, though. I draw the
box in the light source position. It seems that the specular
reflection is more "accurate" in sgi glu. I can't say for sure though.


> Thanks.  My plan is to replace Mesa's GLU with the SI GLU someday
> (when I find time).

You mean SGI open-source reference implementation? Their code style is
horrible because of over-optimization. Honestly, I like Mesa code much
better. It is more readable.


- Stephen

Re: [Mesa3d-dev] bug in sphere normal

[Brian P. <br...@va...>]

Stephen Tse wrote:
> 
> Brian Paul <br...@va...> writes:
> 
> >
> > How do they compare when you enable smooth shading for the sphere?
> >
> 
> Oddly, they look the same when smooth shaded. Why?? Then, it's not the
> problem of the normal?

It's not odd at all.  The color at each vertex is being computed
correctly, and identically by both OpenGL implementations.

It's just that when you're flat-shading that a different vertex
is being chosen to color each quadrilateral.  This is probably due
to the quad strips being drawn in a different order in the two
gluSphere() implementations.


> > It may be that because of the vertex order for the triangle strips
> > being different, that a different provoking vertex is being used
> > for filling each facet.
> 
> Can that be fixed?

You could modify gluSphere() to compute/draw the vertices in reverse
order (or some other order).  I haven't compared Mesa's gluSphere()
to the SI's version so I can't say exactly.


> > The GLU spec doesn't say exactly how the triangle (or quad) strips
> > are to be oriented in gluSphere so this might be an allowable
> > variation.
> 
> Variation? But this is a huge visible discrepancy, though. I draw the
> box in the light source position. It seems that the specular
> reflection is more "accurate" in sgi glu. I can't say for sure though.

It's an unfortunate variation.  But as I said, I don't think the GLU
spec goes into that much detail.


> > Thanks.  My plan is to replace Mesa's GLU with the SI GLU someday
> > (when I find time).
> 
> You mean SGI open-source reference implementation? Their code style is
> horrible because of over-optimization. Honestly, I like Mesa code much
> better. It is more readable.

But Mesa's GLU tessellator and NURBS code isn't nearly as good as the
SI code.

-Brian

Re: [Mesa3d-dev] bug in sphere normal

[Stephen T. <ste...@sf...>]

Brian Paul <br...@va...> writes:

> It's not odd at all.  The color at each vertex is being computed
> correctly, and identically by both OpenGL implementations.
> 
> It's just that when you're flat-shading that a different vertex
> is being chosen to color each quadrilateral.  This is probably due
> to the quad strips being drawn in a different order in the two
> gluSphere() implementations.

... I see...


> > Can that be fixed?
> 
> You could modify gluSphere() to compute/draw the vertices in reverse
> order (or some other order).  I haven't compared Mesa's gluSphere()
> to the SI's version so I can't say exactly.

You're totoally right. I simply modify it to draw slices in reverse
order and get the identical result as sgi glu produces. Great!


> It's an unfortunate variation.  But as I said, I don't think the GLU
> spec goes into that much detail.

I beg to differ. The spec does not say anything but it does not mean
the discrepancy is allowable in reality. I setup and rotate/move the
light position around and find sgi's more "accurate". But, again, I am
not an expert enough to say anything definite.

BTW, does the conformance test (which covers GL part for sure) cover
GLU and GLUT parts as well?


> But Mesa's GLU tessellator and NURBS code isn't nearly as good as the
> SI code.

Can you be more specific? As a matter of fact, I am studying closely
the codes of mesa's glu for personal interests. SGI's codes are not
meant for easy human reading.

Re: [Mesa3d-dev] bug in sphere normal

[Brian P. <br...@va...>]

Stephen Tse wrote:
> 
> Brian Paul <br...@va...> writes:
> 
> > It's not odd at all.  The color at each vertex is being computed
> > correctly, and identically by both OpenGL implementations.
> >
> > It's just that when you're flat-shading that a different vertex
> > is being chosen to color each quadrilateral.  This is probably due
> > to the quad strips being drawn in a different order in the two
> > gluSphere() implementations.
> 
> ... I see...
> 
> > > Can that be fixed?
> >
> > You could modify gluSphere() to compute/draw the vertices in reverse
> > order (or some other order).  I haven't compared Mesa's gluSphere()
> > to the SI's version so I can't say exactly.
> 
> You're totoally right. I simply modify it to draw slices in reverse
> order and get the identical result as sgi glu produces. Great!
> 
> > It's an unfortunate variation.  But as I said, I don't think the GLU
> > spec goes into that much detail.
> 
> I beg to differ. The spec does not say anything but it does not mean
> the discrepancy is allowable in reality. I setup and rotate/move the
> light position around and find sgi's more "accurate". But, again, I am
> not an expert enough to say anything definite.

Well, when I first wrote gluSphere() I didn't have the SI code to
compare to.  And, I don't recall comparing SGI's gluSphere to Mesa's
gluSphere at that level of attention.

If you rotate/transform the sphere in the right way, you may find
that Mesa's gluSphere looks "more accurate".


> BTW, does the conformance test (which covers GL part for sure) cover
> GLU and GLUT parts as well?

GLU, but not in too much detail.  GLUT has its own set of self-test
programs.


> > But Mesa's GLU tessellator and NURBS code isn't nearly as good as the
> > SI code.
> 
> Can you be more specific? As a matter of fact, I am studying closely
> the codes of mesa's glu for personal interests. SGI's codes are not
> meant for easy human reading.

Mesa's polygon tessellator doesn't have the GLU 1.2 features.
Gareth Hughes worked on this for a while but didn't have time to
complete the work.  I'm sure he'd agree that it's a big job.
Also Mesa's GLU NURBS tessellator doesn't handle trimming or a
few other features.

-Brian

Re: [Mesa3d-dev] bug in sphere normal

[Stephen T. <ste...@sf...>]

Brian Paul <br...@va...> writes:

> Well, when I first wrote gluSphere() I didn't have the SI code to
> compare to.  And, I don't recall comparing SGI's gluSphere to Mesa's
> gluSphere at that level of attention.

What's SI code? standard code?

> 
> If you rotate/transform the sphere in the right way, you may find
> that Mesa's gluSphere looks "more accurate".

Okay =).


> > BTW, does the conformance test (which covers GL part for sure) cover
> > GLU and GLUT parts as well?
> 
> GLU, but not in too much detail.  GLUT has its own set of self-test
> programs.

The conformance test is available only to the OpenGL licensee, right?
How can Mesa get access to it? Via your company, valinux?

Do you know if there is an open-source equivalent for the test suits?
glean is one of them, but it's not actively maintained anymore, I'm
afriad. 


- Stephen

Re: [Mesa3d-dev] bug in sphere normal

[Allen A. <ak...@po...>]

On Tue, Jan 16, 2001 at 06:35:38PM -0800, Stephen Tse wrote:
| Do you know if there is an open-source equivalent for the test suits?
| glean is one of them, but it's not actively maintained anymore, I'm
| afriad. 

Glean is still under active development, but not very many people
have contributed tests.  Would you like to? :-)

(BTW, you're correct that there hasn't been an official "release" of
glean in a long time.  However, that's partly because it's relatively
convenient to get a copy of the current code by checking it out from
the CVS tree.)

Allen

Re: [Mesa3d-dev] bug in sphere normal

[Gareth H. <ga...@va...>]

Brian Paul wrote:
> 
> > > But Mesa's GLU tessellator and NURBS code isn't nearly as good as the
> > > SI code.
> >
> > Can you be more specific? As a matter of fact, I am studying closely
> > the codes of mesa's glu for personal interests. SGI's codes are not
> > meant for easy human reading.
> 
> Mesa's polygon tessellator doesn't have the GLU 1.2 features.
> Gareth Hughes worked on this for a while but didn't have time to
> complete the work.  I'm sure he'd agree that it's a big job.
> Also Mesa's GLU NURBS tessellator doesn't handle trimming or a
> few other features.

*shudder*

Oh yes, it's a large problem.  Thankfully, I actually understand it now
and could do a much better job of updating Mesa's GLU than the previous
attempt.

However, with the SI code publicly available, there isn't as much of a
need for this to be done.  I've got a lot of other things to work on, so
this would be near the bottom of my TODO list (if it were on there at
all).

-- Gareth

Re: [Mesa3d-dev] bug in sphere normal

[Brian P. <br...@va...>]

Stephen Tse wrote:
> 
> Brian Paul <br...@va...> writes:
> 
> > Well, when I first wrote gluSphere() I didn't have the SI code to
> > compare to.  And, I don't recall comparing SGI's gluSphere to Mesa's
> > gluSphere at that level of attention.
> 
> What's SI code? standard code?

Sample Implementation.  http://oss.sgi.com/projects/ogl-sample/


> > If you rotate/transform the sphere in the right way, you may find
> > that Mesa's gluSphere looks "more accurate".
> 
> Okay =).
> 
> > > BTW, does the conformance test (which covers GL part for sure) cover
> > > GLU and GLUT parts as well?
> >
> > GLU, but not in too much detail.  GLUT has its own set of self-test
> > programs.
> 
> The conformance test is available only to the OpenGL licensee, right?
> How can Mesa get access to it? Via your company, valinux?

I've got the conformance tests.


> Do you know if there is an open-source equivalent for the test suits?
> glean is one of them, but it's not actively maintained anymore, I'm
> afriad.

Where'd you get that idea?  Glean's been pretty active in the past
few months.

-Brian