Where did the LibOVR code go in SDK 0.7?

The code is no longer included, though you should not need it.

Thanks for your answer.

That is very unfortunate :cry:

@VectionVR We offset the VR headset orientation to the user seat to use VR on motion simulators.
We have been working on VectionVR from the earliest oculus lirary versions.
We have followed and adapted our code at every oculus library release.

We greatly appreciated your efforts to redistribute the Oculus libray as a dynamic library since version 0.5 allowing us to integrate our code without having to contact each and every game developer.

But now we are back to square one, even worst than square one actually.

Can you please explain why you decided to remove the code ?
How can we adapt the code of the library after this refactoring ?

Thanks

When you obtain the tracking pose from the SDK, you should be able to do whatever you want with those values inside your engine or application. So before you apply the pose to your camera, you can modify the value, reverse it, do whatever you want.

We don't develop games or game engines,
we integrate motion simulators with games supporting the Oculus Rift.

We developped a generic way to offset the rift to a dynamic seat position -> VectionVR (available on github)
We based our solution on a patch of the Oculus Library as it was open source and already integrated by the games and engines.
That way we could follow the Oculus Library life cycle without Oculus having to support this feature and it was completely transparent for the game developers.


We invested a lot of effort in this project believing the Development Kits and the open sourcness of your code was for the developer comunity to start integrating the rift to their products before the customer product launch date.

Why closing your sources now ?

Thanks

Possible explanation is that they did it the same reason OSVR (of all...) did it too http://www.osvr.org/blog/?p=126:

Unlike most of the OSVR platform, the Render Manager is not open-sourced at this point. The main reason is that the NVIDIA API was provided to Sensics under NDA and thus we cannot expose it at this time.

And of course you believed the development kit to be open. After all, palmer said https://reddit.com/r/oculus/comments/21 ... vr/cgc06b2

We promise we won't change. If anything, our hardware and software will get even more open, and Facebook is onboard with that.

https://www.reddit.com/r/oculus/comment ... vr/cgbz25t

Facebook has a good track record on open hardware and software, which is great for us. We want to make our hardware and software even more open than they already are, and they are totally cool with that.

https://www.reddit.com/r/oculus/comment ... ure_of_vr/

Facebook is run in an open way that’s aligned with Oculus’ culture. Over the last decade, Mark and Facebook have been champions of open software and hardware, pushing the envelope of innovation for the entire tech industry. As Facebook has grown, they’ve continued to invest in efforts like with the Open Compute Project, their initiative that aims to drive innovation and reduce the cost of computing infrastructure across the industry. This is a team that’s used to making bold bets on the future.

... and then they released their 0.4 SDK with the closed source head tracking service.

"jhordies" wrote:
We don't develop games or game engines,
we integrate motion simulators with games supporting the Oculus Rift.

We developped a generic way to offset the rift to a dynamic seat position -> VectionVR (available on github)

You could probably still do this by creating a modified version of the Oculus SDK shim, and do the modification of the head poses inside ovr_getTrackingState, and inverse modification inside ovr_Submit.

"jherico" wrote:

You could probably still do this by creating a modified version of the Oculus SDK shim, and do the modification of the head poses inside ovr_getTrackingState, and inverse modification inside ovr_Submit.

Thanks for your answer,
We used the network stack and architecture of the LibOvr, we could of course do it in another way even if it's not that clean.
But, correct me if I'm wront, I didn't see a way to regenerate the dll in 0.7, only the static libraries (.lib), meaning we can't intgrate the modified version of the library transparently with games anymore.

"jherico" wrote:
You could probably still do this by creating a modified version of the Oculus SDK shim, and do the modification of the head poses inside ovr_getTrackingState, and inverse modification inside ovr_Submit.

If I understood it correctly, they want to switch out the libraries in third party applications to add support for their technology without altering the third party applications.

Now they'll need to look at dll injection/hooking...

"jhordies" wrote:

"jherico" wrote:

You could probably still do this by creating a modified version of the Oculus SDK shim, and do the modification of the head poses inside ovr_getTrackingState, and inverse modification inside ovr_Submit.

Thanks for your answer,
We used the network stack and architecture of the LibOvr, we could of course do it in another way even if it's not that clean.
But, correct me if I'm wront, I didn't see a way to regenerate the dll in 0.7, only the static libraries (.lib), meaning we can't intgrate the modified version of the library transparently with games anymore.

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.

Well, since Oculus seems to be closing their source more and more for each version, I guess the next step would be to petition them for a simple interface for motion base integrator to work through.

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. But that would probably kill the business for @VectionVR and similar companies. So I guess they desire a more raw form of interface.