Added an option to enable or disable the auto start feature

[demonixis]

The auto server start is a nice feature. However if a user doesn't want to use OSVR (he want to play in flat mode), he can't, he has to unplug its HMD from its computer.

If you use Unity 5.4 with the OpenVR API enabled AND you have the OSVR-SteamVR driver, then this feature will start OSVR then start SteamVR and the final API used will be SteamVR. So please, let us choose when enable the server. It's usefull for many cases, but not all.

[DuFF14]

thanks!

[JeroMiya]

@DuFF14 @rpavlik @demonixis I'm late to the discussion. Should this be a global setting? That way developers don't have to disable it on a per-application basis (and we don't have to implement this same change in each engine). I mean, currently they can disable it by just deleting the environment variable, but maybe a more elegant way to do the same thing (maybe an OSVR-Config setting they can just toggle without resetting everything).

[demonixis]

I think it's a good idea to have a per application settings. As a game developer, I would like to create a full OSVR experience without Vive or Oculus support, in this case, the autostart feature is welcome. But, I can work on a cross HMD game and in this case, the autostart feature is not required (and can cause issue).

SteamVR has this option, the server starts automatically when you start a SteamVR apps. It's a bad choice from Valve because I have to create a second executable for OSVR with a CLI parameter to disable native VR support.

So please, don't do same error as Valve, the obligation to use the clientKit prefab must be useful (it's not currently but it's another subject)

[JeroMiya]

This is good feedback. My worry with allowing developers to disable auto-start on an application basis is that on some platforms (Android currently; iOS, GearVR, and PSVR when they are supported), the auto-start functionality is required for OSVR to function at all. There's never going to be an already running server on these platforms (except maybe sometimes on android, but in limited circumstances - e.g. a custom OS build). And, from a user experience perspective, it's somewhat inconsistent when game A auto-starts OSVR and game B does not. That's why I think it would be better to have a user setting outside of applications to let users control from their side whether the server auto-starts on platforms where it is optional (desktop).

A couple of your points are interesting though: non-vr mode and the situation where both SteamVR and OSVR auto-start.

It might be a good thing to auto-start both Vive and OSVR in some cases even if OSVR isn't doing the final stereo and distortion correction rendering. For example: if you're using OSVR for input, you might have your game use the native Vive plugin for the HMD tracking and rendering, and then use OSVR for other interfaces, like eye tracking or locomotion, which SteamVR doesn't support. That's what we do in Unreal - we have an HMD plugin and an Input plugin, so we auto-start OSVR even if we aren't selected as the "HMD" plugin.

Maybe we could make auto-start more lazy in Unity? For example, we would only attempt an auto-start if either you're using OSVR as the HMD rendering plugin, OR if you attach any interface behaviors to your scene, etc... That way, your Vive+OSVR scenario wouldn't cause OSVR to auto-start unless you were still using OSVR interfaces for other things besides stereo/distortion rendering and head tracking (e.g. eye tracking, locomotion, skeletal, gesture, and so on).

I think your comment on letting the user play a game outside of VR per their preference is also compelling. However if the user wants to start a game in non-vr mode, we shouldn't be trying to connect to an already running server either. I've seen some games use a command line argument to control this - for example subnautica can be made to start in non-vr mode by passing -vrmode none to the application arguments (in steam or in a shortcut), and the developer can create their own launcher (or just two shortcuts even) to control this in a user-friendly way.

[demonixis]

Well I understand your point, it's true that on non standalone platform, it makes sense to have this feature enabled. We can show this option only on a standalone build (#UNITY_STANDALONE).

SteamVR has its own drivers which, well, works well. I perfectly understand that the goal of OSVR is to manage all aspects of the VR, from HMD, to controllers. But as a game developer, I don't want to mix all SDKs, it's hard and dangerous.

When a user starts one of my games, he has the experience he want. If he want to use SteamVR, he'll have a SteamVR experience, with controllers, roomscale (or not), etc. Using all features of a SDK is an hard thing, mixing many SDKs is not a good idea.

IMHO, the OSVR SDK is here for users who want an OSVR experience, as the Oculus SDK.

[JeroMiya]

Mixing OSVR with other SDKs (SteamVR and Oculus, for example) is a supported and important use case for OSVR. Unlike other SDKs, we fully separate our tracking/interface APIs (OSVR-Core) from the rendering API (OSVR-RenderManager) and that's by design. Certainly you shouldn't be required to mix OSVR with other SDKs, but it's not exactly onerous if you want to opt-in to these additional interface types.

So, in summary, my recommendations would be:

• Prioritize VR plugins and conditionally auto-start OSVR when/if-and-only-if OSVR is actually being used, instead of enabling/disabling auto-start on a per-app basis. We should look into ways to make prioritization and lazy initialization easier for Unity developers.
• Users should have control over toggling auto-start on/off, across all apps. This makes application behavior more consistent for the user.

[demonixis]

I'm agree

[DuFF14]

@demonixis @JeroMiya good points about non-VR mode and mixing SDKs. So are we looking at a new entry in the config file and clientkit API call? Shall we open an issue in Core?

[JeroMiya]

Yes, it would probably be an issue in core. We could do it a couple of ways:

• A server config option. Plus add an -autostart argument to the server to let it know that it's being launched with the auto-start API, and should make note of the setting. This is my preference.
• A second environment variable to toggle auto-start. Kind of kludgy but gets the job done.

[DuFF14]

Opened an issue here for continuing discussion: https://github.com/OSVR/OSVR-Core/issues/446