Sign in to follow this  
Mekanikles

OpenGL Flickering edges in OpenGL

Recommended Posts

Hi, I do realize that this has probably been asked a million times before since I know it to be a common problem but I can only find solutions to issues related to texturing. My problem is that I get flickering edges when drawing adjacent surfaces. My surfaces use no textures, they're just phong shaded. The flickering appears as white dots that move around. I want to build a retro style level using building blocks that should appear seamless. Any help would be appreciated, thanx in advance /Mekanikles

Share this post


Link to post
Share on other sites
Don't think antialiasing is the problem here. if you read it carefully, he's getting flickering between polys, not jagged edges.

The first thing I would suggest is looking at your z-buffer resolution. If it's 16 bit right now bump it to 24 and see if that helps. Also, if you have two polygons that are meant to be connected, make sure that their vertices line up EXACTLY. Even an incredibly small offset can lead to rendering artifacts.

Share this post


Link to post
Share on other sites
Yeah, sounds like some form of z-fighting. You might also want to check your calls to glFrustum or glPerspective and see what your near plane is set to. If you've got it set to something ridiculously small (like 0 or 0.1) then you'll waste all your precision near to the camera. Push it out further and see if it helps.

Share this post


Link to post
Share on other sites
Thanx for the swift replies. However, I don't think my Z-buffer is the problem since the adjacent polygons aren't overlapping and I see white artifacts where two black surfaces connect. I do believe it's an precision problem though, that the two edges really aren't connecting properly due to subpixel faults when filling the surfaces. But I am putting the vertices of the surfaces on the exact same spot (I'm only dealing with integer map coordinates). I read somewhere that putting a small border on each surface to "fill up" the possible gap can solve it but then I would get Z-battling between those borders.

On a side note: Lots of less polished PS1 games had this problem so it seems to be rather common :-)

thxnx again /Mekanikles

Share this post


Link to post
Share on other sites
Use indexed primitives (indexed triangle lists or indexed traingle strips being the most efficient), and all these problems will instantly go away. But you could run into some issues with texcoords.

That said, you should not get any kind of sparkling along connected edges, if you really supply the exact same coordinates for connected vertices.

Try to post a screenshot of the artifact, that would help,

Share this post


Link to post
Share on other sites
A screenshot would probably help.

Are you possibly mixing the fixed function pipeline with shaders? That can cause even identical input coords to render to slightly different screen pixels (use the ftransform() function if you really want to mix the two).

Share this post


Link to post
Share on other sites
@Yann L: Hm, I'm not quite sure what you mean, does it pay to use indexed list for simple quads? (my level is made up by connected boxes).

Here's a screenshot anyway:
Screenshot of flickering egdes 2

It doesn't show an awful lot here, but when moving the view it flickers alot, sometimes whole lines of white along the edges. I don't know if the shader has something to do with it, the "white" dots change color from grey to white when moving the lights around, so they seem to be affected by the shader.

@OrangyTang: I do not quite understand what you mean but I am using the ftransform.

thnx /Mekanikles

[Edited by - Mekanikles on March 2, 2008 6:51:51 AM]

Share this post


Link to post
Share on other sites
Update: I've tried modifying the near clipping plane and the artifacts go down significantly (though never quite disappear). At a value of 10 they're almost gone, but that's way too high, I'm using around 1 now and it feels like that's as far as I can go. My far clipping plane is 300 btw if that's any help. I'm using relatively large coordinates where the columns in the picture are about 5*30*10.

Share this post


Link to post
Share on other sites
Well, from the image and near-plane description you gave, I defiantly think that it's what we were saying earlier: The vertices are not the same, numerically, so the subpixel calculations are causing overlap and, naturally, some z-fighting.

It sounds like you want them to be two separate meshes for some reason, so sharing an actual vertex may be impossible here. If that's the case, you will probably want to find a way of preventing the z-test from happening along that edge. If possible disable z-testing when drawing those elements, and if not try using polygon offsets: http://www.opengl.org/resources/faq/technical/polygonoffset.htm

Share this post


Link to post
Share on other sites
This is not the z-fighting problem we usually described.

It is probably because the edge is described by two different sets of vertices on the two side. And therefore, the faces on the left side and right side did not raster to give the same value along the edge. As shown in the image, the dots on the flickering edge appear as white. It is not possible caused by z-fighting as the left side and the right side are converging to the same color which is not white. Indeed, the dots are ceases, just like little holes on the wall. The white dots are the 3D scene behind the surface.

You can verify it easily. Try to paint the 3D scene behind the surface using red color, the dots should become red.

Beside, this problem is more obvious on ATI display card and less obvious on NVidia display card. Therefore, it may disappeared if you replace your display card.

Share this post


Link to post
Share on other sites
Hi again, thnx for all the answers, I can't really say for sure whether it is Z-fighting or creases between polygons but the reason the pixels become white is, as ma_hty mentioned, due to the wall behind them (the vertical wall is actually intersecting the 45 degree ones).

Another picture, here with a ridiculously low near plane:
Image Hosted by ImageShack.us

As you can se, the edge in the screenshot is 'K'-shaped, where one column meets meets two wedge-shaped ones. The reason for building the map like this is that I can eaisly make the level in 2D with, say, MSpaint or something (think DOOM maps). Should I be considering merging all columns into one mesh (no idea how to do that) or can I make sure that the wedges connect somehow?

Share this post


Link to post
Share on other sites
Quote:
Original post by Mekanikles
As you can se, the edge in the screenshot is 'K'-shaped, where one column meets meets two wedge-shaped ones. The reason for building the map like this is that I can eaisly make the level in 2D with, say, MSpaint or something (think DOOM maps). Should I be considering merging all columns into one mesh (no idea how to do that) or can I make sure that the wedges connect somehow?


So basically you've got something like this made up of two seperate objects:

| |__/
| |_/
| |/
| |\

| |_\

| |__\


Where the double vertical lines on the left are one object and the angle ones are another?
In that picture it certainly looks like z-fighting caused by such an issue. Perhaps the correct answer is to get rid of the left-objects (pillar) polygons which are on the side that the tunnel section meets up against. Or to change the model of your tunnel to something like this:


| ||___/
| ||__/
| ||_/
| ||_\

| ||__\

| ||___\


Where you have a gap between the outermost angled "corner" of the tunnel and the pillar, then close it off with an outer side wall for the tunnel model?

Sorry if that's confusing I'm not very good with ASCII art.

As an aside what are you NEAR and FAR clipping planes currently set too? It looks like you can see quite a long way into the distance in that screenshot.

Andy

EDIT : if someone can tidy up those ASCII diagrams that'd great since I can figure out the combination of html + whatever_insanity_GD_uses that will get them to render properly :(

Share this post


Link to post
Share on other sites
@NineYearCycle: You've got it spot on with your awesome ASCII-art, however, with the current implementation of the levels I cannot create thin walls.

I'm building levels almost just like in DOOM, with 2d-polygons with two values on each vertex. One lower and one upper bound, where a column is drawn in the shape of the polygon, sliced where the boundaries are. So, the whole map is built from different columns going from infinite negative to infinite positive with a segment cut out of them. Floors are just large columns where you are placed "inside" the gap. The only difference between this and DOOM is that I'm allowing tilted horizontal surfaces.

Curiosa aside, I think I've gotten the answers I needed. I will try to eliminate the walls that shouldn't be shown by discarding column sides that share 2 or more vertexes with an adjacent column. Or something like that anyway.

Thanx for all the replies /Mekanikles

Share this post


Link to post
Share on other sites
Quote:
Original post by Mekanikles
... The reason for building the map like this is that I can eaisly make the level in 2D with, say, MSpaint or something (think DOOM maps). ...


If this is the only reason, I think you should really consider whether it does make thing easier or not. Most well-designed 3D modeler software can give you 3D model without such problem with just a few click which can suit more situations. If what you are doing is not intuitively easier by a huge extend, what is the point of doing it?

Share this post


Link to post
Share on other sites
the vertices have to be in exactly the same position
as Yann L saiz indexing the same vertice is ideal

have a look at this link also

http://www.google.com/search?q=t-junction+sparklies&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

Share this post


Link to post
Share on other sites
@ma_hty, I know, I know, but this is an project assigment for a computer games course I'm taking and we're supposed to to the level building from scratch :-)

@zedz Thanx for putting a name to my problem!, I will certainly look it up some more.

Share this post


Link to post
Share on other sites
Well you've got the option of fixing the T-junctions but most of those things that I read seemed to advocate avoiding them forming.

Couldn't you introduce a vertical component to the tunnel side sections like so

| | / | | /
| | / | | /
| |/ = | | | <- i.e. this part is flat now.
| |` | | |
| | ` | | `
| | ` | | `

That means that there's a gap between the flat wall of the other column.

Though this is of course the less technical solution to the problem ;)

Andy

EDIT - i give up with the ascii art on this forum :( I recommend cut n' pasting the above into notepad! :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this