# OpenGL Flickering edges in OpenGL

## Recommended Posts

Mekanikles    139
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 on other sites
polymorphed    272
Try enabling antialiasing.

##### Share on other sites
Tojiro67445    122
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 on other sites
OrangyTang    1298
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 on other sites
Mekanikles    139
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 on other sites
Yann L    1802
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 on other sites
OrangyTang    1298
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 on other sites
Mekanikles    139
@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:

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 on other sites
Mekanikles    139
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 on other sites
Tojiro67445    122
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 on other sites
ma_hty    100
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 on other sites
Mekanikles    139
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:

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 on other sites
NineYearCycle    1538
Quote:
 Original post by MekaniklesAs 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 on other sites
Mekanikles    139
@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 on other sites
ma_hty    100
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 on other sites
zedz    291
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

##### Share on other sites
Mekanikles    139
@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 on other sites
NineYearCycle    1538
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! :)

## Create an account

Register a new account

• ### Similar Content

• Hello. I'm Programmer who is in search of 2D game project who preferably uses OpenGL and C++. You can see my projects in GitHub. Project genre doesn't matter (except MMO's :D).

• Hello, My name is Matt. I am a programmer. I mostly use Java, but can use C++ and various other languages. I'm looking for someone to partner up with for random projects, preferably using OpenGL, though I'd be open to just about anything. If you're interested you can contact me on Skype or on here, thank you!
Skype: Mangodoor408
• By tyhender
Hello, my name is Mark. I'm hobby programmer.
So recently,I thought that it's good idea to find people to create a full 3D engine. I'm looking for people experienced in scripting 3D shaders and implementing physics into engine(game)(we are going to use the React physics engine).
And,ye,no money =D I'm just looking for hobbyists that will be proud of their work. If engine(or game) will have financial succes,well,then maybe =D
Sorry for late replies.
I mostly give more information when people PM me,but this post is REALLY short,even for me =D
So here's few more points:
Engine will use openGL and SDL for graphics. It will use React3D physics library for physics simulation. Engine(most probably,atleast for the first part) won't have graphical fron-end,it will be a framework . I think final engine should be enough to set up an FPS in a couple of minutes. A bit about my self:
I've been programming for 7 years total. I learned very slowly it as "secondary interesting thing" for like 3 years, but then began to script more seriously.  My primary language is C++,which we are going to use for the engine. Yes,I did 3D graphics with physics simulation before. No, my portfolio isn't very impressive. I'm working on that No,I wasn't employed officially. If anybody need to know more PM me.

• By Zaphyk
I am developing my engine using the OpenGL 3.3 compatibility profile. It runs as expected on my NVIDIA card and on my Intel Card however when I tried it on an AMD setup it ran 3 times worse than on the other setups. Could this be a AMD driver thing or is this probably a problem with my OGL code? Could a different code standard create such bad performance?

• I'm trying to get some legacy OpenGL code to run with a shader pipeline,
The legacy code uses glVertexPointer(), glColorPointer(), glNormalPointer() and glTexCoordPointer() to supply the vertex information.
I know that it should be using setVertexAttribPointer() etc to clearly define the layout but that is not an option right now since the legacy code can't be modified to that extent.
I've got a version 330 vertex shader to somewhat work:
#version 330 uniform mat4 osg_ModelViewProjectionMatrix; uniform mat4 osg_ModelViewMatrix; layout(location = 0) in vec4 Vertex; layout(location = 2) in vec4 Normal; // Velocity layout(location = 3) in vec3 TexCoord; // TODO: is this the right layout location? out VertexData { vec4 color; vec3 velocity; float size; } VertexOut; void main(void) { vec4 p0 = Vertex; vec4 p1 = Vertex + vec4(Normal.x, Normal.y, Normal.z, 0.0f); vec3 velocity = (osg_ModelViewProjectionMatrix * p1 - osg_ModelViewProjectionMatrix * p0).xyz; VertexOut.velocity = velocity; VertexOut.size = TexCoord.y; gl_Position = osg_ModelViewMatrix * Vertex; } What works is the Vertex and Normal information that the legacy C++ OpenGL code seem to provide in layout location 0 and 2. This is fine.
What I'm not getting to work is the TexCoord information that is supplied by a glTexCoordPointer() call in C++.
Question:
What layout location is the old standard pipeline using for glTexCoordPointer()? Or is this undefined?

Side note: I'm trying to get an OpenSceneGraph 3.4.0 particle system to use custom vertex, geometry and fragment shaders for rendering the particles.

• 9
• 11
• 21
• 26
• 17