Lazy init of OSVREntryPoint to avoid startup delays in non-VR mode, and configurable timeout #102
Conversation
…ds, made nohmd option skip init, and delayed init to avoid startup delays when UE4 run with nohmd non-VR mode
…ds, made nohmd option skip init, and delayed init to avoid startup delays when UE4 run with nohmd non-VR mode
| } | ||
|
|
||
| // hack: to avoid delay on OSVR server connection attempt when not using OSVR, don't initialize if nohmd command line param specified | ||
| if (FParse::Param(FCommandLine::Get(), TEXT("nohmd"))) |
There was a problem hiding this comment.
OSVRInput may need the entry point even if nohmd is set. Can this skipping behavior be parameterized?
There was a problem hiding this comment.
I've been meaning to move OSVREntryPoint to OSVRClientKit for this reason, but I don't know how many people out in the wild would be affected by that breaking change.
There was a problem hiding this comment.
"Can this skipping behavior be parameterized?"
In what way were you thinking? I think it best to make it skip by default with nohmd option to avoid the excessive startup pause for non-VR users, so perhaps add a parameter check that overrides the nohmd skip like "-forceosvr", so "-nohmd -forceosvr" on command line would still initialize OSVREntryPoint?
There was a problem hiding this comment.
I just meant something like an argument to Initialize indicating whether it should attempt to connect if nohmd is set. In this case, OSVRInput would pass true, because it wants OSVR to connect even if the game is not running in VR mode. OSVR (hmd) would pass false.
There was a problem hiding this comment.
One problem: if OSVR plugin is enabled but running on a non-VR machine, then when OSVRInput initializes (which happens even if nohmd passed) the 3-10 second pause would occur due to not being able to connect to OSVR server. We shouldn't make all non-OSVR users wait 3-10 seconds.
There was a problem hiding this comment.
If the developer is running OSVRInput, they are still an OSVR user even if the game is running in non-vr mode. OSVRInput implements the controller and motion controller interfaces in unreal, which are orthogonal to "vr mode". If the developer doesn't want either OSVRHMD or OSVRInput, the current workaround is to just disable the OSVR plugin, although in the future we may split OSVRInput into its own plugin, with a common OSVRClientKit module between them (i.e. move OSVREntryPoint to OSVRClientKit).
There was a problem hiding this comment.
This is more about end-users who can not enable or disable UE4 plugins. The end-user is using a full game build (in which plugins can't be enabled or disabled - the plugins enabled by developer are enabled and can't change) and not UE4Editor (where a developer can enable or disable plugins).
We have to target end-users with game builds and make the experience for them good - we (and all developers of products for non-developer end-users) can't force our non-OSVR users (the majority of our users) to wait for 3-10 seconds on a black screen while the UE4 OSVR-plugin fails to connect to a non-existent OSVR server.
P.S. Sorry for long response delay - was out of office for a week.
|
I understand it's not the best situation without an async or deferred HMD and Controller/MotionController plugin workflow built-in to Unreal (the only real solution to this issue), but we have to work with what we have. OSVRInput should continue to work in non-VR mode, and that can't happen without waiting for the server startup. Your timeout setting, is it end-user editable in the user settings? Can we add a console command to change it in a persistent way (though I realize the console is disabled in most production builds)? If so, that can be the end-user workaround for now. |
|
This change already has InitTimeoutSeconds as a config file value, but we don't want to force non-OSVR users to go configure it lower than the default value needed for OSVR users to have it work (I had failures at 3 seconds but none at 10 seconds). What if we make the "when -nohmd passed,, OSVRInput skips OSVREntryPoint init and this OSVR server connection to avoid 10 second delay for non-OSVR users" be controlled by a config file value? It can default to false but products/developers who can't force their non-VR users to wait for 10 seconds at a black screen could set it to true. |
|
OK, this thread is good feedback. I think you're on the right track with the -nohmd server check setting, but as an alternative to defaulting it to off for OSVRInput, I've been thinking of an alternative that may involve new API in the OSVR ClientKit. It looks like we could use it for the Unity plugin as well. Basically, the idea is that we could add an API to QUICKLY query whether the client should even attempt to connect to the OSVR server. So basically, we would check if the server is running - i.e. the server port is open (or if the user registered an auto-start server, which we can check quickly). A quick port check and not a full connection attempt with a path tree request. Our plugin would then check this before running server auto-start and before initializing the client context and waiting for status check. Theoretically, this would eliminate the timeout delay for users with no OSVR server running or registered for auto-start. |
|
See this issue: OSVR/OSVR-Core#464 |
|
Re: "we could add an API to QUICKLY query whether the client should even attempt to connect to the OSVR server" - If you want to avoid the hassle of looking for listen ports, etc for the check perhaps consider another IPC mechanism like named sockets (AF_UNIX under Unices) or a Windows IPC mechanism (see https://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx ) for the "is server running to tell if I should try to connect" check. |
|
Forwarding response from @rpavlik: "no, that's [open port check] pretty much the best way since that's the way the server gets contacted. Any other way introduces the possibility that bad shutdowns leaves inconsistent state. There could be something with a named object and a process handle for Windows, etc. But that's complex, slow, and fragile." |
…lse, but if set to true will skip OSVR init if -nohmd passed on commandline - to avoid 10 second pause when no VR is present
|
I added a SkipIfNoHMDCommandLine config option that defaults to false, but if set to true AND "-nohmd" command line arg passed it will skip OSVR init (and the 10 second delay if no OSVR server present, like when not in VR mode) including for OSVRInput 's OSVREntryPoint::Initialize(). This is a workaround until the OSVREntryPoint::Initialize() can quickly return failure if OSVR not present or OSVR server not running. |
Added OSVR.Settings InitTimeoutSeconds, increased default to 10 seconds, made nohmd option skip init, and delayed init to avoid startup delays when UE4 run with nohmd non-VR mode.
This is so apps that support non-VR and different VR APIs can avoid the delay caused by OSVR server connect/init when in non-VR mode.