Jump to content

Oculus Rift - An unique product, or a new technology?


MirceaKitsune

Recommended Posts

I've slowly started gaining interest in this whole Oculus Rift thing. It's actually been a few years since I wanted to play games or watch stereo pictures / movies on eyephones with stereoscopic rendering support. And although I didn't initially care about head tracking, that will be a very welcome ability as well. It overall sounds like a very promising future for VR technology... or does it?

 

I have one big problem with this whole thing so far: I want to use devices that are the product of a technology, not a technology that is the product of a device. Think of mice for instance: Countless brands produce computer mice... optical ones, bluetooth ones, with various additional buttons, you name it. Computer mice aren't a device that belongs to either Microsoft or any other firm. Most importantly, mice require no additional drivers to provide basic functionality, and you don't need to install each brand's software to use one. They simply work when you plug them in... whether it's on a PC or Laptop, a Windows or a Linux machine, a Genius or a Logitech mouse. On the other hand, video cards require brand specific drivers (like ATI and Nvidia), but applications themselves don't need to code support for each of the two so they can render images. If I'm to take interest in modern eyephones, I want it to be the same thing; A new technology that can be developed and supported by anyone and everyone, rather than being some corporation's toy. Especially with the popularity the Rift is getting, I imagine patent trolling (for both hardware and software) will occur, and things might not go so smoothly.

 

Now I've read about alternatives to the Oculus Rift already being prepared. So in regard to hardware, I assume the problem isn't very bad, and "eyephones with head tracking" can themselves be considered a free technology that's not up for patent claims. But I am somewhat concerned on the software part. Typically, if a common open-source implementation can exist. By common I mean a driver as well as per-application integration that can work with all and any such devices; The Oculus Rift itself, as well as all the different products made by other brands as an alternative... which might use different approaches and technologies. For example, will a game engine be able to write common code for eyephones, which can render stereoscopic image on both the Oculus Right and Google Glass alike?

 

As an open-source game developer, who might be interested to support the technology myself, I'm even more interested in better understanding this. I don't care to ever code support for "someone's hardware", only for actual architectures. I also wouldn't want to be in the position of adding support for the Oculus Rift, then when someone makes an alternative write an integration for that, then when a third brand creates yet another headset code that too, and so on. That would be like manually adding support for Genius, IBM, Microsoft, etc. keyboards to my code, which would be preposterous.

 

So what's known so far on this end, and how do you think things will go? Will the Oculus Rift require both drivers and application integration to support it, will only drivers be needed but the implementation becomes common, or will the Rift use a common architecture entirely which all programs and similar hardware can relate to without individual dependencies?

Edited by MirceaKitsune
Link to comment
Share on other sites

I've slowly started gaining interest in this whole Oculus Rift thing. It's actually been a few years since I wanted to play games or watch stereo pictures / movies on eyephones with stereoscopic rendering support. And although I didn't initially care about head tracking, that will be a very welcome ability as well. It overall sounds like a very promising future for VR technology... or does it?

 

I have one big problem with this whole thing so far: I want to use devices that are the product of a technology, not a technology that is the product of a device. Think of mice for instance: Countless brands produce computer mice... optical ones, bluetooth ones, with various additional buttons, you name it. Computer mice aren't a device that belongs to either Microsoft or any other firm. Most importantly, mice require no additional drivers to provide basic functionality, and you don't need to install each brand's software to use one. They simply work when you plug them in... whether it's on a PC or Laptop, a Windows or a Linux machine, a Genius or a Logitech mouse. On the other hand, video cards require brand specific drivers (like ATI and Nvidia), but applications themselves don't need to code support for each of the two so they can render images. If I'm to take interest in modern eyephones, I want it to be the same thing; A new technology that can be developed and supported by anyone and everyone, rather than being some corporation's toy. Especially with the popularity the Rift is getting, I imagine patent trolling (for both hardware and software) will occur, and things might not go so smoothly.

 

Now I've read about alternatives to the Oculus Rift already being prepared. So in regard to hardware, I assume the problem isn't very bad, and "eyephones with head tracking" can themselves be considered a free technology that's not up for patent claims. But I am somewhat concerned on the software part. Typically, if a common open-source implementation can exist. By common I mean a driver as well as per-application integration that can work with all and any such devices; The Oculus Rift itself, as well as all the different products made by other brands as an alternative... which might use different approaches and technologies. For example, will a game engine be able to write common code for eyephones, which can render stereoscopic image on both the Oculus Right and Google Glass alike?

 

As an open-source game developer, who might be interested to support the technology myself, I'm even more interested in better understanding this. I don't care to ever code support for "someone's hardware", only for actual architectures. I also wouldn't want to be in the position of adding support for the Oculus Rift, then when someone makes an alternative write an integration for that, then when a third brand creates yet another headset code that too, and so on. That would be like manually adding support for Genius, IBM, Microsoft, etc. keyboards to my code, which would be preposterous.

 

So what's known so far on this end, and how do you think things will go? Will the Oculus Rift require both drivers and application integration to support it, will only drivers be needed but the implementation becomes common, or will the Rift use a common architecture entirely which all programs and similar hardware can relate to without individual dependencies?

Im sorry i meant to reply. I can see that short terms they would be using drivers, and a uncommon architecture. Long term i think they will patent the software cor business use and the headset market could then have a common (or perdominate) architecture.

Link to comment
Share on other sites

  • 2 weeks later...

 

 

or does it?

It does, but not for the reasons you have listed.

 

 

 

They simply work when you plug them in...

Boy, you must not have had any high-end gaming mice then; my rat does not work like a basic mouse without the driver, glitches like you wouldn't believe (os x and windows)

 

 

 

On the other hand, video cards require brand specific drivers (like ATI and Nvidia), but applications themselves don't need to code support for each of the two so they can render images.

Yes and no, if you want to draw something to the screen, yes, if you want to be a progressive gaming engine than no, you have some code that is different on NVidia then AMD; they do things vastly differently and so your optimizations and some implementations will too differ.

 

 

If I'm to take interest in modern eyephones, I want it to be the same thing; A new technology that can be developed and supported by anyone and everyone, rather than being some corporation's toy.

Sorry that has a very low probability of happening, because different companies provide different implementations and different technologies, for the most part they require a very specific kind of adressing, distortion, even drawing to make the technology work, and this is before head-tracking.

 

 

 

Especially with the popularity the Rift is getting, I imagine patent trolling (for both hardware and software) will occur, and things might not go so smoothly.

I dont think that will slow them much, Facebook has a good legal team to where oculus doesnt have to worry about that too much, and the developers they have themselves have numerous patents, they are bright people some are legends at the forefront of their respectful fields. They have the money, they have momentum, they brought the cost down, they are growing their name, Oculus i believe, and i really want to, is becoming a force to be reckoned with.

 

 

 

For example, will a game engine be able to write common code for eyephones, which can render stereoscopic image on both the Oculus Right and Google Glass alike?

Google glass does not render stereoscopic images, unless you are revealing to us that the next generation may have 2 displays?

Answer is 2-fold. On one hand if the physical technologies are similar enough, and the driver interface is the same, then yes, you could potentially support different manufacturers. But as i have already said, the physical technology is different thus the drivers are vastly different thus SDKs are different thus engines will have to write separate code to draw on different kinds of devices; luckily usually its not that difficult a task.

 

 

 

So what's known so far on this end, and how do you think things will go?

You will require different drivers, you will require different SDKs, i feel that game engine developers together with video drivers writers, as they currently do for many things, will take care of the transforms for you and abstract the vr devices away while having different code for each one, and if you want to write an engine, you will have to implement different SDKs for different devices. I will not exclude the fact that Oculus may push for some sort of a standard, but i doubt that everyone will comply.

Link to comment
Share on other sites

AtomicMaster: From what I discussed in other places about this, it seems that this is thankfully not the case so much. Particularly, the Rift should use a standard architecture for the basics, although a few parts might require additional software to work properly.

 

The two important things I consider basics are (stereoscopic) rendering to the lenses and head tracking. The lenses are said to be detected as standerd video devices, the same way VGA / DVI / HDMI monitors are... which is what I'd expect and hope. I don't know if dividing the image to each lens is understood by the standerd display system, but I was told that the OS should detect when side-by-side stereo splitting is appropriate so this should be generic. As for the head tracking mechanism, that's apparently detected as a standerd input device as well (joystick or mouse) which is great!

 

My example with the mouse also applies in this case, and what you said is correct; Complex mice, like those gaming mice with tons of buttons and more than one wheel, will require their own driver in case you want to use those extra buttons. But the standerd behavior as a mouse, which is tracking the pointer + understanding the left / middle / right buttons + the standerd mouse wheel, work automatically with any and every mouse. Unless of course it's a very weird and unusual mouse I imagine. That's the same idea I'm hoping the Rift and other VR devices go for.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.