The are many of these for each render pass. And after checking with the debugger, it seems the log at vtkOpenGLRenderWindow.c:286 is the result of various different OpenGL calls so I suspect this is a general issue with the OpenGL integration.
Unfortunately I have no idea where to go from here as that is about all the information I have. I really expected this to work once it compiled + ran without crashing since the egui part should be making the OpenGL context active right before calling render on VTK and my impression is that with the external renderer, this is what VTK expects.
I still don’t have things working with egui yet, but egui uses glow at the lower level (at least with its default “eframe” integration) and I now have integration directly with glow working on GitHub - Gerharddc/egui-vtk at glow.
It turns out the warnings were caused by .with_profile(GlProfile::Compatibility) not being passed during context creation as it seems VTK relies on this.
Another important factor to get VTK things visible was to call gl.clear(COLOR_BUFFER_BIT | DEPTH_BUFFER_BIT); before calling the VTK render function. Clearing only COLOR_BUFFER_BIT seems to be insufficient.
I also implemented a way to use gladLoadGL instead of gladLoaderLoadGL to ensure that the exact same OpenGL functions are loaded on the C++ as on the Rust side, but so far this does not seem to be critical to get things working. It might help to avoid nasty issues on other platforms though.
Ok so I finally got this working! In the end I had to resort to rendering VTK inside an offscreen FBO and piping its texture into an egui Image. I actually managed to get VTK drawing without that, but it refused to draw in the correct place for some reason. It drew with the correct size at least though. Anyway, this is probably a nicer approach anyway as it saves VTK from having to redraw for every frame.
Now the last remaining challenge is to get mouse events forwarding…
