Skip to main content
jhordies
Up and Coming
September 25, 2015

Where did the LibOVR code go in SDK 0.7?

Hello,

I can't find the code of LibOVR anymore.
I use to find the code in :
OculusSDK_061\LibOVR\Src:

<DIR> .
<DIR> ..
<DIR> CAPI
<DIR> Displays
<DIR> Net
39.117 OVR_CAPI.cpp
50.151 OVR_CAPIShim.c
6.479 OVR_CAPI_Util.cpp
18.626 OVR_Error.cpp
17.971 OVR_Error.h
12.243 OVR_PadCheck.cpp
2.043 OVR_PadCheck.h
48.531 OVR_Profile.cpp
8.558 OVR_Profile.h
8.792 OVR_SerialFormat.cpp
4.361 OVR_SerialFormat.h
92.936 OVR_Stereo.cpp
38.752 OVR_Stereo.h
8.207 OVR_StereoProjection.cpp
2.580 OVR_StereoProjection.h
<DIR> Resources
<DIR> Sensors
<DIR> Service
<DIR> Util
<DIR> Vision

But in the 0.7 SDK I downloaded from the Oculus website, the same folder only contains
OculusSDK_07\LibOVR\Src

<DIR> .
<DIR> ..
52.355 OVR_CAPIShim.c
7.189 OVR_CAPI_Util.cpp
8.718 OVR_StereoProjection.cpp
<DIR> Resources

I looked in the other folders and the kernel, in case it had been migrated, but I can't find the missing files.

Could somebody explained me where to look ?

Thanks

    14 replies

    Show previous replies
    jhordiesAuthor
    Up and Coming
    September 30, 2015
    Hello pixelminer,

    "pixelminer" wrote:
    A very trivial solution would be an interface to feed the acceleration data (translational and rotational) of the motion system to the Oculus SDK and let the SDK handle the negation of the external forces.


    That's exactly what our VectionVR opensource patch does.

    "pixelminer" wrote:
    But that would probably kill the business for @VectionVR and similar companies. So I guess they desire a more raw form of interface.


    We've didn't restrict our solution to any particular hardware. We just wanted to make the Oculus Rift compatible with motion simulation.

    I had the chance to meet with Palmer and ask him about integrating the VectionVR patch in their code (or any similar feature) during the Oculus Connect 1, he also feared we wanted to have a solution locked for our hardware.
    I explained how VectionVR was generic and not hardware specific but he told me It was not in their priority list (which I understand because of the niche nature of the feature) to support such a feature.

    Releasing our solution as a patch to the SDK was a nice and clean solution because it didn't requiere Oculus to worry about it our give any kind of support. It was available for everybody to integrate. It was also very convenient to just add a feature to the OculuLibrary transparently for the game.

    We would love to see the feature integrated but I doubt it.
    I really hope Oculus will stand to their initial commitment to opensource.
    Vrally
    Up and Coming
    September 30, 2015
    "jhordies" wrote:
    Hello pixelminer,

    "pixelminer" wrote:
    A very trivial solution would be an interface to feed the acceleration data (translational and rotational) of the motion system to the Oculus SDK and let the SDK handle the negation of the external forces.


    That's exactly what our VectionVR opensource patch does.


    Ok, so if I understand you correctly; your patch lies between the Oculus sensors and the SDK and subtracts the Motion system inertial data from the Oculus inertial data?

    "jhordies" wrote:
    I had the chance to meet with Palmer and ask him about integrating the VectionVR patch in their code (or any similar feature) during the Oculus Connect 1, he also feared we wanted to have a solution locked for our hardware.
    I explained how VectionVR was generic and not hardware specific but he told me It was not in their priority list (which I understand because of the niche nature of the feature) to support such a feature.


    On the other hand it would be quite easy for them to add an interface for supplying external accelerations. It is only 2 more vectors to handle.

    "jhordies" wrote:
    We would love to see the feature integrated but I doubt it.
    I really hope Oculus will stand to their initial commitment to opensource.


    I hope this as well, but regretfully the experience is telling another story. Which is too bad since Oculus is hurting the spirit of the innovators and hackers. Many who has been early adopters and evangelists for VR in general and especially for Oculus.
    jhordiesAuthor
    Up and Coming
    September 30, 2015
    "jherico" wrote:


    Ah, I see what you mean. You don't want to have to have the app writer integrate with your code, you just want it to work. Well, that's admittedly a bit trickier. The most likely path to success then would probably be to create a DLL that's compatible with the interface on the LibOVR DLL... then you could create your own runtime installer, which would install the normal service, the normal DLL with a changed name and your wrapper DLL with the original name. For any function you don't care about you'd just do a pass-through to the normal DLL from your wrapper. For those you do care about, you could modify the values on the fly before returning them to the client.

    So if someone wants to use your system, them they'd need to install your version of the runtime, but otherwise it should be transparent.

    This approach has several downsides. If you want to support the broadest possible range of games, you'd need to create both 32 bit and 64 bit wrappers, and you'd probably need to support the same set of SDK versions that the wrapped DLL did. You also might come into conflict with the licensing terms, specifically those about using the SDK code to support hardware other than the Rift (though I'm pretty sure the spirit of that clause is "don't use this SDK to make 'rift-compatible' headsets). You also might end up with Oculus having a claim to ownership of the entire wrapper. That would probably depend on the interpretation of 'derived code'. Of course Oculus has an incentive here to ensure that making a binary-interface compatible DLL is considered derivation, since otherwise it renders toothless the clause about not making Rift compatible headsets that use the SDK. Anyway, I am not a lawyer, just looking at it from a technical perspective, where it's certainly do-able.


    Thanks for your answer,
    I agree with you, it's technically feasable one way or another.

    We did comply with the Oculus Licence, we contacted them to inform them about our patch, made the patch available to everyone (github), it's not locked to any specific hardware.

    We didn't fear Oculus claiming it's ownership, we would have loved to see the feature integrated officially.

    We were happy to see the Oculus Library become a dynamic library.
    It made possible taking benefits of the opensourceness of LibOvr without having access to the code of each and every game/application to recompile them with a modified version of the library.

    But now that Oculus closed the source, it seems clear that they don't want the community to contribute or add features anymore.
    We were already struggeling with the positional tracking not being released, but if Oculus doesn't want us to change the library, we won't try to by-pass the new restrictions at every release.
    It's frustrating after having spent time and effort working on this project and maintaining it.
    littlezaphod
    New Participant
    December 23, 2016
    Hi all,
    any news on this topic? I have developed a 6DOF motion platform as a private project and would like to use the rift for visualization. Subtracting platform external acceleration from Oculus head IMU is the way to go but no longer since the closure of the relevant SDK portions.
    Thank, Pat
    Terms & ConditionsAccessibility statement