[ originally from http://sourceforge.net/tracker/index.php?func=detail&aid=730471&group_id=387&atid=100387 ] I have a very starange problem. I was using Red Hat 8.0, mesa 4 i think, and it was fine. With RedHat 9.0 mesa 4.0.4, when playing Quake3 or other OpenGL games, the shadows beneath the characters and the decals such as blood show thorough the walls. The shadows seem to be drawn even when they should not be visible, thus I get an unfair advantage as I can see players around the corner before they know I am there, via the shadow. It may be a Z/W-buffer problem, as the depth may not be correctly calculated, not sure. Has anyone ever had this problem before?? Any help is appreciated. Is it the driver? Look at the attached picture, RTCW shows the blood of a dead soldier through the wall i am standing against. Thanks. Here is the output of GLXInfo: direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Rage128 20020221 M3 AGP 2x x86/MMX/SSE OpenGL version string: 1.2 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_window_pos, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess Followups: Comments Date: 2003-05-13 15:06 Sender: a_raikmo Logged In: YES user_id=768084 OpenGL renderer string: Mesa DRI Rage128 20010405 M3 AGP 1x x86/MMX/SSE OpenGL version string: 1.2 Mesa 3.4.2 From Red Hat 8.0, this works perfectly. Date: 2003-05-12 15:02 Sender: a_raikmo Logged In: YES user_id=768084 I have taken the latest drivers from dri.sourceforge.net but they still do not solve the problem. The old drivers for red hat 8.0 worked perfectly, so i don't know where this problem has arisen from. Help appreciated.
mass reassign to dri-devel@, i'm no longer the default component owner. sorry for the spam.
this is old but probably still valid. Bug 755 might be a testcase...
closing due to inactivity and recent bugfixes in the area. please reopen if they're still valid.
reopening, still valid apparently.
Sounds like this could be related to bad glPolygonOffset implementation. I coded a little test program to figure out how r300s z-bias works: http://nu.rasterburn.org/~aet/offset.tar.bz2 (never mind about the coding style!) Im suggesting something similar to be included in mesas test programs as i didnt find any decent programs that would clearly show if glPolygonOffset is operating correctly. Unless anyone isnt interested in creating a new test im willing to port this to glut and add tests for points and lines.
The test looked the same both on ALWAYS_INDIRECT and with hardware on my Rage 128. Given that the decals in question tend to be at large differences in Z, I'm not that surprised that it didn't help. Another possibility is that it's broken software fallbacks that are at fault. Checking if R128_DEBUG=fall <game> shows fallbacks happening could indicate that that's the problem, since fallbacks are rather broken currently.
I think it's safe to close this after 7 years of silence, and the driver in question has since been removed from mesa. I don't know if it was fixed in the meantime, but let's assume it was.
(In reply to comment #7) > I think it's safe to close this after 7 years of silence, and the driver in > question has since been removed from mesa. I don't know if it was fixed in the > meantime, but let's assume it was. Hmm. In such cases I think CLOSED is better than RESOLVED. Unfortunately there does not seem to be a reason TOO_OLD or similar. I guess WONTFIX is good in this case.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.