Weird scerrated triangle effect on my meshes

I am working on a space trading simulation, and am reading mesh data in, which has precalculated normals.

I have recently added light sourcing, and
am experiencing a weird effect within my meshes now.

Check out the space station in this screenshot:
http://www.dodgyposse.com/images/scerrated.jpg

Look at the gold globe in the centre, and you will see some of the edges have a triangular chunk taken out of them.

At first I thought, ‘depth buffer’ but GL_DEPTH_TEST is enabled, and I have called glEnable( GL_DEPTH ) also.

GL_CULLING is also enabled…

As you move forward in the scene, the position of the missing chunks moves, and sometimes, when the camera stops moving, everything looks fine.

I also noticed,that some of the triangles on the surface of the ships flicker between light and shadow as the camera moves, i.e you can see the triangles which make up the mesh…

I am assured that my meshes all have level surfaces…

Any ideas anyone?

dd

i think this is a zbuffer problem… how are your settings?

how much zbufferbits? ( if you have a geforce, real zbufferbits = colorbits - stencilbits, had this one time 16bit color mode and 8bit stencil, result whas 8bit depthbuffer, not very nice indeed )

near/far clipplane settings? try to move the near more far away, and the far more near…

Hi,
So you can modify the number of bits which the z buffer uses? Kind of explains what is going on…

How do I modify this parameter?

dd

After a bit more thought:

The near clip plane is set to 0.1, the far clip plane is set at 10000.0.

I did this to ensure my planets did not suddenly appear out of nowhere, as I approached them…i.e they start very small
and grew as I got nearer.

After a bit more thought:

The near clip plane is set to 0.1, the far clip plane is set at 10000.0.

I did this to ensure my planets did not suddenly appear out of nowhere, as I approached them…i.e they start very small
and grew as I got nearer.

ok, the depthbufferdepth is choosen with the PIXELFORMATDESCRIPTOR struct, but, as i explained, depending on driver(-settings) it can be choosen automatically…

first, u create a spacetrading simulation… so i think your meshes dont need to come too near to the cam, so set near to 1.f … try if it is a problem to do so… second, perhaps you should use 2 depthbuffers_passes, means first you set your clipplanes to for example 100 -> 1000000 and render all things behind 100 ( planets mostly… ), then clear the depthbuffer and after you set it to .1f -> 100 to render the rest…

but the rest is just setting the depthbufferdepth to a higher res and try to set the near as far as possible ( and perhaps you can take the far a little nearer… )

Thanks guys, it was the near and far clipping planes, and after bringing them closer together, my polygons are no longer competing!!!

5 stars to dave!!!

>> At first I thought, ‘depth buffer’ but GL_DEPTH_TEST is enabled, and I have called glEnable( GL_DEPTH ) also.

Err… there is no enable enum by the name of GL_DEPTH.

glEnable(GL_DEPTH_TEST) is what you’re looking for there. Unless you just typed it wrong.

Siwko

I meant

glEnable ( GL_DEPTH_TEST )
glDepthMask( GL_TRUE );

sorry about the typing mistake!

dd

btw, do you have culling enabled? glEnable( GL_CULL_FACE );… perhaps CW or CCW, like that there can be much stress taken away with z-buffer problems, too…

You could sort your drawables in two bins, “far away” and “nearby” (with some overlap). Then you’d draw like this:

  1. clear Z buffer
  2. set near/far to (100, 10000)
  3. draw far away bin
  4. clear Z buffer
  5. set near/far to (0.2, 200)
  6. draw nearby bin

This way, you don’t get Z fighting even with 16 bit Z buffers.

The two stage drawing idea is a great one also… I’ll have a go!!

Clearing the depth buffer twice in a single frame? Isn’t that a bit extreme?
Just scale your distances down…
For an experiment, put your near and far clip planes back to the values they were at when you had the triangle flicker problem.
Then add this command at the start of your render loop…
glScalef(0.25f, 0.25f, 0.25f);

Do you see the improvement?
I’m not suggesting you use glScale (screws up normals), but it should indicate that your distances are too big…so long as everything is relative, you should do a uniform scale of all your coordinates and you’ll have no problem.