If you get a Mesa build on Windows, you’ll want to point VTK’s build at its SDK and libraries (that is, anything FindOpenGL wants should get the Mesa answers). If you’re doing Qt stuff, you’ll run into this issue and need to tell Mesa to ignore compat bits (workaround is discussed in that issue).
Can you explain why this is necessary? A lot of documentation suggests just carefully naming and place dlls to make sure that mesa is loaded - and this seems to work. Does pointing VTK at Mesa’s SDK/libs result in a better (or faster) connection?
Our deployment scenario is one where most of our customer have sufficient support for OpenGL2, but some won’t and we want the code to switch to mesa in those limited cases. We do NOT want to deal with 2 different builds of VTK for this.
If that works, sure, it’s worth doing. But it’s not something I would necessarily trust to work in such a way without actual testing. It’s more about making sure that nothing is “leaking” around the “this is what OpenGL is” barriers and causing symbol mismatches or such.
I am building vtk 9.2 rc4 static release build with a VS 2019 x64 toolchain. I have osmesa built
using the buildscript in the git repo mentioned in this thread (mesa-dist-win). Configuring my
build to be static with VTK_OPEN_GL_HAS_OSMESA gives the following cmake error:
CMake Error at CMake/vtkOpenGLOptions.cmake:116 (message):
The VTK_OPENGL_HAS_OSMESA can’t be set to ON if any of the following is
true: the target platform is Windows, VTK_USE_COCOA is ON, or VTK_USE_X is ON or VTK_USE_SDL2 is ON. OSMesa does not support
on-screen rendering and VTK’s OpenGL selection is at build time, so the
current build configuration is not satisfiable.
Are there cmake variables that would allow specifying the include and lib dirs of the osmesa build ?
How do I