We use vtk’s OpenVR integration, and recently I noticed that when using VTK 9.1.0, the vr::VRInput() call in vtkOpenVRRenderWindowInteractor::Initialize() in line 784 returns a nullptr leading to a crash.
This does not occur with VTK 9.0.1.
Does anybody have a quick idea what the problem could be here?
I am using an Oculus Quest with Oculus Link for testing this. Did anything change in how VTK sets up the VR input between 9.0.1 and 9.1? Do I need to do something special/additional in VTK 9.1?
I see now that the release notes state that “VTK’s OpenVR’s input model has been updated to be action-based and supports binding customization within the OpenVR user interface.” - which sounds like its related to my problem. Not sure what I need to do about this, though…
I think I have seen this in the past where the steamvr/openvr libraries are old. Normally steam vr updates itself but some folks have that turned off. So I would try making sure steamvr is up to date and then also check that the openvr_api.dll is up to date. Specifically the one probably sitting next to your application. Let me know if that is it. Thanks!
@ken-martin thanks for the input.
I’m already using the latest versions I could find (SteamVR 1.20.4 , latest OpenVR SDK 1.16.8 from GitHub - ValveSoftware/openvr: OpenVR SDK).
Also, I’m using both VTK versions on the same PC with exactly the same OpenVR/SteamVR versions.
To me this would suggest that I need to do something differently in my application in setting up VR in VTK between the versions, but I have no clue yet what…
The Frustum OpenVR example also fails with exactly the same problem with 9.1.0; to me this seems to suggest rather something wrong on the system or with the combination of VTK/OpenVR and my hardware in general (AMD card / Oculus Quest).
However I think I also tried the same on a system with a NVIDIA Quadro and a HTC Vive - which would suggest that either my code as well as the the example are broken on VTK 9.1.0 and require some extra work to get going in comparison to VTK 9.0.1 - considering the line before where it crashes - it has to do with finding the manifest.json file , will check that next
Don’t think it’s the manifest file itself (though I guess the *.json files are now required?).
The crash happens despite the .json file being where it is passed into the SetActionManifestPath - but of course the vr::VRInput() call already returns the nullptr, so it doesn’t even reach that function. As far as I can tell, the vr::VRInput() errors out in the call to VR_GetGenericInterface with error VRInitError_Init_NotInitialized. That’s as far as I got with debugging so far…
Hmm, feels like something is off on the setup. I’m not 100% sure about 9.1 as I am typically on master but the example has been working generally from what I recall. I know it has been working recentl but we changed a ton recently to add OpenXR support.
This may be overkill but if you want you can try out ParaView, specifically https://data.kitware.com/#item/611001c62fa25629b9132ea7is a zip that contains the PV executable along with a VR demo PV state file you can load (.pvsm) that works well in VR and is based on a VTK that uses the new input models etc. I have run that with Oculus Quest 2 + controllers so it should be fine. Just possibly another quick datapoint to check. My memory keeps thinking that VRInit issue is related to an old openvr_api Maybe that dll is somewhere else in your path or your VTK is being built against an older openVR somewhere.
Thanks for the suggestions, will try that tomorrow - ProcessMonitor to see which actual openvr_api.dll gets pulled in for my program.
Thanks for the effort regarding the specific Paraview version! Trying to download that zip you linked to at the moment, however, gives me a kind of popup warning “An error occurred while communicating with the server. Details have been logged in the console”.
The developer console shows
Loading failed for <script> with source "https://data.kitware.com/static/built/plugins/google_analytics/plugin.min.js"
and
"400 Bad Request"
Tried it with Vivaldi, Firefox and Edge (the last one without any extensions), and they all show the same behavior, so I don’t think it’s a browser issue on my side.
Currently using OpenVR in VTK 9.1 as we speak in iMSTK (on a quest 2). The exposing of the action system json is very nice for control customization. Though I put up recent fixes for it in iMSTK (only quest 2 bindings right now) (https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/751).
Can you check the call vr::VR_Init (ln457) is hit in vtkOpenVRRenderWindow::Initialize before vr::VRInput is called? It should. vtkOpenVRRenderWindow & the interactor both have an initialization. I have hit this issue when I accidently called Render on the renderwindow before it was initialized.
Additionally if vr::VR_Init were to fail in vtkOpenVRRenderWindow::Initialize it would have thrown an issue saying it couldn’t start the VR runtime.
Ahh the TestDragon example Initializes first so it works. Can you create an issue at https://gitlab.kitware.com/vtk/vtk/-/issues so we try to get this fixed at some point? Thanks!
