It’s quite a mystery how to build VTK python with OSPRay. I couldn’t find proper information for building it (in my case on Ubuntu LTS 20).
I first tried to clone VTK release branch and compile it with OSPRay. The compilation worked but it didn’t find/use ospray so I suppose that it’s only supported in later VTK versions (correct me if I’m wrong). I found that some work was done to support OSPRay 2 nine months ago and that was merged in master branch.
So I cloned a recent nightly-master (6000c2d7, because the latest one doesn’t compile) and I downloaded the latest compiled OSPRay 2.5 on Intel website. Then in vtk_build folder, I added with ccmake the options -DOSPRAY_INSTALL_DIR:PATH=/path_to_ospray -DVTK_ENABLE_OSPRAY:BOOL=ON
After the config was done, I ran make and it all compiled, I saw some info that OSPRay was found and used:
83% Generating Python wrapper sources for vtkOSPRayVolumeInterface
84% Building CXX object CMakeFiles/vtkRenderingVolumePython.dir/CmakeFiles/vtkRenderingVolumePython/vtkOSPRayVolumeInterfacePython.cxx.o
The rest of the compilation ended but no mention of vtkOSPRayPass.
So obviously, when I try:
I don’t think OSPRAY_INSTALL_DIR does anything. You probably want ospray_ROOT. The VTK_ENABLE_OSPRAY flag only does anything if the RenderingRayTracing module is built. It is controlled by the VTK_MODULE_ENABLE_VTK_RenderingRayTracing cache variable (set it to YES).
Thanks @ben.boeckel that helped. It’s not over but at least the module was built.
I thought it was a typo but it’s really ospray_ROOT. Then it automatically finds ospray_DIR (lib/cmake/ospray-2.5.0 inside the ospray root path).
Now when I run an example with volume rendering, I get this:
[openvkl] INITIALIZATION ERROR: could not open module lib openvkl_module_ispc_driver: libopenvkl_module_ispc_driver_4.so.0: cannot open shared object file: No such file or directory
[openvkl] WARNING: unrecognized driver type 'ispc_8'.
[openvkl] INITIALIZATION ERROR: Could not find driver of type: ispc_8. Make sure you have the correct VKL libraries linked.
[openvkl] INITIALIZATION ERROR: null handle provided to void vklDriverSetErrorCallback(VKLDriver, VKLErrorCallback, void*)
[openvkl] INITIALIZATION ERROR: null handle provided to void vklDriverSetLogCallback(VKLDriver, VKLLogCallback, void*)
[openvkl] INITIALIZATION ERROR: null handle provided to void vklDriverSetInt(VKLDriver, const char*, int)
[openvkl] INITIALIZATION ERROR: null handle provided to void vklDriverSetInt(VKLDriver, const char*, int)
[openvkl] INITIALIZATION ERROR: null handle provided to void vklCommitDriver(VKLDriver)
[openvkl] INITIALIZATION ERROR: null handle provided to void vklSetCurrentDriver(VKLDriver)
[openvkl] INITIALIZATION ERROR: Open VKL not yet initialized (most likely this means you tried to call an Open VKL API function before first setting a driver)(pid 225548)
OSPRay ERROR: unsupported volume type 'structuredRegular'
OSPRay ERROR: embree internal error 'invalid argument'
I do have the file libopenvkl_module_ispc_driver_4.so.0 in ospray/lib though…
Thanks for trying it out Nick! Two things come to mind off the top of my head.
Compile OSPRay from source. OSPRay’s binary packages are not configured as SDK’s, so the transient path and such to OSPRay’s dependencies like Embree, VKL and the rest are not always reliable on all platforms and on all releases. Advice 1: the easiest way to build OSPRay from source is to use OSPRay’s superbuild. Ie, get a hold of OSPRay source, then point cmake at ospray/scripts/superbuild/CMakeLists.txt instead of ospray/CMakeLists.txt. The build products will be in the build/install directory. Advice 2: I recommend changing the superbuild’s default setting of INSTALL_IN_SEPERATE_DIRECTORIES from ON to OFF to put all of the dependencies in one easy to find directory.
Would you mind trying OSPRay version 2.4 instead of 2.5? There are almost always things that need changing in VTK’s interface to OSPRay to make it compatible with even minor OSPRay release updates, and the last time we did that was for OSPRay 2.4.
OK, I used superbuild scripts with INSTALL_IN_SEPARATE_DIRECTORIES:BOOL=OFF (note separate, not “seperate”). OSPRay compiled without any issue.
Then I pointed VTK to the “non-separated” build lib folder and compiled VTK again. The compilation worked. But the issue appeared again but I realized that OSPRay was built as 2.5 and I have no idea how to choose 2.4. What I naively did was to git reset --soft until the merge commit of 2.4 but it seems that the superduperinstallscript didn’t care and went along with 2.5. In ccmake there’s no VERSION option for OSPRay (for OpenVKL yes, for OIDN yes, for Embree yes, …).
I guess it’s just a simple thing to choose 2.4. Do you know how to do that?
If you cloned ospray from git “git checkout v2.4.0” should work. If downloading the source tarball from the webpage look for the “old OSPRay releases” link. In either case do a clean build and the defaults should be for the appropriate dependency versions.
So, I’ve got two strikes. Hmm, let’s try a third pitch.
library path issues still seem to be a problem. Find the file “libopenvkl_module_ispc_driver_4.so”. It should be in something like /build/install/lib. Add that directory to your LD_LIBRARY_PATH. It wouldn’t hurt to also put it in your PATH and PYTHONPATH too but try LD_LIBRARY_PATH first.
That was as simple as setting the LD_LIBRARY_PATH. Thanks @Dave_DeMarle
Now I’ve got one other issue. It seems that X11 XCB was not found on my Ubuntu, despite installing libx11-xcb-dev.
So VTK segfaults as soon as the window opens (but I saw the volume! And no import complaints from OSPRay side). The error is “X connection to NAME broken (explicit kill or server shutdown).” where NAME is a weird set of special chars.
I’ll open a new issue about it. I assume that OSPRay works but I’ll come back here once I’ve got a proper VTK build.