Is it possible to use Openve Direct mode with SteamVR ATW?

[vicdxxx]

I know SteamVR has two options to set ATW that is "asynchronous reprojection" and "interleaved repropjection". Are these features still do work in OpenVR direct mode? I have finished a openvr direct mode driver, follow the comments of api_driver.h. I think these comments are insufficient. For example, I met a stutter steamvr home scene using my driver, while I have accuratly implememted all functions in DirectModeComponent.(I think) Where could I find more introductions about these stuffs? Any suggestion is high appreciated!

[LoSealL]

Actually, the official guide don't recommend to use IVRDriverDirectModeComponent, but it has more functions than IVRVirtualDisplay does, so I also implements IVRDriverDirectModeComponent rather than the latter. I'm not sure what instructions you exactly need, if you want to figure out how ATW enabled in SteamVR, I will tell you that if you only implement IVRDisplayComponent, it's implemented in vrcompositor (If you turn on the options of course), and you don't need to call any API to deal with the details in ATW. If you really want to handle everything by yourself, and you want SteamVR to call your IVRDriverDirectModeComponent implementation, you should return both IsDisplayOnDesktop() and IsDisplayRealDisplay() false. The Submit() call in IVRDriverDirectModeComponent will pass in a vr::HmdMatrix34_t *pPose argument, it's meant to be the position used to render these submitted frames, do remember that there may be more than one submit per frame, and you should blend them together in your implementation . When you ready to present frames to your Display (or virtual display), you should get a new pose and calculate the rotation to do the reprojection.

[Balderick]

Actually, the official guide don't recommend to use IVRDriverDirectModeComponent,

What official guide? SteamVR itself tells users that extended mode is not recommended when ever it detects a dislpay not properly configured for direct mode. "Please use direct mode. Extended mode is not recommended." says steamvr.

I think third party driver providers are hugely underestimating the need for this and not using direct mode actually heightens jittering, bad tracking and even possibly things like black images being rendered. I appreciate not all displays support direct mode so sometimes there is no choice but too use extended. What the problem is third party drivers and trackers using a differeing methodology to create a pose from the structure and methodolgy steamvr tracked devices use. THere is no way currently built in to openvr api to bridge the differing structs.

We need provision for better third party driver support built into openvr api so that openvr is not so optimised just for steamvr tracked devices. Currently, any driver that is not a steamvr tracked device driver is a second class citizen. Steamvr even without any steamvr tracked devices connected is still wanting to use the ccoord and position methodology that steamvr tracked devices use in things like room setup and room layout but most steamvr apps provide to a means too recenter and so most folks probably do not even notice how bad steamvr room layout is tellling them how out of place their devices and room layout are.

Using the null driver, sample driver and not properly naming and registreing there own drivers is something else i have seen third party devs use just to get things appearing to be working.

Valve documentation for openvr api will hopefully start growing as they provide better suppport for third party non steamvr tracked devices.

Using direct mode on pc vr is simply the recommended way to run vr apps. Even my shield tablet can run steamvr in direct mode nowadays.

[Balderick]

@vicdxxx Try subscribing to Revive issue tracker. https://github.com/LibreVR/Revive The issues there tell you the ideal settings for ATW, ASW related settings per app. It will show you the need to change settings according the needs and wants of each steamvr app or at least describes which settings are needed for different apps.

I define all atw related settings as well as advanced supersampling to be off by default in my steamvr.vrsettings

Valve have the mindset that we should not be needing to apply any time warp at all if apps are running at 90 fps. Time warp is a workaround for games not hitting the 90 fps needed. Which makes sense to me why steamvr apps run fine without any of those settings applied, at least on the most part.. Valve have put a lot of time and effort into making game engines, vr platform apis, vr runtimes, operating systems and proprietary drivers better in order for apps to run at 90 fps instead of working on workarounds.

The display that i use is actually a 60 hz display so steamvr apps probably run better without all the time warp stuff because of that.