Banding When Rendering 3D Model

Started by
8 comments, last by Jorj 18 years ago
Hello, I have lately started coding with directX and have (this morning) worked out a model loading script (WooHoo), my problem is that it puts wierd bands onto some of the Objects. I have tried loading from different objects and all from the same one, and i still get this, it seems to depend on the angle you look at the object from and distance from it. Is there any way to A)Stop it, or B)Lessen the effect - I take it somewhere the depth buffer isn't detailed enough....or something.... Can Anyone Help Me. Thanks in advance - Jorj EDIT: Made your image embedded instead of just a text-link -Jack
Advertisement
I presume its the grey pattern that you're not wanting? Or is it the pixellation of the textures?

If it's the grey pattern, then how have you set up your depth buffer (usually in the D3DPRESENT_PARAMETERS passed to CreateDevice())? Also, how have you configured your projection matrix (usually via D3DMatrixPerspectiveFovLH())?

Cheers,
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

What are your clip planes set to in your projection matrix? If they're far apart (e.g. 0.01f -> 10000.0f) then you'll get precision issues. Try something like 1.0f -> 1000.0f and see if that helps.

What is the object supposed to look like? it's a bit hard to tell from that screenshot [smile]
The two depth parameters are:

EnableAutoDepthStencil = TRUE;
AutoDepthStencilFormat = D3DFMT_D16;

I am just experimenting with the clip planes - it was 1 - 2000....its hard to tell if its better.....ill see how low i can get it and see if thats better.

Thanks a lot.

The Model is a room, the gray area is the metal around a wooden chest, my next challenge (after loading animated models) is to use shaders on the entire thing, because its really ugly at the moment (that half the reason I didn't put the whole screenshot in)

Edit: Have got it down to 500, and it might be better, but its still quite obvious...
Give D3DFMT_D24S8 a try. It should instantly improve results if you are indeed suffering from z-issues, as it seems you are.

A better way to handle this issue is to fix the model. From what I could tell, it has coplanar surfaces. Most modeling software can handle these issues okay, but computer GPU's just suffer trying to calculate that. If it's a possibility, I'd highly recommend removing the coplanar surfaces, and avoiding having any in the future. Anything else would only be able to reduce the artifacts, no eliminate them.

Also, give Linear filtering a go, to reduce the pixely look of the texturing.

Should be something in the sort of:
	m_pd3dDevice->SetSamplerState(0, D3DSAMP_MIPFILTER, D3DTEXF_LINEAR); 	m_pd3dDevice->SetSamplerState(0, D3DSAMP_MAGFILTER, D3DTEXF_LINEAR); 	m_pd3dDevice->SetSamplerState(0, D3DSAMP_MINFILTER, D3DTEXF_LINEAR); 


Hope this helps :).
Sirob Yes.» - status: Work-O-Rama.
Fanstatic, changing the depth buffer type get rid of it, thanks.

I would have looked at the model but i have no idea what coplanar surfaces are...
a co-planar polygon is an invalid polygon. For a *true* polygon, all vertices should lie on one plane. Triangles never suffer from his problem since 3 points will always form a plane. Quads can easily be made to be co-planar by simply pulling one of the vertices. The problem with co-planar polygons is that you can't correctly define a face normal, which can cause some wierd lighting artifacts.

Quote:Original post by RobTheBloke
a co-planar polygon is an invalid polygon.
Other way round I think [wink]

Triangles are examples of convex and coplanar polygons, which is why they're great for computer graphics.

An arbitrary polygon can have these properties, but is not required to.

Quote:Original post by RobTheBloke
The problem with co-planar polygons is that you can't correctly define a face normal, which can cause some wierd lighting artifacts.
I'm not sure I quite understand this part. A coplanar polygon has all its points on the same plane, thus the normal for the polygon is just that of the plane. I can understand your point for non-coplanar polygons [smile]

Anyway, in the context of what sirob said, coplanar polygonS are basically triangles that exist on the same plane and overlap each other. When you put these through the transformations they generate (in theory) the same depth values. However, due to floating-point inaccuracies they might not have exactly the same depth - so you can get some pretty odd artifacts (the classic is "Z fighting"). The fix being to seperate any triangles that overlap each other on the same plane.

hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

Quote:Original post by jollyjeffers
Anyway, in the context of what sirob said, coplanar polygonS are basically triangles that exist on the same plane and overlap each other. When you put these through the transformations they generate (in theory) the same depth values. However, due to floating-point inaccuracies they might not have exactly the same depth - so you can get some pretty odd artifacts (the classic is "Z fighting"). The fix being to seperate any triangles that overlap each other on the same plane.


Heh, I saw his question, but couldn't really come up with an understandable answer. That's a great way of putting it, I say :).
Sirob Yes.» - status: Work-O-Rama.
Ah right, i get it. Thanks a lot, ill fix that model.

- Jorj

This topic is closed to new replies.

Advertisement