[Solved]Bootstrapping the OpenGL3 Renderer crashes my existing rendering code

[MadDoctor5813]

I've recently started using CEGUI, and I've managed to get a button rendering properly. Except, when I stopped testing CEGUI's rendering code, and reenabled my own, I got a null access in nvoglv32.dll, which I believe is the graphics driver for my card, an Nvidia GTX 750. Using gDEbugger, I figured out that it was crashing on my call to glDrawElementsBaseVertex. I also saw that various calls in the CEGUI renderer were creating GL_INVALID_OPERATION errors. I tried commenting out my call to render the GUI, and it still crashed. Finally, I commented out all the CEGUI related code, and then, my existing code started working again. All these signs point to some kind of interference between CEGUI's renderer and mine in the state machine, but finding the culprit seems difficult, what with the million and six OpenGL variables involved. And, while researching this issue, I read that CEGUI's renderer saves and restores GL state anyway. I'm really have no idea what's going on, and have no idea how to proceed. Has anyone else experienced this issue?
My renderer code is here:
IndexedRenderer.h
IndexedRenderer.cpp
The rest of it is also in the repo.
CEGUI.log
I am on x86, Windows 10, and using .dlls, which I think means linking dynamically, I'm not the best at this kind of thing.

[MadDoctor5813]

I figured out the problem. In a true facepalm moment, I wasn't rebinding my array buffers, because I bound them once in the VAO and assumed this carried over when I rebound the VAO later. Apparently, it does not, and I didn't notice because no other buffers were ever bound, until I started using CEGUI's renderer. Hopefully, anyone else who stumbles across this will find a solution, or at least a laugh.

[Ident]

Do you think the documentation could be improved on this or how else would this have been preventable? If it is the docu, where would you change what?

[MadDoctor5813]

I think a little warning somewhere saying, "CEGUI binds its own VAO and buffers, so make sure to rebind yours before rendering" should do it. Also, every piece of OpenGL info I've found online says, somewhat misleadingly, that VAOs remember what buffers you have bound at the time.

[Ident]

CEGUI shouldn't change your vao's. As far as I see CEGUI unbinds the VAO first in the current version of OpenGL3 Renderer (on v0-8 branch which will be 0.8.5 Release). Once your VAO is unbound , it should be invulnerable. This behaviour regarding the unbinding might have been different in the past though.

Where would you like us to insert the information about CEGUI's vaos etc? In the API docu here maybe: http://static.cegui.org.uk/docs/0.8/ren ... orial_draw ?

[MadDoctor5813]

To be honest, I don't think the failure is in your documentation at all. I just misunderstood what people meant when they say online that a VAO will remember what buffers you have bound, which I took to mean the buffer id bound, when they actually meant the buffer binding point, i.e, GL_ARRAY_BUFFER. So, I was binding my own buffers when I created the VAO, and I never rebound them, which was fine while I was just rendering my own stuff, but after I started using CEGUI, suddenly, I was using the CEGUI bound buffers when rendering my own geometry, and this would cause driver crashes because of bad vertex specification. It's really my own fault in the end.