Changing MESA_GLX_DEPTH_BITS works like a charm!
As for the colors, I still think that either I missed some openGL setting in my program, or there is a bug in Mesa. I would expect that regardless of the GL implementation I should be able to turn off all shading, antialiasing etc, render something in color XYZ, read back pixels and find color XYZ, not color (X-1)(Y-1)(Z-1). This makes selection by color value a little harder to do across platforms, but I can work around it.
On 10/12/06, Brian Paul < email@example.com> wrote:Dave Demarle wrote:
> I think I have found a bug in Mesa.
> When I run this code
> < http://www.cs.utah.edu/%7Edemarle/mesabug/main.cxx > linked to my
> system's GL library (nvidia on debian linux) I get image A (below) which
> is correct. When I run the same code linked to the Mesa libary (either
> current CVS or release mesa-6-1) I get image B (further below) which is
> incorrect. Specifically the colors in the Mesa image are off by one and
> a few extra triangles around the silhouette are drawn.
The OpenGL spec is not pixel-accurate so two different versions of
OpenGL will often produce slightly different images.
As for the "extra" pixels in Mesa, those are probably coming from
back-facing polygons passing the depth test because of insufficient
depth buffer precision. You can try two things:
1. Set the MESA_GLX_DEPTH_BITS env var to 32 to get a 32-bit depth
buffer (If you're using the Xlib driver, that is). The Xlib driver
uses a 16-bit depth buffer by default.
2. Adjust your near/far clip planes so they're closer together.