mesa3d-dev

[Mesa3d-dev] GL_EXT_vertex_weighting (was EXT_texture_env discussion)

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

On that NVIDIA demo page, there's a demo that shows of this new
extension.  I know the Rage 6 can also do vertex weighting, so we might
want to implement this fairly soon.  I volunteer, as I'll be working on
the Rage 6 DRI driver.

I'll investigate this and report back.

-- Gareth

Re: [Mesa3d-dev] GL_EXT_vertex_weighting (was EXT_texture_env discussion)

[Olivier M. <Oli...@cy...>]

Hello,

I found two serious bugs in the GLU tesselator. I reported these bugs on
the sourceforge bug tracking system. They are easy to reproduce on linux
using gtklookat-0.8.2 (which uses libvrml97-0.8.2) and loading the two
VRML files I mention in the bug report.

I tested these two VRML files on my G3 with MacLookAt which relies on
the same libvrml97 library but uses Apple OpenGL and they both worked
nicely.

Both gtklookat and libvrml97 (as well as MacLookAt) are available from
http://www.openvrml.org/projects/ with complete source code.

One bug is very annoying since it makes GLU crash (SEGFAULT probably due
to a memory leak while attempting to free memory). The other bug causes
reversing the order of vertices in some non convex faces when the normal
is negative, which makes that the wrong side of the face is rendered
(typically the top face of a non-convex VRML Extrusion is drawn properly
while the bottom face is drawn on the wrong side).

I tryed to get into the GLU code to understand the problem, but it seems
not so easy for me. I think you Gareth are the author of that code and
you may help me fixing that problem if you can reproduce the bug (any
hint greatly appreciated).

Best,

-Olivier

Re: [Mesa3d-dev] GL_EXT_vertex_weighting (was EXT_texture_env discussion)

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

Olivier Michel wrote:
> 
> Hello,
> 
> I found two serious bugs in the GLU tesselator. I reported these bugs on
> the sourceforge bug tracking system. They are easy to reproduce on linux
> using gtklookat-0.8.2 (which uses libvrml97-0.8.2) and loading the two
> VRML files I mention in the bug report.
> 
> I tested these two VRML files on my G3 with MacLookAt which relies on
> the same libvrml97 library but uses Apple OpenGL and they both worked
> nicely.
> 
> Both gtklookat and libvrml97 (as well as MacLookAt) are available from
> http://www.openvrml.org/projects/ with complete source code.
> 
> One bug is very annoying since it makes GLU crash (SEGFAULT probably due
> to a memory leak while attempting to free memory). The other bug causes
> reversing the order of vertices in some non convex faces when the normal
> is negative, which makes that the wrong side of the face is rendered
> (typically the top face of a non-convex VRML Extrusion is drawn properly
> while the bottom face is drawn on the wrong side).
> 
> I tryed to get into the GLU code to understand the problem, but it seems
> not so easy for me. I think you Gareth are the author of that code and
> you may help me fixing that problem if you can reproduce the bug (any
> hint greatly appreciated).

I suggest building/using SGI's GLU library from the SI release.

-Brian

[Mesa3d-dev] GLU tessellator (was something completely OT)

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

Olivier Michel wrote:
> 
> I found two serious bugs in the GLU tesselator. I reported these bugs on
> the sourceforge bug tracking system. They are easy to reproduce on linux
> using gtklookat-0.8.2 (which uses libvrml97-0.8.2) and loading the two
> VRML files I mention in the bug report.

Okay, here's the deal, for the record:

Brian and I have discussed this, and we have decided to replace Mesa's
GLU with the SI's one RSN.

I am still working on my new code, as I know of at least one obscure bug
in SGI's version that I'd like to avoid.  I will continue to work on
this until I'm finished, and then Brian and I will compare the two
implementations and decide on which version to use.

I could say I'm rather busy at the moment with other things like DRI
driver development, but that would be a severe understatement.  I'm
hoping that one day I will actually have sufficient time to devote a
week to this, as that would get me a long way towards being done.

The current tessellator in Mesa is just plain broken.  I actually
understand the problem space now, which is why I'm not fixing the old
code, rather replacing it entirely.

-- Gareth

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[Stephen J B. <sj...@li...>]

On Fri, 23 Jun 2000, Gareth Hughes wrote:

> Okay, here's the deal, for the record:
> 
> Brian and I have discussed this, and we have decided to replace Mesa's
> GLU with the SI's one RSN.
 
I was under the impression that SGI's not-quite-OpenSource license would
be a problem here.

                            --ooOOoo--

Please note the change in my email address (was hti.com - now link.com)

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

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

Stephen J Baker wrote:
> 
> On Fri, 23 Jun 2000, Gareth Hughes wrote:
> 
> > Okay, here's the deal, for the record:
> >
> > Brian and I have discussed this, and we have decided to replace Mesa's
> > GLU with the SI's one RSN.
> 
> I was under the impression that SGI's not-quite-OpenSource license would
> be a problem here.

I'm thinking that I'll simply drop Mesa's GLU and require people to
get SGI's GLU.  It would be nice if someone made RPMs or other easily
installed images of SGI's GLU.

-Brian

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[Olivier M. <Oli...@cy...>]

Brian Paul wrote:
> 
> Stephen J Baker wrote:
> >
> > On Fri, 23 Jun 2000, Gareth Hughes wrote:
> >
> > > Okay, here's the deal, for the record:
> > >
> > > Brian and I have discussed this, and we have decided to replace Mesa's
> > > GLU with the SI's one RSN.
> >
> > I was under the impression that SGI's not-quite-OpenSource license would
> > be a problem here.
> 
> I'm thinking that I'll simply drop Mesa's GLU and require people to
> get SGI's GLU.  It would be nice if someone made RPMs or other easily
> installed images of SGI's GLU.
> 
> -Brian

Ok, so I am volunteer to do a re-packaging for SGI GLU. I plan to do the
following:

1) remove everything else than GLU (i.e., GL, GLX) from the SGI SI
package.
2) get rid of C++ dependencies since I believe they are useless for GLU.
3) create some standard and easy way to build (like the GNU
./configure;make;make install but also the old style "make target" as
used in Mesa)
4) create one RPM source package and two binary RPM packages (Linux i386
and Linux PPC)

I am currently printing the license B from SGI to understand how I can
remove parts / add new things.

I will let you know when it's ready.

-Olivier

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

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

Hward Luby wrote:

> We can do that for Red Hat. Since it's only one file, we'll make a
> compressed .so. Do you want us to host it or should it go on sourceforge?

There's the libGLU.so library and glu.h header file.  Is it standard
practice to put the library and header in the same package?  It would
be the simplest for most people.

I'm not sure of the best place to host it right now.  The SGI SI site
might be best.



Olivier Michel wrote:

> Ok, so I am volunteer to do a re-packaging for SGI GLU. I plan to do the
> following:
> 
> 1) remove everything else than GLU (i.e., GL, GLX) from the SGI SI
> package.

Hopefully the main/gfx/lib/glu/ subdirectory can stand on its own.
That is, it doesn't have intimate dependencies on the rest of the sample
GL source tree.


> 2) get rid of C++ dependencies since I believe they are useless for GLU.

I think the GLU NURBS tessellator is written in C++.


> 3) create some standard and easy way to build (like the GNU
> ./configure;make;make install but also the old style "make target" as
> used in Mesa)
> 4) create one RPM source package and two binary RPM packages (Linux i386
> and Linux PPC)

There are already GNU makefiles within the tree.  It would be nice
if you could add rules to generate the binary and source RPMs and
have those rules put into the SI's CVS tree.

I think binary RPMs are the most important thing initially.  People
can download and compile the sources now but probably >95% of people
just want to simply install the library and header files with minimal
fuss.


> I am currently printing the license B from SGI to understand how I can
> remove parts / add new things.

I encourage you to work in cooperation with the SI developers/maintainers
rather than branch off.  I think they'd be receptive to someone helping
with packaging.


Perhaps you guys should join the SI mailing list and discuss your plans
there.

I'm sure a lot of people would appreciate you doing this!

-Brian

PS: A similar treatment for GLUT would be nice too.

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[Howard <ho...@me...>]

----- Original Message -----
From: "Brian Paul" <br...@pr...>
>
> I'm thinking that I'll simply drop Mesa's GLU and require people to
> get SGI's GLU.  It would be nice if someone made RPMs or other easily
> installed images of SGI's GLU.
>
We can do that for Red Hat. Since it's only one file, we'll make a
compressed .so. Do you want us to host it or should it go on sourceforge?
--
Howard Luby     Fax:248 540-3138 Tel:248 540-2251
ho...@me... http://www.mediascape.com

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[Stephen J B. <sj...@li...>]

On Mon, 26 Jun 2000, Brian Paul wrote:

> Stephen J Baker wrote:
> > 
> > On Fri, 23 Jun 2000, Gareth Hughes wrote:
> > 
> > > Okay, here's the deal, for the record:
> > >
> > > Brian and I have discussed this, and we have decided to replace Mesa's
> > > GLU with the SI's one RSN.
> > 
> > I was under the impression that SGI's not-quite-OpenSource license would
> > be a problem here.
> 
> I'm thinking that I'll simply drop Mesa's GLU and require people to
> get SGI's GLU.  It would be nice if someone made RPMs or other easily
> installed images of SGI's GLU.
 
Do you think that the more 'pure' Linux distro's like Debian would
accept that?  It would be bad if OpenGL applications couldn't rely on
the existance of GLU for simple stuff like gluBuildMipMaps just
because we don't have a perfect tessellator or whatever.

Don't get me wrong though - I'd like to see SGI's SI GLU become
"The One True GLU".

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[James A. T. <tr...@de...>]

On Mon, Jun 26, 2000 at 03:43:18PM -0500, Stephen J Baker wrote:
>  
> Do you think that the more 'pure' Linux distro's like Debian would
> accept that?  It would be bad if OpenGL applications couldn't rely on
> the existance of GLU for simple stuff like gluBuildMipMaps just
> because we don't have a perfect tessellator or whatever.
> 
Could someone point me to the license for SGI's version?

If the license does not comply with the Debian Free Software Guidelines
(DFSG for short)(*) then the GLU library would have to go in non-free.

Just in case anyone is wondering, I am the Debian maintainer for mesa.

(*)They are basically the same as the Open Source definition, since the
Open Source definition is based on the DFSG. See
http://www.debian.org/social_contract#guidelines for details.

-- 
James (Jay) Treacy
tr...@de...

Re: [Mesa3d-dev] GLU tessellator (was something completely OT)

[Olivier M. <Oli...@cy...>]

"James A. Treacy" wrote:
> 
> On Mon, Jun 26, 2000 at 03:43:18PM -0500, Stephen J Baker wrote:
> >
> > Do you think that the more 'pure' Linux distro's like Debian would
> > accept that?  It would be bad if OpenGL applications couldn't rely on
> > the existance of GLU for simple stuff like gluBuildMipMaps just
> > because we don't have a perfect tessellator or whatever.
> >
> Could someone point me to the license for SGI's version?

It's http://oss.sgi.com/projects/FreeB (be careful the first postscript
page seems corrupted, it created many gremlins on my printer, maybe the
.doc version is better).

> If the license does not comply with the Debian Free Software Guidelines
> (DFSG for short)(*) then the GLU library would have to go in non-free.
> 
> Just in case anyone is wondering, I am the Debian maintainer for mesa.
> 
> (*)They are basically the same as the Open Source definition, since the
> Open Source definition is based on the DFSG. See
> http://www.debian.org/social_contract#guidelines for details.

Let us know if you think that this SGI license fits with Debian DFSG.

Thanks,

-Olivier

Re: [Mesa3d-dev] GL_EXT_vertex_weighting (was EXT_texture_env discussion)

[Holger W. <hwa...@ya...>]

Hi everybody,

it's almost done -- the software rasterizer seems to be working. I'll
stress and test it a bit next days.

Brian, shall I send you a 'preview', which could be used already as
template for drivers or should I send it to you when I tested it ?

- Holger

Re: [Mesa3d-dev] EXT_texture_env discussion

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

Holger Waechtler wrote:
> 
> Hi everybody,
> 
> it's almost done -- the software rasterizer seems to be working. I'll
> stress and test it a bit next days.

So, this extension is really going to do what you need?  I'm expecting/
hoping that people will actually use it.


> Brian, shall I send you a 'preview', which could be used already as
> template for drivers or should I send it to you when I tested it ?

Don't send it until you're reasonably finished with it.

-Brian