How to find cause of blank window with no opengl errors?

Started by
5 comments, last by swiftcoder 6 years ago

I'm having some problems trying to figure out why my application won't draw the triangle I'm telling it to draw on the screen. After every single gl call in my code I check if glGetError() isn't equal to GL_NO_ERRORS, however it always is so I don't have any errors or anything to use when debugging. I'm literally clueless as to why my application won't render the triangle. The only thing that the window displays is a grey background since I set the clear color to be grey.

It would be nice to get some tips as to what to do when your OpenGL window isn't displaying anything and glGetError() returns nothing of use.

Advertisement

Hello. If you can seem to see your triangle it could be a number of things.

You haven't attached your program.

Your view port hasn't been initialised

You haven't drawn the correct number of vertices.

You haven't copied across the correct number of vertices. 

Check you call your draw after you set the background and before you present.

A third party tool that is very useful to check your graphics pipeline and that could highlight what the issue is render doc. It's free.

Or if you have your code on github,  I could review it. 

18 hours ago, Kearney401 said:

Hello. If you can seem to see your triangle it could be a number of things.

You haven't attached your program.

Your view port hasn't been initialised

You haven't drawn the correct number of vertices.

You haven't copied across the correct number of vertices. 

Check you call your draw after you set the background and before you present.

A third party tool that is very useful to check your graphics pipeline and that could highlight what the issue is render doc. It's free.

Or if you have your code on github,  I could review it. 

 

Ah so there are no sort of "general guidelines" that help debugging OpenGL in general? :/

I managed to fix the issue I was having though, I was sending the size of  a single float multiplied by the total amount of vertices in the mesh instead of sending the size of an entire vertex multiplied by the total amount of vertices.

Also, I kinda try to stay away from 3rd party debugging tools since I figure it would be better to learn to manually debug OpenGL in order to learn more about it.

Thanks for the help! :)

And if there are any tips for debugging OpenGL though it would still be awesome if anyone could post them ^^

3 hours ago, Mr.Mushroom said:

Ah so there are no sort of "general guidelines" that help debugging OpenGL in general? :/

Well sometimes... in my dreams.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

Get a graphics debugger like Nsight or RenderDoc. This way you can see what information you ACTUALLY sent up to the gpu and are using, as well as you may be able to debug the shaders

Also be sure to start simple. try first rendering a triangle in screen space. once you get that triangle rendering, use the world (object), view, and projection matrices.

A couple things it could possibly be:

Object rendered behind camera or between camera and near plane of the projection matrix (or beyond the far plane, or of course out of the view frustum (out of sight))

Not clearing depth buffer

Not sending the position (or other attribute like color) data up to a buffer

Not binding the buffer (vbo) before sending the data or drawing the object (not sure if you'd get an error or not), or the vao

Not drawing enough indices (if your using indices), or vertices

Backface culling is opposite of the winding order your currently drawing the object as

Drawing wrong topology (eg. point, line or triangle)

Anyway, maybe one of those will get you looking in the right place

On 04/04/2018 at 2:58 PM, Mr.Mushroom said:

Also, I kinda try to stay away from 3rd party debugging tools since I figure it would be better to learn to manually debug OpenGL in order to learn more about it.

You'll mostly learn weird quirks of the state machine that way, at the cost of great personal frustration.

When GPUs are involved, it's worth using every debugging aid at your disposal.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

This topic is closed to new replies.

Advertisement