NA-MIC Project Weeks
Back to Projects List
Lighting problems with latest SlicerVR
Key Investigators
- Csaba Pinter (EBATINCA, Spain)
- Andras Lasso (PerkLab, Queen's University, Canada)
- Matt Jolley (CHOP, USA)
- Jean-Christophe Fillion-Robin (Kitware)
Project Description
There is a regression with how latest SlicerVR lights the scene, both with the old VR and the new XR backend.
- OpenVR: Default lighting looks as expected, but now SSAO and Lights module options are not applied on the VR view (even if the view node IDs are explicitly selected)
- OpenXR: Default lighting looks washed out
Objective
- Make both backends of SlicerVR work like before the regression
- “Normal” lighting by default
- Lights module changes have effect on VR view as well
Approach and Plan
- Investigate the problem with the help of people directly involved in the OpenXR integration
- If we find the root cause of either issues, try to address them
Progress and Next Steps
- The Kitware team looked into the issue with OpenXR
- The issue seems to be the SRGB conversion. There is already a workaround possible, with a proper solution suggested (see comment)
- OpenVR support is being removed from Windows, so probably not worth trying to address the issue
Illustrations
The following screenshots demonstrate shadows vs no shadows in OpenVR:
Left: Slicer view using OpenVR without shadows
Right: VR view (with back lights / without two sided lighting)
Left: Slicer view using OpenVR with shadows
Right: VR view (with back lights / without two sided lighting)
The following screenshots demonstrate different lighting options in OpenXR:
Left: Slicer view using OpenXR without shadows
Right: VR view (with back lights / without two sided lighting)
Left: Slicer view using OpenXR without shadows
Right: VR view (without back lights / without two sided lighting)
Background and References
For those who have access to SlicerHeart internals, this is the link to the issue: https://github.com/JolleyLab/Internal/issues/205#event-14879920416