New Oculus SDK Adds Experimental Linux Support and Unity Free For Rift Headset

An anonymous reader writes: Oculus, creator of the Rift VR headset, has released a new version of their SDK which brings with it long sought-after support for Linux, which the company says is "experimental." Linux support was previously unavailable since the launch of the company's second development kit, the DK2. The latest SDK update also adds support for Unity Free, the non-commercial version of the popular game authoring engine. Previously, Unity developers needed the Pro version—costing $1,500 or $75/month—to create experiences for the Oculus Rift.

Re:

[davydagger]

It really takes a special person to understand the diffrence between proof of concept of tommorow's technological workhorses and a technological gimmick.

To the average person, they are both the same. A device with new, intresting technology that uses technology based on recently discovered science, a big refinement of current science, or technology which was otherwise previously unavailable because of a certain limit. Despite this, at current, the available device still does not perform better than what it

Re:

[fuzzyfuzzyfungus]

Depending on the technology in question, it may not even be apparent to the special person(without domain specific knowledge that they may lack, or which may not even exist yet).

With something like an Oculus-style VR headset, the "Well, if we can put a screen in front of each eye and track acceleration and orientation, ideally with a fallback for recalibration when the drift from dead-reckoning with inertial sensors starts to creep in" concept is not particularly new. Relatively lousy versions even becam

Re:

[davydagger]

>With something like an Oculus-style VR headset, the "Well, if we can put a screen in front of each eye and track acceleration and orientation, ideally with a fallback for recalibration when the drift from dead-reckoning with inertial sensors starts to creep in" concept is not particularly new.

Again, it begs the question. There is still a big gap between "proof of concept", and "killer application". A product that proves the technology works, and a product that proves the technology is actually useful ar

Re:

[mindwhip]

I have to agree... one example that springs to mind is the PS2 EyeToy. It proved that motion tracking used as a controller could be done but it was basic, lacked refinement, reliability, and wasn't easily reused as most of the work was being done in (closed source) software.

It wasn't until the Kinect came out with the extra sensors and the ability to easily re-purpose the technology when windows drivers were released that more serious uses were found and still those applications are still mainly at the "pr

Re:

[dmbasso]

It's amazing how the joke got old so quick. I guess you should have stopped around the third iteration.

And before you come criticize this comment, wait for Bennett's.

Re:

[tepples]

Yes. In fact I'm such a frequent contributor to Slashdot's comment section that I occasionally hit the daily comment cap while trying to narrow down a point.

about time

[Nyder]

this is the year of the linux VR.

Apple already won that war ...

[Anonymous Coward]

The Unix on the Desktop War is over, Apple won with Mac OS X.

confirmed

[Anonymous Coward]

This is slightly old news. I spent a chunk of yesterday setting up Unity free, and creating some test environments with the Oculus camera rig and player controls in them. I can confirm that so far it works great, and is extremely easy to do, even for a complete Unity noob like me.

What is the interaction with the OS?

[fuzzyfuzzyfungus]

As I understand it, the DK2 hardware interacts with the host computer at three points: there's an HDMI video in, which feeds the two screens(presented as a 1920x1080 monitor; but physically split into two 960x1080 panels), a USB interface for the in-device sensors and housekeeping purposes(accelerrometer, magnetometer, gyroscope, firmware updates, latency testing device), and a USB connected IR camera for head-tracking based on the IR LEDs on the head-mounted portion of the device).

How much OS-specific work needs to happen, and how is it distributed?

I'm assuming that the HDMI-in is fairly normal, unless they really broke the EDID/DDC or something(but obviously not going to be very pleasant unless the application drawing to the '1920x1080 monitor' knows that each of my eyes is only getting half of it).

Barring very good reasons(probably involving latency), I'd assume that the camera is just a UVC device; but that actually using it as anything but an expensive webcam requires the OR-specific head-tracking software to have access to it (the meat of which is presumably cross-platform; but DirectShow vs. V4L2 and other interacting-with-the-system stuff won't be).

The headset's USB interface presumably needs a specific driver, since 'read the outputs of a bunch of sensors and also firmware update' isn't exactly a USB Device Class; but would presumably be a comparatively lightweight 'wrap the sensor outputs and get them to the host as quickly as possible' thing, with the bulk of the motion and position tracking logic being mostly OS independent except for the layers it has to interact with to get headset and camera data.

Is this largely the extent of it (2 mostly standard interface, one device specific driver, plus having the motion and position tracking software running on Linux and interacting with the OS-specific interfaces to the drivers)? Do I fundamentally misunderstand how work is broken up within the Oculus system? Do I basically understand it; but it turns out that latency demands are so stringent that a variety of brutal modifications to the typical OS graphics system and GPU drivers are also required?

Re:

[tlhIngan]

How much OS-specific work needs to happen, and how is it distributed?

I'm assuming that the HDMI-in is fairly normal, unless they really broke the EDID/DDC or something(but obviously not going to be very pleasant unless the application drawing to the '1920x1080 monitor' knows that each of my eyes is only getting half of it).

Barring very good reasons(probably involving latency), I'd assume that the camera is just a UVC device; but that actually using it as anything but an expensive webcam requires the OR-spec

Re:

[ultranova]

The headset's USB interface presumably needs a specific driver, since 'read the outputs of a bunch of sensors and also firmware update' isn't exactly a USB Device Class;

03h [wikipedia.org] and FEh [usb.org]?

An accelemeter is really just a joystick with six axes, as is a 3D locator.