It simply means we now know that Oculus is dedicated to solve their openGL problems and be cross-platform. We can’t do it unless they provide a working foundation. Also, we are working with someone at Oculus to solve problems as they arise. However, it would be foolish to think that Oculus changes their internal priorities just because of us.

Good news indeed. Although it’s a little vague what that means for us (well, X-Plane that is).

Does that mean that you guys are still dedicated to Oculus support, but will probably put it on hold for a while 🙁

Or does that mean you have enough information/support now that you are able to press forward now?

Great News
Danke Philipp 🙂

Yes. We’ve gotten lots of good input and are now in direct communication with engineers at Oculus. Also, at the conference Oculus stressed they want to fix their openGL problems very soon and that Mac and Linux support is not dead, it will definitely come.

If they are running with OGL they are probably using client warping and extended desktop – this is -not- the path that Oculus recommends to ship an app on – it’s basically prototype proof of concept code; the same path that Philipp has mostly working. This is also the code path that has problems with vsync, etc.

I’m pretty sure that Outerra (www.outerra.com) runs OpenGL and it has some pretty excellent oculus support… so it must be possible?

Cheers
Ben

Hi Jim,

_If_ another tech comes along that has adequate market share, we will consider native integration. My comment on plugin support and head tracking was based on misunderstanding your comment about HDMI. Currently it is necessary for us to do stereoscopic integration at the app level. This may change or we may provide a ‘canned’ stereoscopic solution if standards emerge; right now we have to get a stereoscopic surface from the driver, which is not passed on to the device in a general way.

but I appreciate your candor.

Thank You
Yours truly
Jim
JazAero designs

Honestly: probably not.

Our view is that _most_ hardware should be supported by third party plugins that can be tuned by the hardware maker to take maximum advantage of that hardware. Anyone who remembers GoFlight support via built-in LR and via a plugin understands how much more detailed support can be when it’s done in a plugin. We (LR) are simply divided too many ways to give each piece of hardware a ton of attention, particularly when only a small percentage of our users have it.

The Rift is an exception because it’s operating at a different scale.

If the device is really only a head tracker, a plugin-based implementation will be pretty straight-forward. The Rift really only needs to be “built-in” for its stereoscopic display properties.