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.

Comments

Bennett Haselton on reality

[Anonymous Coward]

For quite a long time now we've been promised affordable, realistic virtual reality devices. Sadly still, no ice and no dice. I at least won't be drawing any conclusions until we receive some insight from resident mathematician and algorithm extraordinaire Bennett Haselton. His insight over the years has proved invaluable over the years on Slashdot. Let's hear from Bennett, frequent contributor.

Re:Bennett Haselton on reality

[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 is intended to replace, or still does not fufill most of the promises the technology should offer.

Some of these devices are technological dead ends, which are not refinable into mass producable products, or simply not truely capable of being worthwhile. Others, however are.

It takes a person with some vision, in addition to technological smarts, and understanding of the human proccess to tell the diffrence. It is not immediately apparant to the public.

Re:Bennett Haselton on reality

[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 became just cheap enough to appear in modest quantities in video game arcades, and more expensive ones usually lurk around some academic and R&D operations.

However, unless they happened to have their finger on the pulse of the MEMs business, even an enthusiast of the technology would likely be inclined to dismiss it as a niche application at best(in largely the same way that, even among people who thought computers were pretty awesome and/or profited from selling them, it was hard to be too optimistic about their future ubiquity until transistorization and VLSI: even if the theoretical utility of building machines that do binary math was visible, there ain't no Moore's law for relays and vacuum tubes...)

Re:Bennett Haselton on reality

[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:Bennett Haselton on reality

[Anonymous Coward]

Are you a frequent contributor? No? Okay, well shut the fuck up and let Bennett contribute.

Re:Bennett Haselton on reality

[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 are two entirely diffrent things, and its something most people miss.

Re:Bennett Haselton on reality

[Anonymous Coward]

I actually stopped yesterday but someone had to use a lot of F bombs today so couple more. It's true tho there needs to be another contribution after so long eventually. Other reply is not me, I always try for civil exchange

Re:Bennett Haselton on reality

[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 "proof of concept" end of the scale and it still isn't clear if such technologies will have long term use.

There are however other related technologies that have benefited as a result.

Re:Bennett Haselton on reality

[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.

Re:Bennett Haselton on reality

[Anonymous Coward]

You're a frequent cocksucker. There's a subtle difference.

about time

[Nyder]

this is the year of the linux VR.

Tipping point for linux desktop

[Anonymous Coward]

Is this the tipping point we've been waiting for?

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:What is the interaction with the OS?

[Anonymous Coward]

You're basically correct. The HDMI for legacy (not direct-to-Oculus) at least is completely normal and viewable on a regular monitor, and vice versa. I have a windows desktop wallpaper with a pair of warped views on it, and when I extend the desktop to the Oculus, I see a static 3d picture. Having a DK2 installed, you end up with a pair of drivers for 2 USB devices, the camera and the headset, and a tray icon with a barebones application to change basic settings, etc. There's also some kind of direct link cable between the camera and the headset that looks an awful lot like a standard TRS mini-jack headphone plug. Not sure what that does, but I honestly haven't thought about it.

I don't think there's anything directly at the OS or GPU level required. It seems like the warpage and chromatic shift to compensate for the lenses is all done via API calls within the special "Oculus camera rig" that is provided for Unity, UE4, etc. This is incorporated into the "present" function in LibOVR, but apparently in earlier iterations (DK1?) it all needed to be done by the application. (SKD distortion rendering vs. Client distortion rendering)

Disclaimer: I only got my DK2 3 days ago, only started working with it in Unity Free yesterday, and have only quick-read the SDK documentation, so I might be wrong about things...

Re:What is the interaction with the OS?

[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-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?

The problem isn't the OS support - in fact, it's possible the OR uses standard USB interfaces.

E.g., you say the sensors and firmware update aren't standard - in fact, they are. The sensors are typically just USB HID devices (HID devices are more than just mice/keyboards/joysticks - they include UPSes, sensors and many other devices. Basically all the device needs to do is send a "report" on its conditions, something sensors can do easily).

Firmware update has the DFU mode - device firmware update. You may remember it from "DFU mode" on an Apple iDevice, which is exactly the same thing - it's a USB device class that's simple enough to be implemented in a boot ROM (so you can never really "brick" it).

The problem I think is Linux' media handling just hasn't be up there. Sure, you need to port your software to use V4L2 (which can be a challenge to begin with). But OR prices itself on low-latency handling and all that, so I think there was a lot of optimizations that had to be done specifically for Linux to get the low-latency they require. The OR software was highly optimized for Windows to get low-latency, so it has to be re-done on Linux. And quite possibly it bypasses some of the Linux stack just to avoid abstraction layers to get even lower latencies. Maybe even doing some of the work in kernel mode.

It's not easy at all - sure to get it working initially is easy, but then OR works because it has low latency between the sensors and the display updates, and that's the hard work. Getting it "to work" is trivially easy, but you want it to work well.

Re:What is the interaction with the OS?

[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 and FEh?

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

what about Google Cardboard?

[Anonymous Coward]

Will we start seeing more apps for it too? Its a bit more affordable for the 'common man' . you can get a plastic version for under 30 bucks, and everyone has a smartphone these days.. With built in sensors, etc..

Apple already won that war ...

[Anonymous Coward]

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

Motion sickness

[Anonymous Coward]

Motion sickness, now with linux support.

Frustrated DK1 and DK2 owner

[Anonymous Coward]

It would be nice if I could get the damn thing to work, with the DK1 at least it worked reliably. With all the new drivers (camera and oculus) and services on windows interacting with buggy video drivers and buggy rift drivers it's a mess and you really cannot use it the old way DK1 because the display orientation is different. I wish they would spend the next SDK release just getting the thing to run reliably on all machines not just the ones they have in the development lab at Oculus. There should not be a service to restart the service that is crashing or hanging. The direct to rift thing is a cool idea but the current video drivers are not ready for it. With the current release today I am getting a "Rift is using GPU:ffffffff and application is using GPU:0" error with the Tuscany demo at least that's better than not running at all and not giving any information as was the case prior. The only thing that seems work reliably on my setup is the demo desk simulator scene in the rift config tool and that only works once and then I need to kill all the tasks and restart them. Also with the latest SDK even desk simulator now has a movement jitter that was not present in previous releases. This thing has to be completely plug and play for the masses to adopt it. And don't tell me to remove everything and insert each device to find a combination that works or reboot, or reinstall the driver after removing. I've had this thing since July and there have been three releases since then to work out the kinks. I'm a frustrated DK1 and DK2 owner.

"No Linux support" not quite true

[Anonymous Coward]

From the summary,

Linux support was previously unavailable since the launch of the company's second development kit, the DK2

This isn't quite true: version 0.3 of the SDK was available, which supports the inertial tracker in the headset, but not the infrared camera that provides positional tracking. Version 0.4 added support for the positional tracker, but was only available for Windows and Mac through version 0.4.2. 0.4.3 adds "experimental" support for Linux. All of these versions are listed as "beta".

Oculus When?

[Anonymous Coward]

Will hell actually freeze over before Oculus (Facebook) ship a product?

The world is missing hardware that can invade your privacy directly from your face.

Hrga Mobil. Prperty paket Outbound bandung

[Anonymous Coward]

Bandung merupakan kota metropolitan di Jawa Barat, cukup banyak pembangunan perumahan baru di Bandung, Property Bandung salah satunya perumahan di daerah bandung utara yang dapat dijadikan referensi bagi Anda yang sedang mencari property hunian ataupun untuk dijadikan sarana berinvestasi. Harga tanah di Bandung cenderung meningkat, cocok bila dijadikan investasi untuk masa depan. Kunjungi kami di Harga Rumah Bandung

Harga Murah Mobil Bandung adalah Update harga tebaru dari berbagai macam merk mobil di indonesia khususnya Bandung / Jawa Barat. Data harga mobil ini, merupakan indikasi harga mobil baru (On The Road) berdasarkan Price List dari Dealer. Harga tidak mengikat, dan dapat berubah sewaktu-waktu. Kunjungi kami di : Harga Mobil Honda Bandung

Honda Mobilio Low Multi Purpose Vehicle ini siap bersaing dengan model sejenis yang telah lama beredar saat ini. Meskipun pemain baru di kelas ini, Honda Mobilio siap menarik para keluarga Indonesia untuk memilikinya dengan berbagai fitur dan fasilitas yang canggih juga teknologi yang sama dengan mobil kelas atas, dengan harga yang terjangkau, tetap memberikan kenyamanan dan keamanan lebih bagi penggunanya. Kunjungi kami di : Harga Honda Mobilio Bandung

Bandung Outbound Adventure adalah perusahaan yang berdomisili di Bandung dan bergerak dibidang pelatihan sumber daya manusia terutama di alam terbuka dengan menggunakan alam sebagai medianya serta kami juga Penyedia Jasa/Provider Outbound Wisata Outbound Bandung, untuk kegiatan – kegiatan yang sifatnya menantang dan petualangan Adventure seperti : Spider Web, Two Line Bridge, Hanging Bridge, Flying Fox, Arung Jeram, Amazing Race, Paintball, Airsoft Gun, Fun Off Road, ATV, Paralayang, Joyflight With Trike Tandem. Kunjungi kami di : Outbound Bandung