On Sun, Aug 24, 2014 at 11:12 PM, Björn Blissing <[email protected]> wrote: > pajuelo wrote: >> Yes but thinking a little about the future, they will implement those >> features at some time but the oculus sdk will become closed source sooner >> than later... and dont forget that now the oculus sdk has no linux support :( > > > I don't think that that Oculus SDK will become a purely closed source SDK. > Some of the functions will remain closed to keep away cheap knockoffs. I > guess functions such as sensor fusion and motion prediction will continue to > be closed, since this is where I guess Oculus spent most of their R&D money. > But I see no business benefit for Oculus to hide API access to screen nor to > camera.
Well, a closed source blob with a shim library that has source available under a restrictive license is not really open source. Setting ideological issues aside, there are tons of technical consequences of that design, for example a Linux support is going to be a major pain and a potential security liability. The blob would need to talk to the hw, that needs either root access or some distro-specific udev configuration, which they aren't likely to provide, except for perhaps some version of Ubuntu. It isn't hard to setup, but would make installation of Linux applications with Rift support a major pain. (the DK1 has similar issues, but at least one can see what the thing is trying to do, so no need for blind trust there). > > Right now you can access the screen, but there is no easy way of accessing > the camera. Hopefully this will open up in the future so that open source > developers can build their pure open source SDK with their own sensor fusion > and motion prediction algorithms. I am afraid that unless someone reverse engineers the camera access and what they are doing with the synchronization signal, it won't be available. It is part of their IP, normally you don't need camera sync for tracking markers, so I guess they have done something clever there and wouldn't want to give that know-how away. Even reverse engineering it could be legally iffy in some countries. I hope I am too sceptical about this and that they will prove me wrong in the future, but it is extremely unfortunate that they took this decision. The design with the runtime is not a bad idea as such, because they could easily keep it under their proprietary license and have a fully public domain/BSD-licensed API library to access it - basically establishing an industry standard for the HMD support, with the different HMD vendors only providing their own runtimes using the same API. A win-win proposition for everyone. Unfortunately, as it is, they did it in the worst possible way - the runtime is an opaque blob and the API is still completely proprietary/restricted, so it cannot act as a standard. > > As of Linux support in the official SDK; that has been promised. But it will > be interesting to see how they choose to implement it. I am also wondering. There are ways to make it work (e.g. how the Nvidia drivers are distributed), but I guess they will take the easy way out. Linux users are vocal, but there isn't that much money in them compared to Windows, so it will be a binary blob compiled for a blessed version of Ubuntu/SteamOS and the rest of Linux users will be on their own. If the runtime doesn't work on your machine, too bad ... Regards, J. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
