I have now had my Rift+Touch for about a month or so. Here's a list of gripes i have or have had so far:
- Sound is often not on in the Rift HMD, regardless of which HMD device setting i have on (mirror vr audio, hear non-vr apps in vr). Sometimes it magically works, but most of the time either sound is in my pc speakers only or in my HMD only. In short the above settings appear to be near useless to me. I have resort to activating/deactivating audio devices in windows almost all the time for audio to channel where i want it.
- The "oculus home works best with windows 10" message. Yes, i got the message the first couple of times i saw it and clicked it away. Why do i have to keep seeing it every time Oculus starts?
- 9 of 10 times i start Oculus for the first time of the day, it will tell me my touch controllers are off. No amount of clicking/pressing/rotating on the controllers will wake them up. What i have found though, is restarting Oculus by settings -> Beta -> Restart Oculus will fix it every time. However (see next point)
- Settings -> Beta -> Restart Oculus _NEVER_ actually restarts it. It closes down Oculus, sure. But it never restarts regardless of amount of time waiting, and it cannot be started again.... That is, unless i go to services, stop the OVRService which is still running (i suppose this service ought to stop and start again), start it manually and then everything works again. Easy, sure. Tedious - VERY.
Being an old ex-dev (mostly frontend though, ex Interface Developer) i dabble a bit with Unity. But rarely have i seen such a mess of assets/utilities/SDK as the Oculus ones. Sure, there is a lot in there. However, it just pretty much never works "out-of-the-box". That goes for both the OVRPlayerController, The OVR Local/Remote Avatar, the CameraRig etc. And the documentation is spread to several places rather than in the source itself. On top of that more often than not the documentation that does exist is outdated either for the current version of the unity or the version of the <x> packages used.
Some of the sample scenes does work as expected (or at least i think they do, in several there is no documentation on how they ARE supposed to work). Others, well. Not so much.
Some of the prefabs (with all dependencies present) work wonderfully. And some don't. As a simple example, a very common scenario for a developer would be to want to have a player controller with hands enabled, and using the oculus home selected avatar skin. But no such prefab exists. Instead we have an OVRPlayerController that does indeed allows movement as expected, but no avatar and hands. Puting up a localAvatar in there, and you will instantly have displacement issues if you don't know that this asset should be a child of the tracking space in the OVRPlayerController. And even if you do, sometimes it works, sometimes it doesn't. Just this morning i made a clean project and import where i couldn't get it to work for the life of me, whereas i have other projects where it does work, but i have other major quirks like grab snap points adding weird transforms that seem to come from who knows where.
Don't get me wrong though. There is a lot of good stuff in the utilities/avatar/sdk/sample/whatnot packages. It is just very very very far from readily accessible. The amount of hours i have spent trawling the net for information that somewhat resembled the setup needed for the most current packages is immense.
Then theres the OVRProfiler. "Please keep drawcalls below 100" for Oculus Rift. That is a pretty tall order. Especially considering that the OVR prefabs (avatar) use 21 drawcalls (if i remember correctly) alone.
Lastly, there is the errors that you will be getting using these standard packages. Sometimes loads of them. Some will be because you are missing an assembly or similar. Fair enough, that is fast to resolve. Often times though there will be heaps of warnings about deferred <insert cause> being used in these packages, you should use <insert new stuff> instead. That's all fine and dandy if user in question had made his own playercontroller, avatar handling etc himself. But that isn't really the case using these packages which ought to be the latest in general best practice. In other words it quickly becomes a bit of a mess.
In short, it would be really (REALLY) nice with some updated packages where the documentation was included _directly_ into the packages, and this documentation being specific for that actual version of the package. It would also be nice to have the common use scenario in there so potential new content providers could actually focus on making content, rather than trying to set up and fix errors with the OVR standard packages.
Whew. There. I said it and got it off my chest. I do love my Rift, and i would love to make some - for starters - small games for it. But with the obstacles above i think i am far from alone in being close to giving up before properly starting. And that is a darn shame as i see it.