Hi glumpy team!
Thank you for a wonderful library.
I'm one the authors of kaolin-wisp. We use glumpy as a dependency to draw layers of info on our interactive renderer canvas.
Specifically, wisp uses the imgui backend for the gui system:
We've had some users complaining about the glfw_imgui backend triggering invalid_operation GL_ERRORs on standard functions
(i.e. glGetUniformLocation). See for example:
#304
and also:

One of the users correctly pointed out that imgui's glfw / opengl integration assumes a glsl shader #version 330 (>=OpenGL 3.3):
https://github.com/pyimgui/pyimgui/blob/74c359702542c4319f4541bab6825597991e980a/imgui/integrations/opengl.py#L15
Then comes the tricky part - I followed your suggestion on issue 304 and upgraded our pipeline to run on GL 3.3 core:
app.use(f"glfw_imgui (GL 3.3 core)")
win_config = app.configuration.get_default() # note: app.configuration.Configuration() returns the wrong gl version here
The shaders / programs we use (which are fairly basic), throw an invalid operation error once more, on this line:
https://github.com/glumpy/glumpy/blob/master/glumpy/gloo/variable.py#L401
I'm assuming that's due to a VertexArrayObject missing, so I added one, following the two-vertex-arrays example.
This time, whether gloo.Program takes version=330 (and attributes, varyings are replaced with in, out, etc) or not, I'm crashing on the draw call in Program.draw():
Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)
Then I saw this paragraph mentioning glumpy sticking to GLES 2.0 (which is on par with GL 2.1).
Can you please clarify the level of support for gloo here for higher gl versions? Is the GL 3.3 setup fully supported and compatible with imgui..?
UPDATE: switching glfw_imgui (GL 3.3 core) to glfw (GL 3.3 core) and temporarily commenting out imgui seems to work after the VAO fix. An integration issue perhaps?
Hi glumpy team!
Thank you for a wonderful library.
I'm one the authors of kaolin-wisp. We use glumpy as a dependency to draw layers of info on our interactive renderer canvas.
Specifically, wisp uses the imgui backend for the gui system:
We've had some users complaining about the
glfw_imguibackend triggeringinvalid_operationGL_ERRORs on standard functions(i.e.
glGetUniformLocation). See for example:#304
and also:

One of the users correctly pointed out that imgui's glfw / opengl integration assumes a glsl shader
#version 330(>=OpenGL 3.3):https://github.com/pyimgui/pyimgui/blob/74c359702542c4319f4541bab6825597991e980a/imgui/integrations/opengl.py#L15
Then comes the tricky part - I followed your suggestion on issue 304 and upgraded our pipeline to run on GL 3.3 core:
The shaders / programs we use (which are fairly basic), throw an
invalid operationerror once more, on this line:https://github.com/glumpy/glumpy/blob/master/glumpy/gloo/variable.py#L401
I'm assuming that's due to a VertexArrayObject missing, so I added one, following the two-vertex-arrays example.
This time, whether
gloo.Programtakesversion=330(andattributes,varyingsare replaced within,out, etc) or not, I'm crashing on the draw call inProgram.draw():Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)Then I saw this paragraph mentioning glumpy sticking to GLES 2.0 (which is on par with GL 2.1).
Can you please clarify the level of support for
gloohere for higher gl versions? Is the GL 3.3 setup fully supported and compatible with imgui..?UPDATE: switching
glfw_imgui (GL 3.3 core)toglfw (GL 3.3 core)and temporarily commenting out imgui seems to work after the VAO fix. An integration issue perhaps?