The need for VR related libraries and uniform driver APIs

[cadcoke5]

Another related item would be standardization of terminology. Though, the existence of a commonly used API will dictate its terminology.

One example, earlier in this thread, used the phrase "Body Feedback". At first glance, I immediately assumed he meant tracking the location of the user's limbs in relation to his body. But, when I read it, I see that he meant forces that the game would apply to the users body. Perhaps "Feedback to Body" would be a better phrase to use.

Another example relates to the intended application. The phrase, "Head Tracking" is clear from the sensor perspective. But, might be used by one game's list of features to indicate it will pan the view on one monitor, to show the environment around the user. Another game might use it for "fish tank VR".

Just adding a bit to the list of things to include in the discussion.

Joe Dunfee

[Direlight]

PC Motion Games



http://www.aiwi-game.com/enu/main/index.php

[nateight]

I can't comment on what is legally or programmatically possible with unified drivers, and sharper minds than my own already have a good grasp on what the ideal solution to this might include, but I want to state one opinion strongly: Time is running out, and further hesitation on this issue invites disaster. If this community or some other interested entity can't point to a large, complimentary range of input devices and demonstrate how supporting all of them will be both dead simple and free, game developers will largely treat Rift support as a fashionable way to garner press attention for their unremarkable console ports, and the new gameplay paradigm the Rift can and should represent may struggle to realize itself. AAA developers are too bloated to anticipate any given zeitgeist in advance, and indie devs are too underfunded to experiment with anything that isn't already in demand. Those of us who can see this landscape clearly need to push for adoption of innovative devices by devs before they begin developing; if we wait until the Rift launches to see what input schemes "catch on", the only ones that will even be available to evaluate will be gamepads absent any other controllers and head tracking used only to turn avatars and their beltbuckle-based guns. I want to believe the VR revolution is inevitable this time, but it will live or die by popular opinion, and if the only control schemes devs have been able to utilize are clunky ones, "The Rift is too hard to control" and "I use my mouse and keyboard to prey on wall-humping VRtards" will be the only memes anyone remembers. Whether someone presents a perfected driver blob ready to be injected into any and all new games or merely convinces a consortium of large and small developers to support a spate of first-party APIs, every day spent attempting to predict the future is a day spent not enacting it. Standardization will come eventually - what we need now (and preferably in advance of the first round of dev Rifts shipping) is pressure on all levels of the industry and a compelling set of standards for them to embrace, however imperfect they may currently be.

[MSat]

I don't think a unified driver is what's needed (or even possible), but rather that the drivers companies release with their hardware all utilize the appropriate standardized APIs for their class of device. USB HID devices allow for a surprisingly amount of flexibility and could work for a lot of hardware that doesn't require much PC-side processing. But for devices like the Kinect and Leap Motion where most (or all) of the processing magic is done on the computer by proprietary algorithms, USB HID no longer becomes a possibility, so a standardized API is likely the only option.

StreamInput has a good chance of making this a reality, and appears to have a lot of the most relevant companies on board. I guess we'll know when they make their first draft public. The only thing remaining to be accomplished after that may be a device configuration utility and database, as well as a set of VR-related libraries to make implementation easier on developers and users.

[nateight]

Uh, guys?

EDIT: Okay, I should have searched for this first, but VRPN hasn't even come up in this discussion about exactly what VRPN is; I doubt I'm the only one here unaware of it. Please note this highly relevant pre-Kickstarter post from Palmer. I'd bet he stands by every word, the only question now being whether the Oculus skunkworks can dramatically improve upon the design of the Hydra before peacefully coexisting alongside it.

[MSat]

Yeah, there's VRPN, and there's also MiddleV.R. (http://www.imin-vr.com/) middleware. While it could certainly work, it requires that the middleware utility developers specifically add support for each device (which has its own API). What happens if either of those utilities stop being supported? That's partially why I think it's better to have a standardized API from the hardware manufacturers themselves.

[CyberVillain]

But freePIE cant really interact directly to a game right? As an example if i make a VR game in Unity with support for bone movement by tracking and some cool stuff like turning on a fan or something similar, correct me if im wrong here. I think what the OP is after is more of a unified set of APIs for direct integration into game engines?

Offcourse FreePIE can support software, look at Vireio, they got their own FreePIE plugin. Also in next release of FreePIE there will be a Generic plugin that any software can use to read/write values to/from FreePIE

https://github.com/AndersMalmgren/FreeP ... cPlugin.cs

[virror]

Would still love to hear from Oculus what their thought is to matter of VR standards, they probably have something up their sleeve.