Hi sboys3,
I came across CustomHeadsetOpenVR while working very deep in SteamVR’s presentation stack, and I think our projects overlap in a pretty unusual area.
I’m working on ReFrameVR. We’ve managed to make Valve’s own SteamVR Motion Smoothing work on an existing streaming HMD path that normally reports it as unsupported.
The current implementation intercepts the presentation contract, hides the original IVRDriverDirectModeComponent from SteamVR, lets SteamVR switch to a compositor-owned IVRVirtualDisplay path and run Valve Motion Smoothing, then privately relays the resulting frames back into the original vendor DirectMode backend.
This is now working end-to-end on Quest 3 + Virtual Desktop, including physical headset output, original HMD/controller tracking, and adaptive refresh rates tested at 72 Hz and 120 Hz.
What I’m really interested in now, though, is going beyond Quest/VD.
I think there may be a path to turn this into a general-purpose SteamVR presentation compatibility layer: keep the original tracking, devices and vendor backend, but provide a generic interposition layer that allows otherwise unsupported DirectMode headsets to use SteamVR compositor features such as Valve Motion Smoothing.
In other words, rather than writing a separate workaround for every headset, I’d like to find out how much of this can be made backend-agnostic.
Your work on native SteamVR headset presentation is one of the closest things I’ve found to what we’re doing, so I wanted to ask directly:
Would you be interested in exploring a truly generic solution together?
We’re preparing ReFrameVR for public release now, and I’d be very happy to share the current architecture, traces, DirectMode lifecycle findings, and implementation details.
Discord: thed0ublec
Mail:yiris.0421@gmail.com
Hi sboys3,
I came across CustomHeadsetOpenVR while working very deep in SteamVR’s presentation stack, and I think our projects overlap in a pretty unusual area.
I’m working on ReFrameVR. We’ve managed to make Valve’s own SteamVR Motion Smoothing work on an existing streaming HMD path that normally reports it as unsupported.
The current implementation intercepts the presentation contract, hides the original IVRDriverDirectModeComponent from SteamVR, lets SteamVR switch to a compositor-owned IVRVirtualDisplay path and run Valve Motion Smoothing, then privately relays the resulting frames back into the original vendor DirectMode backend.
This is now working end-to-end on Quest 3 + Virtual Desktop, including physical headset output, original HMD/controller tracking, and adaptive refresh rates tested at 72 Hz and 120 Hz.
What I’m really interested in now, though, is going beyond Quest/VD.
I think there may be a path to turn this into a general-purpose SteamVR presentation compatibility layer: keep the original tracking, devices and vendor backend, but provide a generic interposition layer that allows otherwise unsupported DirectMode headsets to use SteamVR compositor features such as Valve Motion Smoothing.
In other words, rather than writing a separate workaround for every headset, I’d like to find out how much of this can be made backend-agnostic.
Your work on native SteamVR headset presentation is one of the closest things I’ve found to what we’re doing, so I wanted to ask directly:
Would you be interested in exploring a truly generic solution together?
We’re preparing ReFrameVR for public release now, and I’d be very happy to share the current architecture, traces, DirectMode lifecycle findings, and implementation details.
Discord: thed0ublec
Mail:yiris.0421@gmail.com