4
\$\begingroup\$

When switching version of OpenGL from 4.5 to 4.4, I suddenly started seeing these weird random triangles flickering over my scene

t1

They move around somewhat randomly and are always pointed towards [0,0].

Given that this only appears in 4.4 and not in 4.5, my guess would be that I have some undefined behavior that manifests only in one version? I'm not using any advanced OpenGL, just drawing basic triangles with VBO buffers.

How should I go about debugging these sorts of issues, and what are the likely causes that manifest as artifacts? (The hexes and the white-ish path are what I inteded to draw, only the black/yellow/blue triangles are the artifacts)

\$\endgroup\$
6
  • \$\begingroup\$ Maybe there are NaN or very large values in the W components of the points after projection. Probably they didn't appear before because of differences in the way one version (or rather, implementation) of OpenGL is clipping the polygons vs the other version. \$\endgroup\$
    – Gato
    Apr 26, 2016 at 23:59
  • \$\begingroup\$ Add asserts to make sure your counts and offsets are within bounds on calls to DrawArrays/DrawElements. If you pass bad counts or offsets, GL will just read through the program memory and attempt to draw whatever it finds. \$\endgroup\$
    – glampert
    Apr 29, 2016 at 2:00
  • \$\begingroup\$ Run your application in a graphics debugger like gDEBugger or CodeXL. At the very least you will be able to locate where the triangles comes from. \$\endgroup\$
    – Andreas
    Apr 29, 2016 at 21:35
  • \$\begingroup\$ @Andreas Thanks for recommending this, though I gave gDEBugger a try, and I'm not sure how to locate where a specific triangle is coming from? \$\endgroup\$ Apr 30, 2016 at 8:46
  • \$\begingroup\$ You may step through draw calls. Look at the back buffer while you step. When the triangle appears read the state to see if it is sane. It is a needle in a haystack but better than just looking at the drawn image and randomly poking the code. \$\endgroup\$
    – Andreas
    Apr 30, 2016 at 9:31

2 Answers 2

8
\$\begingroup\$

There are a number things that could cause these problems. Here are some things to try:

  • Bad vertex coordinates. One way to debug it is to print your coords to the console and check for things like NaN, Inf, etc. But it could also be that you're just uploading some wrong, but not obviously bad coordinates. One way to debug this is to bisect your data. Send only half to the card and see if it happens. If not, send the other half. Keep bisecting the data until you've figured out which vertices are the problem
  • Bad near/far plane settings. If you make your near plane too close to the camera, depth testing can get wonky and produce odd artifacts like this. If the far plane is too far, then you might not have enough precision. You can debug it by checking your near and far settings and changing them to see if the problem goes away.
  • Not clearing the frame buffer's color or depth attachment. If the framebuffer isn't cleared junk can be left in it. If you're drawing with blending on, the color results can be odd. If the depth buffer isn't clear, drawing may fail for a given fragment if it's depth is beyond the junk depth value already in the framebuffer. You can debug by checking that you're clearing things before drawing. Maybe look at the framebuffer both before and after drawing.
  • An unexpected shader is active. A fragment shader can color things oddly. Maybe there's a case where you aren't calling glUseProgram() with a new program or clearing it? Debug by ensuring you're getting the program you think you are. You could replace the program you normally use with one that just outputs a solid color and see if it's getting used.
  • Bad shadowing. Maybe your shadow maps are hosed? You could test by turning off your shadows and see if the problem goes away.
  • As @glampert mentions, passing the wrong number of vertices or indices to calls like glDrawArrays(), glDrawElements(), etc. I often forget whether it's number vertices, number of triangles/quads/etc. and pass the wrong value at first. Or passing the wrong stride to one of the above calls. I often think in terms of triangles, but they often want the stride between vertices, not triangles. You can test by passing in a value that's half what you think it should be and see if the problem goes away. If so, add back 1/2 of what you took out and see if it still happens. Keep doing it until the problem returns, then figure out what the proper value is and why.

There are probably other potential issues, but those are the ones I can think of off the top of my head.

\$\endgroup\$
2
  • 3
    \$\begingroup\$ Add to that passing an invalid number of verts or indexes to DrawArrays/DrawElements. The driver will happily attempt to read some random memory past the vertex/index data. If the memory happens to be still within the addressing space of the process, it will just draw junk and not crash. \$\endgroup\$
    – glampert
    Apr 29, 2016 at 1:58
  • \$\begingroup\$ Excellent point! I've added it to the list. \$\endgroup\$ Apr 29, 2016 at 3:13
1
\$\begingroup\$

I was experiencing exactly the same problem in my application when showing DisplayList consisting of TRIANGLE_STRIPs (grid of elevation data). They are extra triangles randomly flickering and moving around, always pointing to [0,0]. And here is my observation:

  • It only happens on some graphics cards (e.g. Intel HD Graphics 4400 with OpenGL 4.0), it runs ok on others (OpenGL 4.5 or even OpenGL 2.1 and 1.4)
  • It only happens if my grid is bigger than 200 x 200 vertices and more importantly:
  • It only happens when I use TRIANGLE_STRIPs to show the grid, if I use just simple separate TRIANGLES for the same data, it runs.
  • What I also find interesting is that using TRIANGLES instead of TRIANGLE_STRIPs has better performance

So I believe it is a problem of OpenGL implementation on some particular HW. I don't see the possibility of using wrong data or invalid pointers.

\$\endgroup\$
2
  • \$\begingroup\$ Strips as the performance path has been obsolete on desktop hardware since 1998; triangles also gives better vertex reuse for grid meshs. \$\endgroup\$ Nov 3, 2016 at 12:42
  • \$\begingroup\$ Ageed. I have the same problem with TRIANGLE_STRIPS, but everything is OK with TRIANGLES. \$\endgroup\$ Feb 20, 2018 at 10:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .