mesa3d-dev

Re: [Mesa3d-dev] shadow extensions

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

Gareth Hughes wrote:
> 
> Brian Paul wrote:
> >
> > While working on the texture image code I had to fix some
> > things related to color index (paletted) texture images.  That
> > got me thinking about other texture formats like depth textures.
> > So, I implemented the GL_SGIX_depth_texture extension and then
> > GL_SGIX_shadow to exercise it.  GL_SGIX_shadow_ambient was a
> > simple addition on top of that.
> >
> > ...
> >
> > My implementation isn't 100% complete either.  Right now, the
> > depth texture is only sampled with nearest/nearest filtering
> > and the texels are always stored as floats.  I'll try to fix
> > those things in the not-too distant future.
> 
> Great work!  I remember talking about this with you at SIGGRAPH last
> year -- I'm really interested in checking this out.

The code was surprisingly simple after I got the new teximage stuff
sorted out.

I want to experiment with shadow map sampling.  Linear filtering
won't necessarily give better results than nearest filtering.
Consider the discontinuities along object profiles.  I might try
taking 4 depth samples, perform 4 R comparisons then use the
results of those 4 tests to determine if the fragment is shadowed
or not.  I'm also curious how mipmapping will work out.

-Brian

Re: [Mesa3d-dev] shadow extensions

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

Brian Paul wrote:
> 
> While working on the texture image code I had to fix some
> things related to color index (paletted) texture images.  That
> got me thinking about other texture formats like depth textures.
> So, I implemented the GL_SGIX_depth_texture extension and then
> GL_SGIX_shadow to exercise it.  GL_SGIX_shadow_ambient was a
> simple addition on top of that.
> 
> ...
>
> My implementation isn't 100% complete either.  Right now, the
> depth texture is only sampled with nearest/nearest filtering
> and the texels are always stored as floats.  I'll try to fix
> those things in the not-too distant future.

Great work!  I remember talking about this with you at SIGGRAPH last
year -- I'm really interested in checking this out.

-- Gareth

[Mesa3d-dev] shadow extensions

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

While working on the texture image code I had to fix some
things related to color index (paletted) texture images.  That
got me thinking about other texture formats like depth textures.
So, I implemented the GL_SGIX_depth_texture extension and then
GL_SGIX_shadow to exercise it.  GL_SGIX_shadow_ambient was a
simple addition on top of that.

Together, these extensions implement shadow maps (invented by
Williams, I think).  Basically, the scene is first rendered from
the point of view of the light source in order to generate a depth
map.  Then, the scene is rendered from the regular camera's point
of view.  Texgen and a special texture matrix compute the projection
of each vertex (as a texture coordinate) into the light's coordinate
system.  During texturing, we compare the texture R component to
the depth map value at (S,T).  The result of the comparison determines
whether or not the fragment is shadowed.

The technique isn't perfect but can work pretty well in the right
situation.

There's a demo in Mesa/demos/shadowtex.c

My implementation isn't 100% complete either.  Right now, the
depth texture is only sampled with nearest/nearest filtering
and the texels are always stored as floats.  I'll try to fix
those things in the not-too distant future.

-Brian

Re: [Mesa3d-dev] sources.lst files

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

de...@ko... wrote:
> 
> >>
> >> I've reported every bug in the past that I've been able to isolate to a simple
> >> test case (and they've all been fixed quickly).  Unfortunately, this one isn't so simple,
> >> we use a large number of features, and the application itself is a very large, complex
> >> application that takes several hours to compile and just getting the compile to work is
> >> a bit hard (it's C++, needs a very recent version of gcc, STLport, etc etc), and we're
> >> not yet distributing the source in a general manner.
> >
> >Would sending me a binary be practical?
> 
> Sure, in fact, with the next release or so, any user will be able to download the binary
> from the website without a password (right now it's password protected and you
> have to make a formal request).

OK.  Let me know when it's available, give me the steps to reproduce the
problem and I'll look at it.


> Right now I'm struggling with getting the Linux port to work again now that the main
> programmer changed some source and it's causing g++ to report an internal compiler error
> (urk).
> 
> >
> >Could you send me a screenshot of the problem?  That might give me a hint.
> 
> Sure: see page http://www.cgl.ucsf.edu/home/dek/mesa_bug

Thanks.


> >> Here's some of the features we're enabling : lighting, fog, arbitrary clip planes, stippled lines,
> >> alpha blend modes, material properties, depth test, line width, point size, scissor, color logic op, vertex
> >> arrays, polygon offset, stencil, along with tons of texture options including 3D textures
> >> when available.
> >
> >Can you enable/disable these different OpenGL features in order to narrow
> >down or characterize the circumstances under which the problem appears?
> 
> We'll see.  It's tricky because those modes are activated and deactivated numerous
> times during a frame render, and not all of them are applied when the bonds are drawn.
> Certainly,lighting, fog, clip planes, alpha blending, material properties, depth testing,
> scissor, and color logic op are applied during bond rendering.

Are the bonds drawn as polygons or lines?  It's a bit hard to tell.  If you can
say what OpenGL features are used when rendering the bonds that would help too.

Thanks.

-Brian

Re: [Mesa3d-dev] sources.lst files

[<de...@ko...>]

>> 
>> I've reported every bug in the past that I've been able to isolate to a simple
>> test case (and they've all been fixed quickly).  Unfortunately, this one isn't so simple,
>> we use a large number of features, and the application itself is a very large, complex
>> application that takes several hours to compile and just getting the compile to work is
>> a bit hard (it's C++, needs a very recent version of gcc, STLport, etc etc), and we're
>> not yet distributing the source in a general manner.
>
>Would sending me a binary be practical?

Sure, in fact, with the next release or so, any user will be able to download the binary
from the website without a password (right now it's password protected and you
have to make a formal request).

Right now I'm struggling with getting the Linux port to work again now that the main
programmer changed some source and it's causing g++ to report an internal compiler error
(urk).

>
>Could you send me a screenshot of the problem?  That might give me a hint.

Sure: see page http://www.cgl.ucsf.edu/home/dek/mesa_bug

>> Here's some of the features we're enabling : lighting, fog, arbitrary clip planes, stippled lines,
>> alpha blend modes, material properties, depth test, line width, point size, scissor, color logic op, vertex
>> arrays, polygon offset, stencil, along with tons of texture options including 3D textures
>> when available.
>
>Can you enable/disable these different OpenGL features in order to narrow
>down or characterize the circumstances under which the problem appears?

We'll see.  It's tricky because those modes are activated and deactivated numerous
times during a frame render, and not all of them are applied when the bonds are drawn.
Certainly,lighting, fog, clip planes, alpha blending, material properties, depth testing, scissor, and color logic
op are applied during bond rendering.

Re: [Mesa3d-dev] sources.lst files

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

de...@ko... wrote:
> 
> Allen Akin writes:
> >On Sun, Feb 18, 2001 at 10:45:19PM -0800, de...@ko... wrote:
> >|
> >| Don't think that passing the conformance tests  is proof you're doing
> >| everything correctly.  We've got scads of visual display problems with Mesa in
> >| our application...
> >
> >Nothing helps stamp out bugs (and prevent their return) better than
> >adding to the test suites that the driver developers use.  If the
> >problems you're seeing can be condensed down to simple test cases, we
> >can add them to the glean suite to make sure they're checked in the
> >future.  (Or you're welcome to add them yourself if you want to
> >register as a glean developer -- start at http://glean.sourceforge.net/)
> 
> I've reported every bug in the past that I've been able to isolate to a simple
> test case (and they've all been fixed quickly).  Unfortunately, this one isn't so simple,
> we use a large number of features, and the application itself is a very large, complex
> application that takes several hours to compile and just getting the compile to work is
> a bit hard (it's C++, needs a very recent version of gcc, STLport, etc etc), and we're
> not yet distributing the source in a general manner.

Would sending me a binary be practical?


> But anyway.  This particular bug is nasty.  I've done full state dumps of the OpenGL
> state, looked at the display list debugging output, and nothing appears to be wrong.
> As far as we can tell, it's in the rasterization phase.  This particlar bug
> exhibits as part of the molecule (this is a molecular modelling application,
> see http://www.cgl.ucsf.edu/chimera) not appearing properly when it is first loaded
> and displayed as a wireframe.  BUt, if a sphere representation is requested, and
> then the wireframe representation is activated, the display begins to work properly.
> Many of the bonds appear properly at first, but many don't-- if you up the MESA_GAMMA to 5
> or so, you can see the "invisible" bonds faintly.    Worse yet, the bonds which are "invisible"
> changes from run to run.  If I had to guess, I'd guess that the rasterization engine is
> reading indeterminate values for the color of the bonds, and that somehow that memory is
> getting properly filled in later when we generate the sphere representation.

Could you send me a screenshot of the problem?  That might give me a hint.


> What's really interesting is that if you compile the app against Mesa 3.4 (I think nothing
> older than 3.3 works- it requires the changes to gl.h to use typedefs instead of enums for
> C++ reasons) then use the Mesa 3.0 libGL, the problem goes away!  So, it must be a problem
> that was introduced after 3.0 (but I know  a lot changed).
> Using the nvidia driver and XFree86 4.0.2 doesn't have the problem.

A *lot* of code has changed since 3.0 so it's hard to say what's causing
the problem.


> Here's some of the features we're enabling : lighting, fog, arbitrary clip planes, stippled lines,
> alpha blend modes, material properties, depth test, line width, point size, scissor, color logic op, vertex
> arrays, polygon offset, stencil, along with tons of texture options including 3D textures
> when available.

Can you enable/disable these different OpenGL features in order to narrow
down or characterize the circumstances under which the problem appears?

-Brian

Re: [Mesa3d-dev] sources.lst files

[<de...@ko...>]

Allen Akin writes:
>On Sun, Feb 18, 2001 at 10:45:19PM -0800, de...@ko... wrote:
>| 
>| Don't think that passing the conformance tests  is proof you're doing
>| everything correctly.  We've got scads of visual display problems with Mesa in
>| our application...
>
>Nothing helps stamp out bugs (and prevent their return) better than
>adding to the test suites that the driver developers use.  If the
>problems you're seeing can be condensed down to simple test cases, we
>can add them to the glean suite to make sure they're checked in the
>future.  (Or you're welcome to add them yourself if you want to
>register as a glean developer -- start at http://glean.sourceforge.net/)

I've reported every bug in the past that I've been able to isolate to a simple
test case (and they've all been fixed quickly).  Unfortunately, this one isn't so simple, 
we use a large number of features, and the application itself is a very large, complex
application that takes several hours to compile and just getting the compile to work is
a bit hard (it's C++, needs a very recent version of gcc, STLport, etc etc), and we're
not yet distributing the source in a general manner.   

But anyway.  This particular bug is nasty.  I've done full state dumps of the OpenGL
state, looked at the display list debugging output, and nothing appears to be wrong.
As far as we can tell, it's in the rasterization phase.  This particlar bug
exhibits as part of the molecule (this is a molecular modelling application,
see http://www.cgl.ucsf.edu/chimera) not appearing properly when it is first loaded
and displayed as a wireframe.  BUt, if a sphere representation is requested, and
then the wireframe representation is activated, the display begins to work properly.
Many of the bonds appear properly at first, but many don't-- if you up the MESA_GAMMA to 5
or so, you can see the "invisible" bonds faintly.    Worse yet, the bonds which are "invisible"
changes from run to run.  If I had to guess, I'd guess that the rasterization engine is
reading indeterminate values for the color of the bonds, and that somehow that memory is
getting properly filled in later when we generate the sphere representation.

What's really interesting is that if you compile the app against Mesa 3.4 (I think nothing
older than 3.3 works- it requires the changes to gl.h to use typedefs instead of enums for
C++ reasons) then use the Mesa 3.0 libGL, the problem goes away!  So, it must be a problem
that was introduced after 3.0 (but I know  a lot changed).
Using the nvidia driver and XFree86 4.0.2 doesn't have the problem.  

Here's some of the features we're enabling : lighting, fog, arbitrary clip planes, stippled lines,
alpha blend modes, material properties, depth test, line width, point size, scissor, color logic op, vertex
arrays, polygon offset, stencil, along with tons of texture options including 3D textures
when available.  

Dave

Re: [Mesa3d-dev] sources.lst files

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

On Sun, Feb 18, 2001 at 10:45:19PM -0800, de...@ko... wrote:
| 
| Don't think that passing the conformance tests  is proof you're doing
| everything correctly.  We've got scads of visual display problems with Mesa in
| our application...

Nothing helps stamp out bugs (and prevent their return) better than
adding to the test suites that the driver developers use.  If the
problems you're seeing can be condensed down to simple test cases, we
can add them to the glean suite to make sure they're checked in the
future.  (Or you're welcome to add them yourself if you want to
register as a glean developer -- start at http://glean.sourceforge.net/)

Allen

Re: [Mesa3d-dev] sources.lst files

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

de...@ko... wrote:
> 
> Gareth Hughes writes:
> >Brian Paul wrote:
> >>
> >> All the conformance tests pass now.
> >
> >I don't think I'll ever get sick of hearing that...
> >
> >-- Gareth
> >
> >_______________________________________________
> >Mesa3d-dev mailing list
> >Mes...@li...
> >http://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> Don't think that passing the conformance tests  is proof you're doing
> everything correctly.

We don't.


> We've got scads of visual display problems with Mesa in
> our application, that other drivers handle just fine.  Then again, we've
> got visual display problems that crop up under the other drivers too.
> We haven't yet found a completely acceptable openGL implementation.

Have you reported these problems?  I'm unlikely to fix bugs that
I'm not aware of.

-Brian

OpenGL conformance (was Re: [Mesa3d-dev] sources.lst files)

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

de...@ko... wrote:
> 
> Don't think that passing the conformance tests  is proof you're doing
> everything correctly.  We've got scads of visual display problems with Mesa in
> our application, that other drivers handle just fine.  Then again, we've
> got visual display problems that crop up under the other drivers too.
> We haven't yet found a completely acceptable openGL implementation.

I am aware of this.  However, passing the OpenGL conformance tests is a
large step in the right direction, wouldn't you agree?  It is critical
if Mesa is to ever become an officially-recognized OpenGL
implementation, rather than "an OpenGL work-alike" library or whatever
it has to be called these days.

-- Gareth

Re: [Mesa3d-dev] sources.lst files

[<de...@ko...>]

Gareth Hughes writes:
>Brian Paul wrote:
>> 
>> All the conformance tests pass now.
>
>I don't think I'll ever get sick of hearing that...
>
>-- Gareth
>
>_______________________________________________
>Mesa3d-dev mailing list
>Mes...@li...
>http://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Don't think that passing the conformance tests  is proof you're doing
everything correctly.  We've got scads of visual display problems with Mesa in
our application, that other drivers handle just fine.  Then again, we've
got visual display problems that crop up under the other drivers too.
We haven't yet found a completely acceptable openGL implementation.

----------------------------------------------------------------------------
Email: de...@cg...   David Konerding   WWW: http://picasso.ucsf.edu/~dek
-----------------------------------------------------------------------------

Re: [Mesa3d-dev] tnl module swapping

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

Keith Whitwell wrote:
> 
> Of course, to get it working you can simply use the X11 driver...

Not a bad idea at all, actually.  That *would* be the simplest
solution... 

-- Gareth

Re: [Mesa3d-dev] tnl module swapping

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

Gareth Hughes wrote:
> 
> Gareth Hughes wrote:
> >
> > So, if you guys have other things to do, I'd be more than happy to
> > tackle this problem in the short term (ie. to get a 3.5 release out).
> 
> I will do this work with the Radeon driver on the mesa-3-5 branch of DRI
> CVS.  This will be the fastest way, otherwise I'd have to go and buy a
> V3 or port another driver over...

Of course, to get it working you can simply use the X11 driver...

Keith

Re: [Mesa3d-dev] tnl module swapping

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

Gareth Hughes wrote:
> 
> So, if you guys have other things to do, I'd be more than happy to
> tackle this problem in the short term (ie. to get a 3.5 release out).

I will do this work with the Radeon driver on the mesa-3-5 branch of DRI
CVS.  This will be the fastest way, otherwise I'd have to go and buy a
V3 or port another driver over...

-- Gareth

Re: [Mesa3d-dev] sources.lst files

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

On Fri, Feb 16, 2001 at 10:36:17AM -0700, Keith Whitwell wrote:
> > > However, pulling the source file lists out would directly eliminate?
> > > the need for that double maintanence work. That's what I meant.
> > >
> > > Do you think we could do that? I would of course do the modification work,
> > > on a seperate branch. You and Keith would just have to agree to use couple of
> > > seperate file for specifying the source lists. Or do you see a problem there?
> > 
> > I think the sources for Mesa 3.5 are quickly settling down and I don't
> > think there will be any big changes anymore (Keith?).  If that's the
> > case, do you still want to make a seperate sources file?
> 
> I removed a file 't_vb_materials.c' yesterday.
> 
> I plan on adding a bunch of templates to make driver writing easier (you've
> already seen a few in the tnl/ directory; they really belong in a directory of
> their own, I think).
> 
> Otherwise, I think that's it for me.

I can't judge how much flux there will be in the source file lists, however if
that's all for the not-too-distant future I guess it'll be unnecessary. Also
just using *.[ch] seems to work pretty well, since the directory organization
is clean (i.e. if there's only one source list var in the Makefile.am, *.[ch]
is safe to assume).

So, for now we'll stick with the seperate maintanence of Makefile.X11 and
Makefile.am.


-Sven

-- 
"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] back to autoconf 2.13

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

On Fri, Feb 16, 2001 at 08:30:14AM -0700, Brian Paul wrote:
> > Well, the problem lies in dynamically generating the list of Makefiles to be
> > created, depending on which directories are present. With the current autoconf
> > you must pass the entire list to a single call of AC_OUTPUT. The only
> > way for a dynamic list is to use a variable and pass that one. I guess that
> > would work with autoconf, _but_ it doesn't with automake because automake
> > parses configure.in for the call to AC_OUTPUT and if it finds AC_OUTPUT($list)
> > assumes it should create a file $list.in. *g*
> > 
> > In the new autoconf you have the required flexibility because it uses
> > a dynamic list internally, i.e. you specify any files to be created by means
> > of repetitive calls to a certain macro (AC_CONFIG_FILES I think) and call
> > AC_OUTPUT without any arguments. The new automake is of course aware of
> > AC_CONFIG_FILES.
> 
> You had suggested putting all the demo directories under a new demo/
> subdirectory.  How would that work?

You mean, whether that would solve the problem? No, because a) you still
need to dynamically decide whether demo/Makefile should be created or not and
b) there are still src-glu and src-glut.

The suggestion to move all the demos under one common subdir was made because
one plausible way to fix the problem cleanly is to make two seperate
packages (in autoconf's sense) "Mesa-demos", "Mesa-GLUT", and "Mesa-GLU". Those
would have their own configure script and be placed in subdirs of the Mesa
sources. Their configure scripts would be invoked by the top-level configure.
That way it's also easy to distribute them seperately from Mesa itself (I think
that's already being done with the demos, right?). It's just a matter of what
you put in the tarball.

-Sven

-- 
"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] sources.lst files

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

Brian Paul wrote:
> 
> Keith Whitwell wrote:
> >
> > I'm still seeing an error in one of the seperate specular tests in
> > mustpass.c;  Previously this was segfaulting (due to the
> > seperate-specular/texture stuff I've been fixing), which seems to be different
> > to the results you were getting (you sent me a list of failures that I
> > couldn't reach because of the segfault).
> >
> > Can you recheck and see if you also get the specular failure?  I'm running at
> > 16bpp on my laptop.
> 
> Yup, I'm getting the failure now too.  I'll start looking into it.

I'll look into it too; it's probably something I've done.

Keith

Re: [Mesa3d-dev] sources.lst files

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

Keith Whitwell wrote:
> 
> I'm still seeing an error in one of the seperate specular tests in
> mustpass.c;  Previously this was segfaulting (due to the
> seperate-specular/texture stuff I've been fixing), which seems to be different
> to the results you were getting (you sent me a list of failures that I
> couldn't reach because of the segfault).
> 
> Can you recheck and see if you also get the specular failure?  I'm running at
> 16bpp on my laptop.

Yup, I'm getting the failure now too.  I'll start looking into it.

-Brian

Re: [Mesa3d-dev] Fog still different

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

Keith Whitwell wrote:
> 
> Brian Paul wrote:
> >
> > Brian Paul wrote:
> > >
> > > Klaus Niederkrueger wrote:
> > > >
> > > > On Fri, 16 Feb 2001, Keith Whitwell wrote:
> > > >
> > > > > Klaus Niederkrueger wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have compared again the software-fog in the 'fire'-demo with Mesa-3.4
> > > > > > and Mesa-3.5 and in Mesa-3.5 it is still a lot denser than in the old one.
> > > > > >
> > > > > > I don't know if this is important or not and if was a bug, I have no idea
> > > > > > if it is now or it was before.
> > > > > >
> > > > > > I haven't try though Mesa-3.4.1.
> > > > >
> > > > > On what driver?
> > > > >
> > > > > I've got the two X11 drivers running side by side & they look identical.
> > > > >
> > > > > Keith
> > > > >
> > > >
> > > > Just normal software-rendering.
> > > > 24bit TrueColor
> > > > Frame buffer: 24bit R8:G8:B8:A0
> > > >
> > > > I don't know what else could help.
> > >
> > > I'm seeing denser fog with 3.5 than 3.4.x too.  Strange thing is,
> > > I think it looked OK the first time I ran it but subsequent runs
> > > look different.  Might be an uninitialized variable somewhere.
> > > I'm looking into it.
> > >
> > > The fire demo seems to be the only demo w/ fog that looks different.
> > > Tunnel, for example, looks identical with 3.5 and 3.4.x.
> >
> > There's a call to glHint(GL_FOG_HINT, GL_NICEST) which is only
> > compiled in if FX is defined.  If the hint is GL_NICEST fog is OK.
> > But if the hint is GL_FASTEST or GL_DONT_CARE the fog is extra
> > dense.  That narrows it down...
> 
> One change is that swrast (in 3.5) now respects (or tries to respect) that
> hint -- previously the software rasterizer *always* did pixel fog, now it has
> the choice.
> 
> The driver can additionally configure swrast to match what the hardware is
> doing with _swrast_allow_vertex_fog() and _swrast_allow_pixel_fog().  I'll
> look over this functionality for unitialized values now.


I think I've gotten to the bottom of this.  GL_NICEST mode causes
the fog factor to be computed per-fragment from the fragment Z coordinate.
It works fine.

GL_FASTEST/DONT_CARE computes the fog factor per vertex then linearly
interpolates the factor across the triangle.  Thing about fire.c is
it draws one large polygon for the ground, most of which gets clipped
away.  We're just linearly interpolating the fog factor in the polygon
clipper.  Doing a perspective-corrected interpolation would probably
improve things.  OpenGL doesn't require perspective correct interpolation
during clipping and adding it to Mesa in this case could be a bit
complicated.

By subdividing the ground polygon into smaller quads the problem
effectively goes away.

I think I'll just clean up fire.c a bit and let it go at that.

-Brian

Re: [Mesa3d-dev] Fog still different

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

Brian Paul wrote:
> 
> Brian Paul wrote:
> >
> > Klaus Niederkrueger wrote:
> > >
> > > On Fri, 16 Feb 2001, Keith Whitwell wrote:
> > >
> > > > Klaus Niederkrueger wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have compared again the software-fog in the 'fire'-demo with Mesa-3.4
> > > > > and Mesa-3.5 and in Mesa-3.5 it is still a lot denser than in the old one.
> > > > >
> > > > > I don't know if this is important or not and if was a bug, I have no idea
> > > > > if it is now or it was before.
> > > > >
> > > > > I haven't try though Mesa-3.4.1.
> > > >
> > > > On what driver?
> > > >
> > > > I've got the two X11 drivers running side by side & they look identical.
> > > >
> > > > Keith
> > > >
> > >
> > > Just normal software-rendering.
> > > 24bit TrueColor
> > > Frame buffer: 24bit R8:G8:B8:A0
> > >
> > > I don't know what else could help.
> >
> > I'm seeing denser fog with 3.5 than 3.4.x too.  Strange thing is,
> > I think it looked OK the first time I ran it but subsequent runs
> > look different.  Might be an uninitialized variable somewhere.
> > I'm looking into it.
> >
> > The fire demo seems to be the only demo w/ fog that looks different.
> > Tunnel, for example, looks identical with 3.5 and 3.4.x.
> 
> There's a call to glHint(GL_FOG_HINT, GL_NICEST) which is only
> compiled in if FX is defined.  If the hint is GL_NICEST fog is OK.
> But if the hint is GL_FASTEST or GL_DONT_CARE the fog is extra
> dense.  That narrows it down...

One change is that swrast (in 3.5) now respects (or tries to respect) that
hint -- previously the software rasterizer *always* did pixel fog, now it has
the choice.

The driver can additionally configure swrast to match what the hardware is
doing with _swrast_allow_vertex_fog() and _swrast_allow_pixel_fog().  I'll
look over this functionality for unitialized values now.

Keith

Re: [Mesa3d-dev] Fog still different

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

Brian Paul wrote:
> 
> Klaus Niederkrueger wrote:
> >
> > On Fri, 16 Feb 2001, Keith Whitwell wrote:
> >
> > > Klaus Niederkrueger wrote:
> > > >
> > > > Hi,
> > > >
> > > > I have compared again the software-fog in the 'fire'-demo with Mesa-3.4
> > > > and Mesa-3.5 and in Mesa-3.5 it is still a lot denser than in the old one.
> > > >
> > > > I don't know if this is important or not and if was a bug, I have no idea
> > > > if it is now or it was before.
> > > >
> > > > I haven't try though Mesa-3.4.1.
> > >
> > > On what driver?
> > >
> > > I've got the two X11 drivers running side by side & they look identical.
> > >
> > > Keith
> > >
> >
> > Just normal software-rendering.
> > 24bit TrueColor
> > Frame buffer: 24bit R8:G8:B8:A0
> >
> > I don't know what else could help.
> 
> I'm seeing denser fog with 3.5 than 3.4.x too.  Strange thing is,
> I think it looked OK the first time I ran it but subsequent runs
> look different.  Might be an uninitialized variable somewhere.
> I'm looking into it.
> 
> The fire demo seems to be the only demo w/ fog that looks different.
> Tunnel, for example, looks identical with 3.5 and 3.4.x.

There's a call to glHint(GL_FOG_HINT, GL_NICEST) which is only
compiled in if FX is defined.  If the hint is GL_NICEST fog is OK.
But if the hint is GL_FASTEST or GL_DONT_CARE the fog is extra
dense.  That narrows it down...

-Brian

Re: [Mesa3d-dev] Fog still different

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

Brian Paul wrote:
> 
> Klaus Niederkrueger wrote:
> >
> > On Fri, 16 Feb 2001, Keith Whitwell wrote:
> >
> > > Klaus Niederkrueger wrote:
> > > >
> > > > Hi,
> > > >
> > > > I have compared again the software-fog in the 'fire'-demo with Mesa-3.4
> > > > and Mesa-3.5 and in Mesa-3.5 it is still a lot denser than in the old one.
> > > >
> > > > I don't know if this is important or not and if was a bug, I have no idea
> > > > if it is now or it was before.
> > > >
> > > > I haven't try though Mesa-3.4.1.
> > >
> > > On what driver?
> > >
> > > I've got the two X11 drivers running side by side & they look identical.
> > >
> > > Keith
> > >
> >
> > Just normal software-rendering.
> > 24bit TrueColor
> > Frame buffer: 24bit R8:G8:B8:A0
> >
> > I don't know what else could help.
> 
> I'm seeing denser fog with 3.5 than 3.4.x too.  Strange thing is,
> I think it looked OK the first time I ran it but subsequent runs
> look different.  Might be an uninitialized variable somewhere.
> I'm looking into it.
> 
> The fire demo seems to be the only demo w/ fog that looks different.
> Tunnel, for example, looks identical with 3.5 and 3.4.x.

The difference is usually because vertex fog is being used instead of
per-pixel.  A lot of the DRI drivers show this, but it isn't a bug there as
that's what the hardware supports.

Keith

Re: [Mesa3d-dev] sources.lst files

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

Brian Paul wrote:
> 
> Keith Whitwell wrote:
> >
> > Brian Paul wrote:
> > > I think the sources for Mesa 3.5 are quickly settling down and I don't
> > > think there will be any big changes anymore (Keith?).  If that's the
> > > case, do you still want to make a seperate sources file?
> >
> > I removed a file 't_vb_materials.c' yesterday.
> 
> t_vb_materials.c or t_vb_material.c?
> 
> _tnl_update_material_stage is referenced in FX/fxdd.c and is in
> t_vb_material.c.  I added it to the makefile and added an extern
> declaration for _tnl_update_material_stage to t_pipeline.h to make
> everything compile.
> 
> All the conformance tests pass now.

I'm still seeing an error in one of the seperate specular tests in
mustpass.c;  Previously this was segfaulting (due to the
seperate-specular/texture stuff I've been fixing), which seems to be different
to the results you were getting (you sent me a list of failures that I
couldn't reach because of the segfault).

Can you recheck and see if you also get the specular failure?  I'm running at
16bpp on my laptop.

Keith

Re: [Mesa3d-dev] Fog still different

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

Klaus Niederkrueger wrote:
> 
> On Fri, 16 Feb 2001, Keith Whitwell wrote:
> 
> > Klaus Niederkrueger wrote:
> > >
> > > Hi,
> > >
> > > I have compared again the software-fog in the 'fire'-demo with Mesa-3.4
> > > and Mesa-3.5 and in Mesa-3.5 it is still a lot denser than in the old one.
> > >
> > > I don't know if this is important or not and if was a bug, I have no idea
> > > if it is now or it was before.
> > >
> > > I haven't try though Mesa-3.4.1.
> >
> > On what driver?
> >
> > I've got the two X11 drivers running side by side & they look identical.
> >
> > Keith
> >
> 
> Just normal software-rendering.
> 24bit TrueColor
> Frame buffer: 24bit R8:G8:B8:A0
> 
> I don't know what else could help.


I'm seeing denser fog with 3.5 than 3.4.x too.  Strange thing is,
I think it looked OK the first time I ran it but subsequent runs
look different.  Might be an uninitialized variable somewhere.
I'm looking into it.

The fire demo seems to be the only demo w/ fog that looks different.
Tunnel, for example, looks identical with 3.5 and 3.4.x.

-Brian

Re: [Mesa3d-dev] sources.lst files

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

Brian Paul wrote:
> 
> Keith Whitwell wrote:
> >
> > Brian Paul wrote:
> > > I think the sources for Mesa 3.5 are quickly settling down and I don't
> > > think there will be any big changes anymore (Keith?).  If that's the
> > > case, do you still want to make a seperate sources file?
> >
> > I removed a file 't_vb_materials.c' yesterday.
> 
> t_vb_materials.c or t_vb_material.c?
> 
> _tnl_update_material_stage is referenced in FX/fxdd.c and is in
> t_vb_material.c.  I added it to the makefile and added an extern
> declaration for _tnl_update_material_stage to t_pipeline.h to make
> everything compile.

I'll take it out again... Sorry.

Keith