PDA

View Full Version : z-buffer artifacts in 32-bit color mode


RayMon
03-23-03, 07:53 PM
I've noticed in a few games that only a 16-bit z-buffer is used instead of a 24-bit z-buffer when running the game in 32-bit mode. When this happens, z-buffer artifacts can be seen on far away polygons. Half-Life, MDK2, and Serious Sam are a couple of games that I can think of that have this problem. Serious Sam has a workaround, but I haven't been able to find a solution in each game where I've encountered this. Is there a way to force a 24-bit z-buffer when in 32-bit mode through the detonator drivers? Any suggestions?

duralisis
03-24-03, 12:20 PM
Somtimes a phenomenon known as "z-fighting" occurs due to limitations of the game engine or the inaccuracy of the BSP file (a "map" containing all the visibility, texturing, and world information of the level you're playing).

Z-fighting is a very common thing for mappers (people who make levels for games). It usually occurs when you overlap polygons, where one is trying to overdraw the other. Since both can have coincident points, but not be on the same triangle strip (meaning their vertices are the same coordinants but not the exact same vertex), you get a sheering effect. Especially at distances.

Now for some games like Half-Life, Q3, etc., the only solution is "cleaner mapping", making sure that only 2 edge meet at any given point along a polygon edge. This allows the game compilers (tools which process your editor's output into a game file format) to process a BSP more efficiently and it's possible to create a map without any overdraw.

To the best of my knowledge, there's no way to force a 24-bit zbuffer under OpenGL. However, in RivaTuner (get it from Guru3d.com), I've seen options for forcing W-buffers and 24-bit zbuffers -- that may help.

Generally under 32-bit color, a 24-bit zbuffer should automatically be used, if not try contacting the game's support or developers, they might know a fix or try integrating a fix in the next patch.