Z Fighting Question

What are your Near and Far planes set at?

I think that basically the larger the difference is between the Near and Far, the less accuracy you will have.

You could try moving the lines slightly higher off the road.

Hi there GremlinX,
How are you doing?

The Problem
Rendering a race track unto a plane on the same height?

The Solution
Since they are on the same height you have a couple of choices. What you can do is raise the race track a little, this might cause a few more problems... or you might want to look into stenciling to solve your problem. What you can do with a stencil buffer is rendering the race track unto the same surface as the ground/asphalt surface without causing ZFighting to occur.

Here is a link to creating effects with the stencil buffer

Stencilling
PS: you need a gamasutra account

I hope this helps buddy, take care.

[Edited by - Armadon on August 28, 2005 2:30:31 AM]

Why not set the z-func to lessequals? This means it draws not only if the z value is less than what's currently there, but also when the values are equal?

look into the D3DRS_ZFUNC renderstate for more info.

This is not a problem with the Z-buffer. The technique you want is "decals". Search this site for "decal" and you will find plenty of discussion.

However, in your case, you don't need decals. Assuming the lines in the road are permanent, the best (and simplest) solution is to apply the two textures in a single pass rather than two passes.

But suppose you want to put skid marks on the road. That is where the decals come in. One way is using glPolygonOffset (if you are using OpenGL). It is pretty simple and efficient, but there are drawbacks. The other way is to use the stencil buffer as Armadon suggested (Decaling with Stencil).

Another solution would be to use z-bias.

Quote:

from http://pluralsight.com/wiki/default.aspx/Craig.DirectX/MeshCreationTutorial.html A z-bias is just a small number that's added to the view space z value of every pixel. Remember, in a left-handed coordinate system, a bigger value for z in view space means “farther away from the viewer.” It's needed in our case because both the wireframe and the solid version of our cube are being drawn in exactly the same place. Since we have z-buffering enabled (remember z-buffers?), and because floating point math can result in small variations between numbers that are supposed to be the same, without a z-bias, parts of the wireframe would disappear “behind” the solid cube. Remove the depth bias code and you'll see what I mean.