• 14
• 12
• 9
• 10
• 13

# artifacts - z fighting or sthm else?

This topic is 797 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi

Please see at first attached image.

I set near clip plane to 1 and far clip plane to 10 - that is why there is black color on half of the print screen.

I marked with red color some artifacts. My net are horizontal and vertical black lines. When I look at my object from outside there are artifacts.

When I looking at object from inside (2nd image) none problem.

Is it issue with Z fighting despite I even did the test with clip planes 1,10? Or this is another kind of issue? Some horizontal and vertical net lines are sometimes missing.

My texture with net is on image3. This blue color it is alpha=0 as this is print screen from some graphic tool when dds is edited. This texture is repeated many times on my geometry.

void Goalnet::draw()
{
d3d::pDev->SetRenderState( D3DRS_CULLMODE, D3DCULL_NONE);
d3d::pDev->SetRenderState(D3DRS_ALPHABLENDENABLE, TRUE);

//with alpha test blendable the same artifacts occur
//d3d::pDev->SetRenderState(D3DRS_ALPHATESTENABLE, TRUE);
//d3d::pDev->SetRenderState(D3DRS_ALPHAREF, 1);
//d3d::pDev->SetRenderState(D3DRS_ALPHAFUNC, D3DCMP_GREATEREQUAL);

d3d::pDev->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_SRCALPHA);
d3d::pDev->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA);
d3d::pDev->SetTextureStageState(0, D3DTSS_ALPHAARG1, D3DTA_TEXTURE);
d3d::pDev->SetTextureStageState(0, D3DTSS_ALPHAOP, D3DTOP_SELECTARG1);

//Set MatWorld
D3DXMATRIX origMatWorld;
d3d::pDev->GetTransform(D3DTS_WORLD, &origMatWorld);
d3d::setMatWorld(d3d::pDev, &mMatOrientation);

//Make sure that Alfa is disabled for net
D3DCOLORVALUE lackAlfa;
lackAlfa.r = 0;
lackAlfa.g = 0;
lackAlfa.b = 0;
lackAlfa.a = 0;
mGoalnet.mat.at(1).Specular = lackAlfa;
mGoalnet.mat.at(1).Emissive = lackAlfa;
mGoalnet.mat.at(1).Diffuse = lackAlfa;
mGoalnet.mat.at(1).Ambient = lackAlfa;

for(u32 i=0; i<mGoalnet.subsets; ++i) //i=1 - net, i=0 - crossbar, posts
{
d3d::pDev->SetMaterial(&mGoalnet.mat.at(i));
d3d::pDev->SetTexture(0, mGoalnet.texture.at(i));
mGoalnet.mesh->DrawSubset(i);
}

//Restore MatWorld
d3d::pDev->SetTransform(D3DTS_WORLD, &origMatWorld);

//Restore states
d3d::pDev->SetRenderState( D3DRS_CULLMODE, D3DCULL_CCW);
d3d::pDev->SetRenderState(D3DRS_ALPHABLENDENABLE, FALSE);
d3d::pDev->SetRenderState(D3DRS_ALPHATESTENABLE, FALSE);
}

I don't know how to solve this issue with best solution. One my idea is not to draw net in one call "drawSubset". I think I should my net divided into 4 separate subsets (back, top, right, left side of goal box). Then I should set order of draw from the far to close and in such way draw net geometry. Is it right solution? Or the problem can be solved easier?

Edited by anders211

##### Share on other sites

Try setting the alpha test reference value to 128.. could be that the texture isn't entirely transparent where it's supposed to be (like 99% transparent so it looks right even though it isn't.

(Value is [0, 255] where 0 is fully transparent, currently you seem to be using 1).

You can also try debugging it by using a non-transparent texture to see if it helps identify the shapes that are "cut out". If they follow the triangulation of the mesh that would give more hints as to what the problem is.

##### Share on other sites

Have you used anisotropic filtering? The grass on the red-circled image looks like you aren't using anisotropic filtering, maybe you could try using it and see if it helps with the net texture?

##### Share on other sites

Hi

No I use linear:

   pDev->SetSamplerState(0, D3DSAMP_MAGFILTER, D3DTEXF_LINEAR); //others: POINT, ANISOTROPIC, PYRAMIDALQUAD, GAUSSIANQUAD
pDev->SetSamplerState(0, D3DSAMP_MINFILTER, D3DTEXF_LINEAR); //how texture displayed when it is render smaller than the image size
pDev->SetSamplerState(0, D3DSAMP_MIPFILTER, D3DTEXF_LINEAR); //for mip maps

However I checked anisotropic as You suggested and it also didn't help.

Currently I solved issue as I supposed by assigning to each wall net different texture in Blender so when I exported object to x file I have 5 subsets instead of 2 like before.

  Material MaterialForCrossbarAndPosts {
1.000000; 1.000000; 1.000000; 1.000000;;
194.117647;
0.100000; 0.100000; 0.100000;;
0.000000; 0.000000; 0.000000;;
}
Material NetLeft {
1.000000; 1.000000; 1.000000; 1.000000;;
0.000000;
0.000000; 0.000000; 0.000000;;
0.000000; 0.000000; 0.000000;;
TextureFilename {"goalnetZtwardeKrawdzie512x512.dds";}
}
Material NetBack {
1.000000; 1.000000; 1.000000; 1.000000;;
0.000000;
0.000000; 0.000000; 0.000000;;
0.000000; 0.000000; 0.000000;;
TextureFilename {"goalnetZtwardeKrawdzie512x512.dds";}
}
Material NetTop {
1.000000; 1.000000; 1.000000; 1.000000;;
0.000000;
0.000000; 0.000000; 0.000000;;
0.000000; 0.000000; 0.000000;;
TextureFilename {"goalnetZtwardeKrawdzie512x512.dds";}
}
Material NetRight {
1.000000; 1.000000; 1.000000; 1.000000;;
0.000000;
0.000000; 0.000000; 0.000000;;
0.000000; 0.000000; 0.000000;;
TextureFilename {"goalnetZtwardeKrawdzie512x512.dds";}

Each wall geometry is a separate mesh subset now. After that issue completely dissapear. The thing which I don't like is that I don't understand why it helped. When all geometry with net is kept in one mesh subset then we have issue. Maybe it helped because it is easier for Z buffer mechanism to decide if pixel should be drawn or not when the input for Z buffer is in form of subsets which spread on rectangles.  Before I suppose the order of vertex processing was chaotic for example:

1 process vertex from top net

2 process vertex from back net

3 again from top

..

40 from right

41 from top

48 from right

etc.

You know what I mean?

And in new approch the order of processing is:

1. process vertices from net left

2. process vertices from net back

3. process vertices from net top

4. process vertices from net right

I checked camera from each side of net and there is none any issue now. So I guess Z buffering mechanism better works now because I give him more friendly input data.

Edited by anders211

##### Share on other sites

I'd bet it's a problem with transparent pixels writing to the depth buffer. If that's the case then splitting the geo would just reorder the rendering, and you'll get the same artifact from a different view -- if you rotate around the net does it always work correctly?

##### Share on other sites

Yes it works correctly now just wherever camera is located - I checked from many view and don't see a problem.

Yes it looks like problem with transparent pixels writing to depth buffer.

What I might add is that in Assimp Viewer (some popular tool for viewing x-files) both meshes (with 2 and 5 subsets) works correctly (z buffer is enabled, however I don't know if fixed function pipeline is used in this tool or some shaders). In my app only this one with 5 subsets.

But I don't have idea what I have wrong that for me the first doesn't work. If someone want I might send him this x-file with goalnet just to check how it works in his app. Maybe I will also check in my environment just to disabling rendering everything (grass, man, sky) apart from my net.

Edited by anders211

##### Share on other sites

If you use shaders you'll get much more freedom as to how to do stuff like this (and stuff like pixel-perfect specular lighting, FF only does vertex lighting AFAIR):

...
clip(In.Color.a <= 0.01f ? -1.0f : 1.0f);
...



Have you considered moving to shaders, or is there some reason you want to use FF pipeline (not trying to tell you what to do, just curious)? :)

##### Share on other sites

Hi, after some additional tests I am 99% sure that my issue is because of z fighting. When I move camera closer to net more net is visible, when I move further more net is invisible. And probably order of rendering geometry has influence on z buffer.

As far as FF pipeline is concerned I also has shader written in order to replace however I used FF when FF pipeline functionality is enough. I use shaders when I need more advanced technics like skeletonal animation.