mesa3d-dev

Re: [Mesa3d-dev] bug in sphere normal

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

Dieter Nützel 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.
> >
> > -Brian
> 
> Sorry, that I step in, but...
> 
> I am under the impression that Gareth Hughes GLU 1.2 work was one of the best
> things ever on this.
> With the current GLU (and the SGI SI one, taken from the Mesa3D site) I never
> got "tessdemo" working the right way. Especially when I draw a "figure" with
> one or more self intersections I get only this:
> 
> "FIST recovery process fatal error"
> 
> Second, "xlockmore" (mode "text3d") crash all the time with the current Mesa
> GLU. (The self intersections?)
> 
> SunWave1>xlock -nolock -mode text3d -ttfont /usr/X11/lib/fonts/ttf/arial.ttf
> Segmentation fault (core dumped)
> 
> Reading symbols from /usr/lib/libstdc++-libc6.2-2.so.3...done.
> Reading symbols from /lib/libm.so.6...done.
> Reading symbols from /lib/libc.so.6...done.
> Reading symbols from /usr/lib/libstdc++-libc6.1-2.so.3...done.
> Reading symbols from /lib/libpthread.so.0...done.
> Reading symbols from /lib/libdl.so.2...done.
> Reading symbols from /lib/ld-linux.so.2...done.
> Reading symbols from /lib/libnss_compat.so.2...done.
> Reading symbols from /lib/libnsl.so.1...done.
> Reading symbols from /usr/X11R6/lib/modules/dri/tdfx_dri.so...done.
> Reading symbols from /usr/lib/libglide3.so.3...done.
> #0  0x402e9b21 in chunk_free () from /lib/libc.so.6
> (gdb) bt
> #0  0x402e9b21 in chunk_free () from /lib/libc.so.6
> #1  0x402e97d2 in chunk_alloc () from /lib/libc.so.6
> #2  0x402e8f91 in malloc () from /lib/libc.so.6
> #3  0x401598df in XGetVisualInfo () from /usr/X11R6/lib/libX11.so.6
> #4  0x81018bd in matherr ()
> #5  0x80547c4 in matherr ()
> #6  0x80501f7 in error ()
> #7  0x8051eb4 in error ()
> #8  0x4029509f in __libc_start_main () from /lib/libc.so.6
> 
> Yes, I "see" that it fails in glide3 (without 3DNow!) but it worked last
> summer...
> 
> Gareth's code could handle this all.


But other people had more trouble with Gareth's code than either the
old Mesa tessellator or the SI tessellator.

Ideally, someone will fix whatever bugs there may be in the SI
tessellator.

-Brian

RE: [Mesa3d-dev] bug in sphere normal

[Dieter <Die...@ha...>]

> > > 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

Sorry, that I step in, but...

I am under the impression that Gareth Hughes GLU 1.2 work was one of the best 
things ever on this.
With the current GLU (and the SGI SI one, taken from the Mesa3D site) I never 
got "tessdemo" working the right way. Especially when I draw a "figure" with 
one or more self intersections I get only this:

"FIST recovery process fatal error"

Second, "xlockmore" (mode "text3d") crash all the time with the current Mesa 
GLU. (The self intersections?)

SunWave1>xlock -nolock -mode text3d -ttfont /usr/X11/lib/fonts/ttf/arial.ttf
Segmentation fault (core dumped)

Reading symbols from /usr/lib/libstdc++-libc6.2-2.so.3...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /usr/lib/libstdc++-libc6.1-2.so.3...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_compat.so.2...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/X11R6/lib/modules/dri/tdfx_dri.so...done.
Reading symbols from /usr/lib/libglide3.so.3...done.
#0  0x402e9b21 in chunk_free () from /lib/libc.so.6
(gdb) bt
#0  0x402e9b21 in chunk_free () from /lib/libc.so.6
#1  0x402e97d2 in chunk_alloc () from /lib/libc.so.6
#2  0x402e8f91 in malloc () from /lib/libc.so.6
#3  0x401598df in XGetVisualInfo () from /usr/X11R6/lib/libX11.so.6
#4  0x81018bd in matherr ()
#5  0x80547c4 in matherr ()
#6  0x80501f7 in error ()
#7  0x8051eb4 in error ()
#8  0x4029509f in __libc_start_main () from /lib/libc.so.6

Yes, I "see" that it fails in glide3 (without 3DNow!) but it worked last 
summer...

Gareth's code could handle this all.

-Dieter

Re: [Mesa3d-dev] _swsetup_RenderPrimNoop

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

Jouk,

Try another cvs update.  osmesa.c should be OK now.

-Brian

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:

> 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] autoconfmake bugs fixed

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

Lee Brown wrote:
> 
> On Sun, 07 Jan 2001, Sven M. Hallberg wrote:
> 
> > -- FYI --
> > Here are the versions the programs themselves report:
> >
> > Autoconf: autoconf (GNU autoconf) 2.49c
> > Automake: automake (GNU automake) 1.4c
> > Libtool: ltmain.sh (GNU libtool) 1.3c (1.851 2001/01/05 09:33:38)
> 
> Sven,
> 
> I tried the latest from these cvs repositories and I failed to build libtool.
> 
> ltmain.sh (GNU libtool) 1.3c (1.852 2001/01/08 01:52:10)
> 
> I managed to get the above versions of autoconf and automake to build however.
> 
> Can download (or anybody) download the latest libtool and get it to work?
> 
> I get the following errors.
> 
> lee@darkstar:~/cvs/libtool$ ./bootstrap
> configure:5820: error: undefined macro: AR_FLAGS
> autoheader: config.h.in is unchanged
> configure.in: 33: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
> configure:6074: error: undefined macro: AR_FLAGS
> configure.in: 10: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
> Makefile.am:126: variable `libdir' not defined
> Makefile.am:130: variable `libdir' not defined
> configure:5650: error: undefined macro: AR_FLAGS
> configure.in: 8: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
> configure:5478: error: undefined macro: AR_FLAGS
> configure.in: 16: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
> configure:5971: error: undefined macro: AR_FLAGS
> configure.in: 8: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
> configure:5478: error: undefined macro: AR_FLAGS
> 
> <gripe>
> I understand that it might be useful to have the latest
> autoconf/automake/libtool set,  but why not use the latest stable releases
> rather than the latest bleeding edge tools? It seems to me this would take out
> one more source of bugs in the code.  I also have to do four cvs updates just
> to get mesa to work rather than one.  Perhaps mesa is such a special library
> that it requires the latest and greatest,  but I really doubt it. I may add
> this is coming from somebody who considers himself pretty good at automake.
> </gripe>

I haven't had time to try the new tools and ./bootstrap but I'm
concerned about needing bleeding-edge tools.  Why are these
development versions of libtool, etc needed?

-Brian

Re: [Mesa3d-dev] autoconfmake bugs fixed

[Lee B. <le...@i-...>]

On Sun, 07 Jan 2001, Sven M. Hallberg wrote:

> -- FYI --
> Here are the versions the programs themselves report:
> 
> Autoconf: autoconf (GNU autoconf) 2.49c
> Automake: automake (GNU automake) 1.4c
> Libtool: ltmain.sh (GNU libtool) 1.3c (1.851 2001/01/05 09:33:38)

Sven,

I tried the latest from these cvs repositories and I failed to build libtool.

ltmain.sh (GNU libtool) 1.3c (1.852 2001/01/08 01:52:10)   

I managed to get the above versions of autoconf and automake to build however.  

Can download (or anybody) download the latest libtool and get it to work?

I get the following errors.
 
lee@darkstar:~/cvs/libtool$ ./bootstrap
configure:5820: error: undefined macro: AR_FLAGS
autoheader: config.h.in is unchanged
configure.in: 33: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
configure:6074: error: undefined macro: AR_FLAGS
configure.in: 10: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
Makefile.am:126: variable `libdir' not defined
Makefile.am:130: variable `libdir' not defined
configure:5650: error: undefined macro: AR_FLAGS
configure.in: 8: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
configure:5478: error: undefined macro: AR_FLAGS
configure.in: 16: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
configure:5971: error: undefined macro: AR_FLAGS
configure.in: 8: `AM_PROG_LIBTOOL' is obsolete, use `AC_PROG_LIBTOOL' instead
configure:5478: error: undefined macro: AR_FLAGS      

<gripe>
I understand that it might be useful to have the latest
autoconf/automake/libtool set,  but why not use the latest stable releases
rather than the latest bleeding edge tools? It seems to me this would take out
one more source of bugs in the code.  I also have to do four cvs updates just
to get mesa to work rather than one.  Perhaps mesa is such a special library
that it requires the latest and greatest,  but I really doubt it. I may add
this is coming from somebody who considers himself pretty good at automake.
</gripe>

Thanks ahead for any assistance.
Lee

-- 
Lee Brown Jr.
le...@i-...

Re: [Mesa3d-dev] _swsetup_RenderPrimNoop

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

"Jacob (=Jouk) Jansen" wrote:
> 
> br...@va... wrote at 16-JAN-2001 16:19:43.14
> 
> >I don't see a problem.  _swsetup_RenderPrimNoop() is defined in
> >swrast_setup/swrast_setup.h and that header is being included by
> >osmesa.c
> >
> >Jouk, are you sure all your sources are up to date?
> The version I got from the CVS this morning does not contain
> _swsetup_RenderPrimNoop. I just checked and there was no update until now.
> 
>               Jouk

OK.  I just did an update to get Keith's latest changes and I have
the same problem now.  Apparently he removed that function but
didn't update the osmesa.c file.

Let's wait for him to fix it.

In the mean time, you can just comment-out that line, though osmesa
will crash.

-Brian

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] _swsetup_RenderPrimNoop

[<jo...@hr...>]

br...@va... wrote at 16-JAN-2001 16:19:43.14

>I don't see a problem.  _swsetup_RenderPrimNoop() is defined in
>swrast_setup/swrast_setup.h and that header is being included by
>osmesa.c
>
>Jouk, are you sure all your sources are up to date?
The version I got from the CVS this morning does not contain
_swsetup_RenderPrimNoop. I just checked and there was no update until now.

              Jouk



sm43-jj) ls -al
total 152
drwx--S---   3 joukj    staff        512 Jan 16 08:26 .
drwx--S---  24 joukj    staff       4608 Jan 15 08:54 ..
drwx--S---   2 joukj    staff        512 Jan 16 08:26 CVS
-rw-------   1 joukj    staff        374 Jan 02 07:54 Makefile.am
-rw-------   1 joukj    staff       2964 Nov 05 19:20 NOTES
-rw-------   1 joukj    staff       4152 Jan 16 08:26 ss_context.c
-rw-------   1 joukj    staff       2038 Jan 16 08:26 ss_context.h
-rw-------   1 joukj    staff       7726 Jan 16 08:26 ss_triangle.c
-rw-------   1 joukj    staff       1417 Nov 22 09:21 ss_triangle.h
-rw-------   1 joukj    staff       5435 Jan 16 08:26 ss_tritmp.h
-rw-------   1 joukj    staff       8092 Jan 02 07:54 ss_vb.c
-rw-------   1 joukj    staff       1408 Nov 22 09:21 ss_vb.h
-rw-------   1 joukj    staff       3959 Jan 15 08:54 ss_vbtmp.h
-rw-------   1 joukj    staff       2314 Jan 16 08:26 swrast_setup.h



Bush : All votes are equal but some votes are more equal than others.

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

Re: [Mesa3d-dev] _swsetup_RenderPrimNoop

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

Keith Whitwell wrote:
> 
> "Jacob (=Jouk) Jansen" wrote:
> >
> > Hi all,
> >
> > I have problems compiling osmesa.c from todays CVS. What is missing?
> >
> > cc /include=([-.include],[])/define=(PTHREADS=1)/name=(as_is,short) /obj=[.osmes
> > a]osmesa.obj [.osmesa]osmesa.c
> >
> >    ctx->Driver.RenderPrimitive = _swsetup_RenderPrimNoop;
> > .................................^
> > %CC-E-UNDECLARED, In this statement, "_swsetup_RenderPrimNoop" is not declared.
> > at line number 1714 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20010116.MESA.SRC.O
> > SMESA]OSMESA.C;1
> > %MMS-F-ABORT, For target [.OSMESA]OSMESA.OBJ, CLI returned abort status: %X10B91
> > 262.
> 
> I haven't been as active keeping osmesa.c uptodate with the changes I'm
> making.  I'll try and patch it today if nobody gets there first.

I don't see a problem.  _swsetup_RenderPrimNoop() is defined in
swrast_setup/swrast_setup.h and that header is being included by
osmesa.c

Jouk, are you sure all your sources are up to date?

-Brian

Re: [Mesa3d-dev] _swsetup_RenderPrimNoop

[Keith W. <ke...@va...>]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi all,
> 
> I have problems compiling osmesa.c from todays CVS. What is missing?
> 
> cc /include=([-.include],[])/define=(PTHREADS=1)/name=(as_is,short) /obj=[.osmes
> a]osmesa.obj [.osmesa]osmesa.c
> 
>    ctx->Driver.RenderPrimitive = _swsetup_RenderPrimNoop;
> .................................^
> %CC-E-UNDECLARED, In this statement, "_swsetup_RenderPrimNoop" is not declared.
> at line number 1714 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20010116.MESA.SRC.O
> SMESA]OSMESA.C;1
> %MMS-F-ABORT, For target [.OSMESA]OSMESA.OBJ, CLI returned abort status: %X10B91
> 262.

I haven't been as active keeping osmesa.c uptodate with the changes I'm
making.  I'll try and patch it today if nobody gets there first.

Keith

[Mesa3d-dev] _swsetup_RenderPrimNoop

[<jo...@hr...>]

Hi all,

I have problems compiling osmesa.c from todays CVS. What is missing?

cc /include=([-.include],[])/define=(PTHREADS=1)/name=(as_is,short) /obj=[.osmes
a]osmesa.obj [.osmesa]osmesa.c

   ctx->Driver.RenderPrimitive = _swsetup_RenderPrimNoop;
.................................^
%CC-E-UNDECLARED, In this statement, "_swsetup_RenderPrimNoop" is not declared.
at line number 1714 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20010116.MESA.SRC.O
SMESA]OSMESA.C;1
%MMS-F-ABORT, For target [.OSMESA]OSMESA.OBJ, CLI returned abort status: %X10B91
262.


                Jouk


Bush : All votes are equal but some votes are more equal than others.

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  jo...@hr...

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2781536                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<

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:
> 
> 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

[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

[Mesa3d-dev] Re: [Mesa3d-cvs] 'Mesa/docs VERSIONS'

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

br...@so... wrote:
> 
> Update of /cvsroot/mesa3d/Mesa/docs
> In directory usw-pr-cvs1:/tmp/cvs-serv21682
> 
> Modified Files:
>       Tag: mesa_3_4_branch
>         VERSIONS
> Log Message:
> moved GL_EXT_texture_env_dot3 item

Oops, sorry.  It was rather late ;-)

-- Gareth

Re: [Mesa3d-dev] autoconfmake bugs fixed

[Marcelo E. M. <mar...@bi...>]

>> "Sven M. Hallberg" <pe...@gm...> writes:

 > I follow the development of autoconf, automake, and libtool pretty closely,
 > because they're adding nifty features all the time. I've used some of these 
 > features in the process of updating Mesa's configure.in and Makefile.am's.

 I'm sure everyone appreciates your work (I do), but using unreleased
 tools kinda makes it difficult for people to actually *test* stuff.  I
 was trying to build Mesa 3.4 with some of the bells and whistles (GGI,
 glide2, glide3) and found out it won't build.  Among the problems, I
 found some of the Makefile.am are wrong.  I pulled new Makefile.am's
 and configure.in from CVS to see if the problems had been dealt with
 already, just to find out that that I needed to hunt for some special
 version of automake and libtool.

 Since one of the new features you have used is something I have wished
 for myself, I can understand why using it is desirable, but...

 (I'll send a patch for Mesa 3.4 sometime this week, I still need to
 figure out the glide2 problems first)

--
Marcelo

Re: [Mesa3d-dev] autoconfmake bugs fixed

[Sven M. H. <pe...@gm...>]

On Fri, Jan 05, 2001 at 09:10:11AM -0700, Brian Paul wrote:
> > Regards,
> > Sven
> > 
> > PS: I've used the very latest versions of autoconf, automake, and libtool from
> > their respective CVS repositories. This is reflected in some changes. So be
> > sure to get those before you try to run the bootstrap script!
> 
> Could you tell us which versions you're using?

I follow the development of autoconf, automake, and libtool pretty closely,
because they're adding nifty features all the time. I've used some of these 
features in the process of updating Mesa's configure.in and Makefile.am's.

-- FYI --
Here are the versions the programs themselves report:

Autoconf: autoconf (GNU autoconf) 2.49c
Automake: automake (GNU automake) 1.4c
Libtool: ltmain.sh (GNU libtool) 1.3c (1.851 2001/01/05 09:33:38)

And these are the commands I used to retrieve the package sources from the
appropriate CVS repositories, quoted directly from the respective web pages:

Autoconf (quoting from http://sources.redhat.com/autoconf/):
 cvs -z9 -d :pserver:an...@su...:/cvs login
 {empty password}
 cvs -z9 -d :pserver:an...@su...:/cvs checkout autoconf

Automake (quoting from http://sources.redhat.com/automake/):
 cvs -z 9 -d :pserver:an...@an...:/cvs/automake login
     (password is ``anoncvs'')
 cvs -z 9 -d :pserver:an...@an...:/cvs/automake co automake

Libtool (quoting from http://www.gnu.org/software/libtool/):
 $ cvs -z3 -d :pserver:an...@su...:/home/cvs login
 Password:
 $ cvs -z3 -d :pserver:an...@su...:/home/cvs co libtool

I pulled the packages out of CVS just a few minutes ago (my current time is
2001-01-07 16:22 CET), and everything worked. A bug in automake I mentioned
in an earlier mail is fixed by now.


Best regards,
Sven

PS: Unfortunately my Christmas vacation ends tomorrow and I will have to return
    to serve my country for another four months, so expect to hear from me
    again next weekend.

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]

Re: [Mesa3d-dev] GLU fun

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

Michael Vance wrote:
> 
> Looking for a little commentary.
> 
> Tribes 2 uses two GLU functions: gluProject and gluUnProject. Normally
> an app would just link dynamically against libGLU and be done with it,
> However, in the world of binary applications and entertainment
> oriented end-users, this is a dangerous proposition. Especially with
> the proliferation of the NVIDIA drivers, which don't ship a GLU.
> 
> My ideas:
> 
> 1) link dynamically and ship a Mesa GLU in the current directory, with
> associated LD_LIBRARY_PATH mojo. Unfortunately, we use a dlopen()
> style pointer mechanism, so GL is never explicitly linked. The
> run-time linker will probably still work because a libGL *is* loaded,
> through dlopen, but it still makes me nervous.
> 
> 2) Ask permission to include the two functions verbatim into the
> Tribes 2 source tree. I did this with gluBuild2DMipMaps with Brian's
> blessing for Heavy Gear 2. Obviously the LGPL usually doesn't allow
> this w/o object files, etc. Unfortunately, it looks like a Frenchman
> of some sort wrote the project/unproject code in Mesa, and I don't
> know if Brian has copyright assignment.

You're welcome to just use those functions.  Anyone familiar with
transformations could derive them in a couple hours.  If you wrote
them from scratch you'd probably wind up with nearly identical code
anyway.


> 3) See if the SGI OSS B license would allow me to do (2) with its
> code. Unfortunately IANAL and can't tell exactly what the license lets
> me do.

I don't think that would be a problem either.

-Brian

Re: [Mesa3d-dev] GLU fun

[Marcelo E. M. <mar...@bi...>]

Hi,

>> Michael Vance <bri...@lo...> writes:

 > However, in the world of binary applications and entertainment
 > oriented end-users, this is a dangerous proposition.
 
 *frown*
 
 > 2) Ask permission to include the two functions verbatim into the
 > Tribes 2 source tree. I did this with gluBuild2DMipMaps with Brian's
 > blessing for Heavy Gear 2. Obviously the LGPL usually doesn't allow
 > this w/o object files, etc. Unfortunately, it looks like a Frenchman
 > of some sort wrote the project/unproject code in Mesa, and I don't
 > know if Brian has copyright assignment.

 Pull out your copy of the blue book and look at gluProject and
 gluUnProject.  Shouldn't take more than 30 minutes to implement both
 functions.  Take into account you are inverting 4x4 matrices, special
 case the inversion.

 HTH,
 
--
Marcelo

[Mesa3d-dev] GLU fun

[Michael V. <bri...@lo...>]

Looking for a little commentary.

Tribes 2 uses two GLU functions: gluProject and gluUnProject. Normally
an app would just link dynamically against libGLU and be done with it,
However, in the world of binary applications and entertainment
oriented end-users, this is a dangerous proposition. Especially with
the proliferation of the NVIDIA drivers, which don't ship a GLU.

My ideas:

1) link dynamically and ship a Mesa GLU in the current directory, with
associated LD_LIBRARY_PATH mojo. Unfortunately, we use a dlopen()
style pointer mechanism, so GL is never explicitly linked. The
run-time linker will probably still work because a libGL *is* loaded,
through dlopen, but it still makes me nervous.

2) Ask permission to include the two functions verbatim into the
Tribes 2 source tree. I did this with gluBuild2DMipMaps with Brian's
blessing for Heavy Gear 2. Obviously the LGPL usually doesn't allow
this w/o object files, etc. Unfortunately, it looks like a Frenchman
of some sort wrote the project/unproject code in Mesa, and I don't
know if Brian has copyright assignment.

3) See if the SGI OSS B license would allow me to do (2) with its
code. Unfortunately IANAL and can't tell exactly what the license lets
me do.

Thoughts?

Thanks,

m.

-- 
Programmer             "Ha ha." "Ha ha." "What are you laughing at?"
Loki Software                      "Just the horror of being alive."
mic...@ya...                         - Tony Millionaire

Re: [Mesa3d-dev] Possible bug in s_texture.c

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

Abaco wrote:
> 
> Hi,
> 
> I´m sitting here in an internet-shop in Spain, so if you won´t be able to
> mail me, for now. But monday I´m back in the Netherlands.
> 
> I think an error exists in the function _swrast_choose_texture_sample_func
> in the file src/swrast/s_texture.c.
> 
> Instead of
> 
>       if (needLambda) {
>          /* Compute min/mag filter threshold */
>          if (t->MagFilter==GL_LINEAR
>              && (t->MinFilter==GL_NEAREST_MIPMAP_NEAREST ||
>                  t->MinFilter==GL_LINEAR_MIPMAP_NEAREST)) {
>             swrast->_MinMagThresh[texUnit] = 0.5F;
>          }
> 
> it should be
> 
>       if (needLambda) {
>          /* Compute min/mag filter threshold */
>          if ((t->MagFilter==GL_LINEAR &&
>              t->MinFilter==GL_LINEAR_MIPMAP_NEAREST) ||
>              (t->MagFilter==GL_NEAREST &&
>                  t->MinFilter==GL_NEAREST_MIPMAP_NEAREST)) {
>             swrast->_MinMagThresh[texUnit] = 0.5F;
>          }

See section 3.8.6 of the 1.2 spec.  It says if the mag filter is
GL_LINEAR and (min filter is GL_NEAREST_MIPMAP_NEAREST or min filter
is GL_NEAREST_MIPMAP_LINEAR) then c = 0.5, else it's 0.

Note that Mesa is indeed wrong, but not in the way you point out.
I should replace GL_LINEAR_MIPMAP_NEAREST with GL_NEAREST_MIPMAP_LINEAR.

I'm wonder if that got changed from the 1.0 spec at one point.

-Brian

[Mesa3d-dev] Possible bug in s_texture.c

[Abaco <aba...@ct...>]

Hi,

I´m sitting here in an internet-shop in Spain, so if you won´t be able to
mail me, for now. But monday I´m back in the Netherlands.

I think an error exists in the function _swrast_choose_texture_sample_func
in the file src/swrast/s_texture.c.

Instead of

      if (needLambda) {
         /* Compute min/mag filter threshold */
         if (t->MagFilter==GL_LINEAR
             && (t->MinFilter==GL_NEAREST_MIPMAP_NEAREST ||
                 t->MinFilter==GL_LINEAR_MIPMAP_NEAREST)) {
            swrast->_MinMagThresh[texUnit] = 0.5F;
         }

it should be

      if (needLambda) {
         /* Compute min/mag filter threshold */
         if ((t->MagFilter==GL_LINEAR &&
             t->MinFilter==GL_LINEAR_MIPMAP_NEAREST) ||
             (t->MagFilter==GL_NEAREST &&
                 t->MinFilter==GL_NEAREST_MIPMAP_NEAREST)) {
            swrast->_MinMagThresh[texUnit] = 0.5F;
         }

I hope this email is send in ASCII and not windows-format-whatever...

Bye

    Klaus

Re: [Mesa3d-dev] autoconfmake bugs fixed

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

"Sven M. Hallberg" wrote:
> 
> So here it is finally, someone should close the following bugs:
> 
> Bug #126494: Fixed.
> 
> Bug #114967: Fixed.
> 
> Bug #122196: Can be closed, existing Makefile is already correct.
> 
> Bug #122198: Regenerated the file lists by simply putting in *.[ch] found in
>              the corresponding source directory. Library and checks build,
>              All demos I tried ran fine. -> Can be closed.
> 
> Bug #122644: Appears fixed already. Checks for cpuid, MMX, and 3Dnow all
>              return "yes" on my system. -> Can be closed.
> 
> I've already checked the changes into CVS, so everyone please try the
> autoconfmake build mechanism on your systems and report any issues remaining
> (submit them to the bug database at sourceforge and drop a note on the list).

Thanks.  I've closed these bugs.


> Regards,
> Sven
> 
> PS: I've used the very latest versions of autoconf, automake, and libtool from
> their respective CVS repositories. This is reflected in some changes. So be
> sure to get those before you try to run the bootstrap script!

Could you tell us which versions you're using?

-Brian