PDA

View Full Version : Static... How do I get rid of it?



ceige
03-18-2004, 12:14 AM
I'm in the middle of programming a remake of the old SemiColon Software game Scarab of Ra and just finished the maze generator when I ran into this problem. This is pretty much my first OpenGL program so I don't really know what I'm doing yet. Whenever I draw the maze and rotate the maze I see all this static like distortions along the edges of the maze. It goes away when I glDisable( GL_DEPTH_TEST ); but I don't want to do that for obvious reasons. http://www.opengl.org/discussion_boards/ubb/smile.gif I think I know why it happens but I still don't know how to fix it.

Does anyone know how I can work around this to make the image look more crisp?

Here are two pictures of the maze with the static like edges. http://chris.reachjapan.org/images/Screenshot.png http://chris.reachjapan.org/images/Screenshot2.png

Thanks for the help.

-ceige

Honk
03-18-2004, 12:34 AM
Looks like z-fighting. That means the precision of your z-buffer is too low.

Try to request a 24/32 bit z-buffer or change your near and far clipping planes (1.0 and 100.0 may do the job).

ceige
03-18-2004, 04:00 AM
Could you give me some code to work off of?
Thanks for the quick reply.

-ceige

endash
03-18-2004, 07:07 AM
Looks like Z fighting. You may have to add an offset (See page 250-253 of the red book).

maximian
03-18-2004, 11:07 AM
I would stay away from depth offset. It cause a lot of other problems, and does not always give you a good result. For near,far planes, look at your glOrtho or gluPerspective, or your func that produces the projection matrix. Look up its defenition and find where it says near and far plane. Then set near to 1, and far to some other value > 1. 16 bit depth is default and is usually fine unless you have a high count poly or are dealing with very small or very large numbers.

Honk
03-18-2004, 11:43 AM
Ceige perhaps you can post your code how you are setting up the pixelformat (in case you set it up yourself and dont use glut or something alike) and your glFrustum() call.

P.S.: When posting code please use the code tags.

ceige
03-19-2004, 05:52 PM
I'm using the SDL port of the NeheGL code. It seems to work well so I haven't looked it over that carefully.

Here my resizeWindow() code if that helps. It has the gluPerspective() code in it.





/* function to reset our viewport after a window resize */
int resizeWindow( int width, int height )
{
/* Height / width ration */
GLfloat ratio;

/* Protect against a divide by zero */
if ( height == 0 )
height = 1;

ratio = ( GLfloat )width / ( GLfloat )height;

/* Setup our viewport. */
glViewport( 0, 0, ( GLint )width, ( GLint )height );

/*
* change to the projection matrix and set
* our viewing volume.
*/
glMatrixMode( GL_PROJECTION );
glLoadIdentity( );

/* Set our perspective */
gluPerspective( 45.0f, ratio, 0.1f, 100.0f );

/* Make sure we're chaning the model view and not the projection */
glMatrixMode( GL_MODELVIEW );

/* Reset The View */
glLoadIdentity( );

return( true );
}


[This message has been edited by ceige (edited 03-19-2004).]

ceige
03-20-2004, 02:57 PM
gluPerspective( 45.0f, ratio, 0.1f, 100.0f );


So looking at the definition of gluPerspective my near values are .1 and my far values are 100. Is that not a big enough of a range? Is that really the problem here?

Overmind
03-20-2004, 11:49 PM
The problem propably is that the range is too big to be stored completely in the z-buffer.

Try setting the near plane as far away possible without cutting away any geometry (I would try 1.0). You may also move the far plane in, but usually moving the near plane out works better.

ceige
03-29-2004, 12:53 AM
All right, I'll try that suggestion.

Just wondering though...
What exactly are the near and far planes? What do they mean?

ceige
03-29-2004, 02:40 AM
I've done a couple more google searches for research and I've got a better idea now of what I'm dealing with.

The program I'm working on generates mazes. The way it's set up is with cells for each room in the maze. When two or more cells are right up against one another, as they generally are, they share walls.

I understand that because there are two walls so close together it is causing z-fighting or flimmering which can be fixed by changing the near and far plane values.

But my walls share the same area in space!
Can that be fixed by changing the near and far values?

I could just reconfigure my maze code to only draw one of the walls but I still want to know the answer to my question just in case.

chowe6685
03-29-2004, 04:18 AM
if they really are drawn in exactly the same place, it seems unlikely that any amount of z-buffer precision can help you. Honestly .1 to 100 is a pretty small range to begin with. I would definitely see if you can avoid drawing walls on top of one another.

roffe
03-30-2004, 09:17 AM
Originally posted by ceige:
But my walls share the same area in space!
Make sure you turn on back face culling.
glCullFace(?)/glEnable(GL_CULL_FACE)