glDrawElements() + sf::Text = Access Violation in nvoglv32.dll

[Suslik]

Hey folks. Situation is as follows.
I render some debug text like this:

    sf::Text line0("Some text to render", debugInfoFont, 20);
    line0.setPosition(10.0f, 20.0f * 1);
    debugInfoWindow->draw(line0);
    //debugInfoWindow->resetGLStates(); //does not help
 

Then I render native opengl geometry like this:

      glEnableClientState (GL_VERTEX_ARRAY);
      glVertexPointer(3, GL_FLOAT, sizeof(Mesh::Vertex), &(vertices[0].pos.x));
      glEnableClientState(GL_NORMAL_ARRAY);
      glNormalPointer(GL_FLOAT, sizeof(Mesh::Vertex), &(vertices[0].norm.x));
      glDisableClientState(GL_TEXTURE_COORD_ARRAY); //just to ensure no texture coordinates are read
      glDrawElements(GL_TRIANGLES, faces.size() * 3, GL_UNSIGNED_INT, faces[0].incidentVertices);
 

And sometimes glDrawElements causes AV in nvoglv32.dll. Emphasis on "sometimes" because I was even unable to make a minimal code: even the large project I'm working on does not always crash. Sometimes it works just fine, sometimes it crashes on 2nd program loop iteration. Debug/Release do not affect behavior in any way. Program does not crash if I disable either text rendering or glDrawElements() calls. Looks like text rendering leaves some buffers unflushed and it breaks something later. I tried adding window->display() after rendering the text in hope that it'll flush the buffers but the program still crashes just the same way.

Also some debugging revealed that if I wrap my text rendering code into this:

glPushClientAttrib(GL_CLIENT_ALL_ATTRIB_BITS);
{
    sf::Text line2("howdy", debugInfoFont, 20);
    line2.setPosition(10.0f, 20.0f * 3);
    debugInfoWindow->draw(line2);
}
glPopClientAttrib();
 

the program no longer crashes but after rendering the 1st frame text disappears. Apparently it has something to do with SFML not resetting some of its buffers between calls, but how can that be helped?

Any suggestions?

[Suslik]

Ok I got it. Cost me a night though. Looks like even though I did reset texture array just to be sure:

glDisableClientState(GL_TEXTURE_COORD_ARRAY);

I have completely forgotten about other buffers that I never use. More specifically it's color buffer, resetting it as well solves the problem. Working code:

glPushClientAttrib(GL_CLIENT_ALL_ATTRIB_BITS);
glDisableClientState(GL_TEXTURE_COORD_ARRAY);
glDisableClientState(GL_COLOR_ARRAY);
//initializing buffers I actually use
glDrawElements();
glPopClientAttrib();
window->draw(text);
window->display();
 

So the question is: Is there a better way than resetting all buffers manually? Unfortunately window->pushGlStates() and window->popGlStates(); seem to ignore client states altogether so they're irrelevant here. Any mechanisms that I'm supposed to use in this case?

[binary1248]

Is there a better way than resetting all buffers manually?

No.

Any mechanisms that I'm supposed to use in this case?

No.

If you want performance while interleaving OpenGL and SFML rendering, you will have to resort to manually managing states as you are doing now. Client side arrays are deprecated anyway and if you are serious about OpenGL, you should probably look at the more modern way of rendering using server objects (Shader + VBO + VAO).

[Suslik]

If you want performance while interleaving OpenGL and SFML rendering, you will have to resort to manually managing states as you are doing now. Client side arrays are deprecated anyway and if you are serious about OpenGL, you should probably look at the more modern way of rendering using server objects (Shader + VBO + VAO).

Even though client side arrays are deprecated in 3.0 they are performing better at my task than VBO's because I have a lot of small independent different objects whose geometry is changed every frame(they're soft bodies) and it looks like switching/updating/calling that many VBO's works slower than just passing these buffers every frame from client side arrays.

Even though I have used vbo's extensively before I have not yet tested a whole basic pipeline how it's supposed to work in OGL 3/4. Especially I'm interested in how to do so in SFML. Can you give me a basic example of OGL 3/4-way rendering geometry with SFML-based context? Also am I right that SFML itself uses deprecated features and is incompatible with 3.0 context so that I'll just have to use "modern" functions in "legacy" context?

[binary1248]

Even though client side arrays are deprecated in 3.0 they are performing better at my task than VBO's because I have a lot of small independent different objects whose geometry is changed every frame(they're soft bodies) and it looks like switching/updating/calling that many VBO's works slower than just passing these buffers every frame from client side arrays.

No offence, but if client arrays are faster than buffer streaming, then you likely did something wrong. Internally, the driver and GPU don't do anything else than use buffers even if you use client arrays. Somehow, a block of memory needs to get updated on the GPU every frame, and how that gets done depends on what code you choose to write. If you are talking about the overhead of having to rebind and update many small buffers every frame, you might want to consider some of the more "advanced" draw functions that OpenGL provides. They allow you to use a single buffer per attribute (assuming that you use a single vertex layout) for multiple draw operations, which eliminates the need to update a large number of smaller sized buffers. Also, don't forget that having to rebind each buffer and call glVertexAttribPointer every frame becomes unnecessary when using VAOs.

There are enough resources on the internet about reducing the overhead in modern OpenGL, which I assume is what was causing the inferior performance of the server object variant. OpenGL is very powerful and flexible, one just has to know what the most efficient way to get something done is .

Even though I have used vbo's extensively before I have not yet tested a whole basic pipeline how it's supposed to work in OGL 3/4. Especially I'm interested in how to do so in SFML. Can you give me a basic example of OGL 3/4-way rendering geometry with SFML-based context? Also am I right that SFML itself uses deprecated features and is incompatible with 3.0 context so that I'll just have to use "modern" functions in "legacy" context?

You use OpenGL basically the same way as you do using any other library (GLUT, SDL, GLFW, etc.). First, you create the SFML window. If you want sfml-graphics rendering as well, you will have to create an sf::RenderWindow, otherwise an sf::Window will suffice for pure OpenGL rendering. After the window is created, an OpenGL context will automatically be active. From there, you do the usual thing with OpenGL.

SFML supports requesting any context version. However: This is subject to what the operating system is willing to provide. On Windows, and Linux if you use proprietary drivers, SFML will request a compatibility profile context in order for sfml-graphics to function. Unfortunately, this applies to sf::Window as well even though it isn't part of sfml-graphics. Work is under way to allow the user to explicitly request a core profile context on creation of an SFML context. This is necessary for requesting any of the non-legacy OpenGL versions on OS X and Linux if you use the free drivers.

What this means is that if you use Windows, you have nothing to worry about. Just request a 3.2 context and you will get something you and SFML can both use. If you use OS X or Linux with free drivers, you can still request a 2.1 context and rely on extensions to get access to the newer features. Either way, you will have to use a loader to provide the defines and function signatures for the newer stuff.

You can restrict yourself to the "modern" API even in a compatibility profile context, yes. This means that your code is future-proof and portable across many more platforms if that is a concern. When the time comes (i.e. SFML 3 ), SFML might switch to solely using the core API when it can as well, so in that case, your whole application will be core only. It is never a bad idea to start getting used to writing modern OpenGL code now.

[Suslik]

Ok I did some testing. I used interleaved VBO vertices + indices in GL_STATIC_DRAW_ARB mode without passing any geometry to GPU every frame vs using fully client-based approach that dumps the whole geometry from RAM to GPU every frame without VBO. I have NVidia GF720 and results are as follows:
VBO: about 95fps
Client-based data: about 70fps

So there's a difference in favor of VBO but not super-significant. Scene consists of around 1000 meshes with 100-1000 polygons each. Using glBegin()/glEnd() is deprecated for a reason - drops fps about 10x.

I'm not sure I want to use VAO just because it's fancy and included in the new standard. Data is already relatively GPU-friendly and is not stored in RAM where possible(dynamically changing objects are still updated by glBufferSubDataARB()).

I'm currently using lame way of obtaining extensions like wglGetProcAddress("glGenBuffersARB"); There's also glew but it kinda kills cross-platformability of SFML because glew means windows. Is there a better way to use those extensions with SFML?

[binary1248]

VBO: about 95fps
Client-based data: about 70fps

So there's a difference in favor of VBO but not super-significant.

10.5ms vs 14.2ms isn't significant? I don't like repeating what has been said many times before, but comparing FPS values doesn't make sense since it isn't linear. This is a 35% increase in performance and for me that is significant enough to warrant serious consideration.

I'm not sure I want to use VAO just because it's fancy and included in the new standard. Data is already relatively GPU-friendly and is not stored in RAM where possible(dynamically changing objects are still updated by glBufferSubDataARB()).

I don't know about you, but I have faith in the ARB only adding things that actually have functional value to the specification. It is "fancy" for a reason: It enables you to reduce the call and driver overhead of each frame, especially when drawing a large number of small batches. This has nothing to do with how vertex data is transferred. If you are unsure about what VAOs are and how to use them, you can read up about them more on the internet.

If your application turns out to be bottlenecked by a high amount of glBufferSubDataARB() calls (remember, profile!), then you might want to consider introducing a buffer manager that batches updates into bigger chunks if you already store all of it in a single buffer. Often, it is "cheaper" to update buffer content once, even if you transfer more data than needed, than to update it many times each time transferring very little data. Driver overhead must never be underestimated.

I'm currently using lame way of obtaining extensions like wglGetProcAddress("glGenBuffersARB"); There's also glew but it kinda kills cross-platformability of SFML because glew means windows. Is there a better way to use those extensions with SFML?

Huh? Yet another misconception... GLEW's sole purpose is to provide a cross-platform way to load extensions. If it were to only work on Windows, there would be no reason for people to use it. Indeed, there are even pre-built packages on every major Linux distribution of it. You can use GLEW, and SFML uses GLEW itself internally. However I would recommend against using SFML's copy of GLEW since it is going to be replaced soon. I currently use a custom generated loader using glLoadGen. It is much cleaner to use than GLEW and far more lightweight. Its documentation can be found here.

[Suslik]

10.5ms vs 14.2ms isn't significant? I don't like repeating what has been said many times before, but comparing FPS values doesn't make sense since it isn't linear. This is a 35% increase in performance and for me that is significant enough to warrant serious consideration.

30% fps increase is not that significant for a super-unoptimized renderer I had before. It's a very naive implementation of a debug renderer that I've written a few years ago and I expected way better performance boost after optimization. For example turning glHint (GL_LINE_SMOOTH_HINT, GL_NICEST); off increased performance about 2x times for me because OpenGL has really lame implementation of smoothed lines and I had a lot of them in the scene. I also used glBegin()/glEnd() back then and replacing them with client states had similar impact.

I don't know about you, but I have faith in the ARB only adding things that actually have functional value to the specification. It is "fancy" for a reason: It enables you to reduce the call and driver overhead of each frame, especially when drawing a large number of small batches. This has nothing to do with how vertex data is transferred. If you are unsure about what VAOs are and how to use them, you can read up about them more on the internet.

Am I right that the only benefit of VAO's is that you have only 1 ogl object bind per game object? So instead of setting separate buffers for vertices, normals and stuff you set up just 1 VAO? So the only benefit is reducing number of object bind calls?

If your application turns out to be bottlenecked by a high amount of glBufferSubDataARB() calls (remember, profile!), then you might want to consider introducing a buffer manager that batches updates into bigger chunks if you already store all of it in a single buffer. Often, it is "cheaper" to update buffer content once, even if you transfer more data than needed, than to update it many times each time transferring very little data. Driver overhead must never be underestimated.

My application is bottlenecked at physics simulation because, it's a physics simation program, duh. I was optimizing the debug renderer and making it more comfortable for use(swithed from my own old testbed to SFML). Also learning new tendencies in rendering code proved to be quite fun.

Huh? Yet another misconception... GLEW's sole purpose is to provide a cross-platform way to load extensions. If it were to only work on Windows, there would be no reason for people to use it. Indeed, there are even pre-built packages on every major Linux distribution of it. You can use GLEW, and SFML uses GLEW itself internally. However I would recommend against using SFML's copy of GLEW since it is going to be replaced soon. I currently use a custom generated loader using glLoadGen. It is much cleaner to use than GLEW and far more lightweight. Its documentation can be found here.

Well that's interesting. I always thought that W in GLEW stands for Windows. Pretty silly of me, then I think I'll just stick to it. Though header generation utility looks very interesting(boost has a similar one for stripping headers off).

[binary1248]

Am I right that the only benefit of VAO's is that you have only 1 ogl object bind per game object? So instead of setting separate buffers for vertices, normals and stuff you set up just 1 VAO? So the only benefit is reducing number of object bind calls?

It's kind of hard to explain, but simply put, it saves vertex attribute bindings as well as the element array binding. I assume you are familiar with having to bind buffers to ARRAY and ELEMENT_ARRAY binding points. Well... A Vertex Array Object saves the attribute ARRAY bindings as well as the ELEMENT_ARRAY binding itself. This means that instead of having to go through the whole "bind buffer, bind attribute, bind buffer, bind attribute, ... , bind element buffer" every frame, you can save it inside a VAO and simply bind it instead. When it is bound, the saved bindings are restored and used by the GL. When it is unbound, the bindings get reverted to whatever they were before. In fact, not having a VAO bound when drawing is even an error in modern OpenGL.

You might or might not have understood what I just said, but to understand how VAOs work and why they are useful, you first have to understand how binding points and attribute binding works. There are numerous specialized sources on the internet where you can get more information from, so I suggest referring to them instead of relying on me :
https://www.opengl.org/registry/specs/ARB/vertex_array_object.txt
https://www.opengl.org/wiki/Vertex_Specification#Vertex_Array_Object
http://stackoverflow.com/questions/11821336/what-are-vertex-array-objects
http://ogldev.atspace.co.uk/www/tutorial32/tutorial32.html
http://www.swiftless.com/tutorials/opengl4/4-opengl-4-vao.html
https://open.gl/drawing

I always thought that W in GLEW stands for Windows.

GL Extension Wrangler .

[Suslik]

Am I right that the only benefit of VAO's is that you have only 1 ogl object bind per game object? So instead of setting separate buffers for vertices, normals and stuff you set up just 1 VAO? So the only benefit is reducing number of object bind calls?

It's kind of hard to explain, but simply put, it saves vertex attribute bindings as well as the element array binding.<...>

Umm. I don't see how that's any different from what I've said. Regardless, I'm definitely not after performance boost of saving 3 extra bindings per object atm. It's just a debug renderer and it has way more significant performance flaws(like I don't do any geometry frustum culling at all) yet it's nice to know how they actually do it right nowadays. Ty for the info/

[binary1248]

Umm. I don't see how that's any different from what I've said.

What I took from what you said is that you understand that you need one VAO per game object. It is not uncommon for multiple game objects to reside in the same buffers, thus enabling you to draw them all with the same VAO. The mapping is not VAO -> Game Object, it is VAO -> Vertex Layout. The only reason why you would need more than one buffer for vertex data is either: 1. The data layout/format is different, or 2. You update them at differing frequencies, thus being able to segregate static data from dynamic data.

Like all things in OpenGL, if you don't need to create more then don't. The same applies to VAOs as VBOs, textures, shaders, FBOs etc. If you can make due with a handful, then great, but there is no need to start "cloning" VAOs just because each game object has to have it's own. Doing this, you probably won't end up with much of a performance gain either.

Like I already said, when working with OpenGL one has to give a bit of thought to the overall structure of your data and the pipeline. In the end, the easier you make it for the driver and GPU to get their work done, the more performance you will get in return.

Regardless, I'm definitely not after performance boost of saving 3 extra bindings per object atm.

If you have 1000 objects and consider that you bind 3 attributes per object along with the array and element buffer bind, that is at least 6 calls per object and 6000 calls in total if you don't unbind the buffers after each object draw. I don't know about you, but I start to shiver when I see such numbers . I estimate (without sample code I can't do any better) that you can probably cut that down to below 100 total calls every frame if you employ the strategy I described above. The difference might be noticeable depending on your hardware and driver.

It's just a debug renderer and it has way more significant performance flaws(like I don't do any geometry frustum culling at all) yet it's nice to know how they actually do it right nowadays.

Maybe on your next project you might start using VAOs from the start then. You get used to it in no time, trust me .

[Suslik]

Yeah thanks for the explanation. So do I understand correctly how efficient rendering goes in 3.3?
Init: create a single VAO for all scene objects that have the same layout.
Render: render parts of this VAO with different offsets passing each object's model matrix to the shader.

Is this scheme correct? If so, I'll still have as many DIP's(in our case glDrawElements() calls) as scene objects. Can I somehow pass their model matrices and then render them all in 1 DIP?

I have also browsed through the links you gave above(I've read most of them while learning ogl 3.3) and all of them explain how to create vao's and vbo's which's not a problem really. But none of them explain how to use them effeciently in common bulk geometry rendering scenarios like a lot of objects with different textures and matrices. Do you have any links for that?

[binary1248]

Yeah thanks for the explanation. So do I understand correctly how efficient rendering goes in 3.3?
Init: create a single VAO for all scene objects that have the same layout.
Render: render parts of this VAO with different offsets passing each object's model matrix to the shader.

Is this scheme correct? If so, I'll still have as many DIP's(in our case glDrawElements() calls) as scene objects. Can I somehow pass their model matrices and then render them all in 1 DIP?

First of all, there are waaay more draw functions than merely glDrawArrays() and glDrawElements() . You can refer to this page on the wiki for the other variants. I have used many of them, but not all. They all have their purposes and you will have to decide which fits your requirements the best.

Secondly, remember, the idea is to batch those draw calls into one giant draw call if possible. This video has a nice explanation of how to do that (you can watch the whole video too of course ). To do that, you will have to move the other calls that you have between draw calls "out". Either feed it to the pipeline as attributes if possible or move that data into its own buffer object as well.

As an example, if you have to specify a different matrix per object, why not pass them as "attributes" as well? If you put them in a separate buffer, you can make use of a vertex attribute divisor to make sure that a single matrix is consumed per object as opposed to per vertex. You can also batch them into a uniform buffer, or if they don't fit, resort to buffer textures. Buffer textures are a bit more complicated than uniform buffers, but have basically "unlimited" size. The possibilities are truly endless. UBOs are a bit more advanced and TBOs are much more advanced, so don't be afraid if you don't understand them from the beginning.

I have also browsed through the links you gave above(I've read most of them while learning ogl 3.3) and all of them explain how to create vao's and vbo's which's not a problem really. But none of them explain how to use them effeciently in common bulk geometry rendering scenarios like a lot of objects with different textures and matrices. Do you have any links for that?

There isn't really a "go-to" example for every scenario. Most of the time you will find that you need to piece together a solution for your own problem from the knowledge that others have shared about their problems. I have spent hundreds of hours going through documentation and the code people provide to see their solutions and tricks. There is no real theory or standard practice that you can learn regarding OpenGL coding techniques, I'd say most of the knowledge you get is through experience. Over time you also end up developing tricks of your own that you didn't find elsewhere. Your scenario already touches on what I would consider "advanced techniques", so don't be put off by the amount of learning that you will have to invest. It will be worth it in the end .

All I can say is that it is possible to draw 1000 meshes, each with their own vertex data (same format of course) but differing matrices using a single draw call. You can provide per-object data that isn't a matrix in either a buffer or as an attribute. In fact, I have gotten away with drawing 4000 objects at 1000 FPS before by abusing geometry "instancing" using per-instance data to vary them inside the shader using TBOs (contrary to what many people think, geometry instancing doesn't mean everything needs to look identical). Once you see how powerful the GL is and the possibilities that it provides you, you will never turn back... It is simply too addictive .

[Suslik]

  The problem is, there's sometimes too much possibilities. Sometimes I don't want to get all creative and go invent a bicycle, I just need a well-tested and a well-performing way of solving a commonly-encountered problem.

  Current situation reminds me of C++ - the language is very powerful, allows using very different coding styles and design patterns. However in practice contrary to what one may expect that often goes as disadvantage because C++ programs often end up being designed too differently and even though the only way of finding best practices is experience, every programmer ends up converging to different code design strategies. Java, C# and other languages often have weaker syntax but explicitly specified best practice code design patterns which ends up in better usability.

  As a bottom line while it's fun tinkering with all different ways of solving problems OpenGL provides sometimes I need a well-tested best practice solution similar to ones DirectX SDK has.

[binary1248]

The problem is, there's sometimes too much possibilities. Sometimes I don't want to get all creative and go invent a bicycle, I just need a well-tested and a well-performing way of solving a commonly-encountered problem.

But therein lies the problem: What is a commonly-encountered problem? And does the solution perform as good in any scenario? OpenGL has gone through a lot of change in the recent years, and many developers have not bothered to catch up, sticking with old practice. Since styles are so divergent, it is difficult for a single "standard practice" to emerge. The same can be said about C++11, although eventually people will get used to the modern way of writing C++ code since it is objectively superior to legacy code in every aspect.

As a bottom line while it's fun tinkering with all different ways of solving problems OpenGL provides sometimes I need a well-tested best practice solution similar to ones DirectX SDK has.

See... that is the thing with the constant DirectX vs OpenGL debate. DirectX people who try out OpenGL are always put off by the sheer possibilities that they have at their disposal to get a job done (and this implies the number of ways they can screw up as well). I haven't done much DirectX coding, but if what you say is true and Microsoft advocates usage of the SDK in certain ways, then it stands in direct contrast to what OpenGL stands for. OpenGL is like a toolbox. It contains multiple tools, each with their strengths and weaknesses and it is up to you to combine them to get the job done as efficiently as possible. DirectX is like a single "all-in-one" tool. Obviously this tool is easier to optimize for many foreseeable use cases, but if your problem does not fit into the set of solutions that it was designed for, you are more or less out of luck. As a layperson, you might find it more appealing to have to only use a single tool for almost every job, but if you ask a "professional" whether they will repair something for you using your all-in-one tool, they will most likely smile at you while carrying their toolbox into your house .