I am not quite as hard core as Philipp on (1) – I think it’s not _impossible_ that we code the engine to speak to different 3-d layers on different platforms. To a certain extent we already do this in that we can support GL implementations with wildly different capabilities.

But … doing so would represent a seriously huge investment in resources, so the win would have to really be worth it. So I’m not holding my breath – once DX12 and GLNext are actual real things and not just in-development specs with “buzz” we can look at the relative benefit and implementation cost. It’s unlikely that DX12 will be competitive with newer GL functionality because of the high rewrite cost and narrowness of implementation target.

X-Plane is developed on Macs and compatible with all three major operating systems, plus the two major mobile operating systems for the mobile offsprings of X-Plane. A single-platform solution that only works under one desktop OS and likely no mobile OS is therefore a no-go for all Laminar developments.

X-Plane supports control surface separation under overspeeds/overloads out of the box with PlaneMaker at least since version 9, possibly earlier.

1) Are there plans to at least partially rely on DirectX at all? Understandably, X-Plane is cross-platform which means OpenGL is the automatic go-to graphics library for support across all OSes, but DX12 + Windows 10 is sounding great, especially with the ‘closer to the metal’ support that DX12 is seeking to achieve. I also understand that OpenGL 5.0 will also reduce overhead and seek closer access to hardware, but that seems faraway and unclear. Any ideas on this?

2) Any plans for crash/soft-body physics implementation, similar to BeamNG:
http://www.beamng.com/content/
It would be pretty cool to see my 777’s wings/flaps/gears get ripped off if I exceed Vne, or the fuselage crumpling like an accordion if I exceed the runway and crash into trees.

I personally met the author of this last September at Oculus Connect in L.A.

https://forums.oculus.com/viewtopic.php?f=20&t=14070&sid=f4a1952fc08d5b83c25701760c14f099

https://github.com/jherico/OculusRiftInAction/blob/9593069bd36971e4d186ae4f01573e219172f2f5/examples/cpp/Example_9_AsyncTimewarp.cpp

There’s someone on the Oculus team that has previously worked with Ben, so we are not completely left out in the cold.

Phillipp, thanks for this update, Any suggestion on how the X-plane community can help put OpenGl on Oculus’ radar. I spent quite some time on their forum, but most of the stuff their is responded to by other developers. I have a developer account but same thing, hard to actually get to a place where someone from Oculus will actually listen.

Understood Philipp. I hoped it could offer something useful rather than my usual posts like “what is the status of Rift support?” 😉

Please file a bug.

The GPS airport load from scenery “feature” needs to be parameter driven at the sim (not just the a/c) level. I would imagine the vast majority of users use custom scenery, do not care whether or not an airport too obscure to appear in a Navigraph database appears on the GPS moving map and don’t care to wait an additional 2-3 minutes at start due to #1 & #2.

Philipp’s explanation in another forum is inadaquate, as is the “fix” coming via log.txt in 10.35.

This monstrosity needs to be addressed in a patch ASAP.