EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

X-Plane 10.32 is now final – you’ll get an auto-update message when you run X-Plane.

Coming soon:

  • 10.35 – we still have code to put the finishing touches on, but the plan is to release more Gateway airports in 10.35.  This will not be the last gateway release (obviously 🙂 so if your airport was approved too late to make the cut, we’ll try to get the next release out soon.  (Our goal is to keep gateway airports flowing rapidly so that everyone can get the full benefit of everyone else’s work easily.) I am hoping for public beta within a week.
  • WED 1.4 – will include GeoJpeg2000 image support, improved orthophoto overlay creation, and importing directly from the Gateway.  Again, I am hoping for public beta within  week.

If you would like to know the status on the Oculus Rift, I suggest you comment on this post (even though it is off topic), any other post that is still open for editing, and every additional post we make (no matter how off topic) until Philipp posts an update; while he has not responded yet, he did assure me that he will make a statement if he gets at least 275 off-topic comments on the Rift.*

* This last paragraph is completely false, just another case of me being snarky and poorly behaved on the interwebs.

The real number is 374 posts. 😉

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

60 comments on “10.32 Is Out, WED and 10.35 Soon”

    1. The status is that Windows bluescreens when we use the Oculus provided shims for the graphics driver. We are in contact with developers at Oculus and have sent detailed crash repotss and the kernel memory dumps they requested. Haven’t heard back from them since then. OpenGL is simply not that high on their priority list. Almost all the cool rendering features we learned about at Oculus Connect in September are (still) DirectX only.

  5. Ben,
    Can you tell me what Windows, Nvidia Driver you are currently using and do you have good AA. I just can’t seem to get decent AA at high settings. I’m currently using a GTX780 3 gig series card.
    Thanks.

    1. I’m on Win-7-64 with the 340.52 drivers. I cannot tell you if I have “good” AA, because “good” is totally subjective.

      AA is a trade-off between performance and aspects of image quality, and the image quality evaluation is potentially subjective. The trade-offs I get probably aren’t relevant to you; I have a GeForce 580 (I haven’t seen my 680 since I moved, which is sort of embarrassing) on a relatively small 1920×1200 monitor. So you’re coming at the problem with a lot more GPU power, probably applied to a lot more pixels, looking for some aesthetic result that we don’t have a good way to quantify.

      I can also tell you that I have spent -no- time investigating options that Nvidia provides in their control panel (my understanding is that they allow for a fair amount of tweaking). We provide a series of AA options based on what we can see in the OpenGL API; if you manage to do better with the NV control panel, great, but it’s not something I can work on.

      One thing is for sure: you’ll have more AA options with HDR off. With HDR on, most of the rasterization (and thus aliasing) is done on off-screen surfaces that Nvidia can’t affect with control panel options. Furthermore, HDR is FSAA-unfriendly, so you get only a few options: FXAA + some amount of OGSSAA. Since it’s an HDR render, the OGSSAA chews up GPU _very_ quickly; 16x OGGSAA will cost you 16x performance.

      If you pick non-HDR rendering, you can in theory start to play with the NVidia control panel and take advantage of some of the “clever” strategies the provide (e.g. 4x FSAA + 16x rasterization for better edging with less GPU).

      1. Thanks for the clarification Ben.
        Hopefully before XP-10 is on final you’ll look at this more HDR is too nice to leave behind.

        1. We do have a next step to look at: using the hw anti-aliasing in HDR mode. A while ago, that wasn’t that exciting of an option, but these days:
          – Hardware is very often bandwidth constrained because we’re running huge screens AND
          – Hardware now comes with compressed color buffers; this path potentially has better compression ratios with hardware FSAA than OGSSAA.
          So it’s worth trying. We’re working through GL modernization that should allow us to do this some time.

          With that in mind I can’t say when we will have other FSAA options or whether it will be in v10.

  6. Keep up the great work guys, look forward to hearing more about the Rift in due course, I think it be one of the biggest single improvements in X-Plane to date, no need for large expensive screens or projectors. Do you know what mouse cursor behaviour will be like when using the Rift?

    1. I don’t think the future of UI is mouse driven, whilst in VR. I’m hoping Oculus’ purchase of Nimble leads to great things in this regard.

  7. Haha. As soon as I read the words “If you would like to know the status on the Oculus Rift, ” I knew something snarky was coming!

      1. As long as that doesn’t creep into the coding, Ben. I don’t want to see any low flying snark’s as I make my final approaches. Could be quite off-putting.

  8. Hi,

    You didn’t say anything about Yosemite issues and I am wandering if they will be addressed in 10.35. I’ve been testing VRAM with OpenGL Monitor and I’ve found that my 1 GB VRAM sometimes gets completely exhausted and the computer starts swapping; that’s when I get like 4 fps and this happens mainly on approach to an airport, at low altitude. I usually can get significant improvement by pointing the camera to the aircraft floor, so that xplane doesn’t have to draw scenery, or choosing an external view like Forward with HUD.
    I know I have a lot of scenery and sveral plugins, which may partly explain the issues, but I still get the feeling that there is a memory leak somewhere. I am looking forward to the promised revision of the Mac version, hoping it will cure some of the present problems.

    Best regards,
    José

    1. Hi Jose,

      PLEASE FILE A BUG!!!!!!!!! Your post is the most coherent statement I’ve heard on Yosemite and VRAM so far. We are DESPERATELY seeking a reproducible scenario. This is a very high priority. But for all of the noise on the org (20+ pages of posts) only ONE user filed a bug. Please file a bug and we’ll go from there.

      Other non-stuttering Yosemite issues should be fixed in 1035 – I have a set of fixes to merge in. But we have not had any forward progress on performance, and right now the limiting factor is a good reproducible bug report.

  9. When I was a TA, the professor did something similar by asking the students to all email me individually and ask for updates on their grades. For some strange reason getting hundreds of the same email filling my inbox didn’t particularly motivate me as much as one might think :).

    1. LOL it can be motivating – just not in the intended way.

      I think Philipp’s exact words were:

      “instead of user mocking, can you compile me a Steam build on Mac?”

      I had to point out that I can do both at the same time…

      1. Let’s hope that two threads can render at the same time in the future as well 😀 (sorry, i had to…)

  10. Being well aware of the current Open-GL situation regarding native Rift/VR support, I am a bit worried that LR might miss the jump on the bandwagon here, regarding not only HMD support but also the integration of the next generation of input devices for VR (Control VR, IGS Glove, Leap Motion).
    I believe with the right bit of code (SDKs are out there) and choices at the core sim platform level, it would take X-Plane to the next level.

    Some other current sims like P3d, DCS etc. have already adopted some sort of native Oculus support, as well as the newest simulation titles like Elite and Star Citizen. In XP10’s case it’s not only a matter of getting some API from Oculus that solves all the integration problems, only very few systems are capable of running XP10 in the neighborhood of 75fps, let alone with some of the VFX sliders up and a FF777 virtual cockpit into a busy payware scenery airport. Not going to happen!

    Future more powerful GPUs might boost overall fps even more, but it seems that there are some bottlenecks within the game engine itself. For some of these, I imagine some crucial engineering decisions would have to be made to straighten them out.

    It’d be nice to hear whether any of the LR guys has info to share on this.
    Not quite at 374 yet, though.

    1. The 75hertz refresh rate is actually not as bad as it sounds. Note that display refresh rate and frame rate of the application are not the same.
      The Oculus SDK has a very nice trick called asynchronous timewarp that takes the last frame supplied by the application and warps it based on the head movement that occurred during the time the application is busy generating the next frame. That is, the frame itself is static, but it is displayed in the correct space where you’d expect it given your head movement.
      The warping can be updated several times while we are waiting for the application to generate a new frame.

      I had the opportunity to test an application with timewarp enabled – the difference is profound!! Even at 25fps the reaction to your head motion is instant and fluid. 25fps update without any time-warping makes you feel dizzy after a short time. If what you are seeing lags your head movement by 50ms it introduces motion sickness for many people. Time-warping takes some of the load of following your head motion away from the application into the realm of the Oculus SDK, which allows relaxing the fps constraints of the application considerably, while it still feels fluid and doesn’t induce the urge to throw up.

      Sadly, when I last checked async time-warp was on the road map for DirectX, with no word still regarding openGL.

      Currently, we can use what the Oculus guys call client-rendering – this is what I’ve demonstrated in the X-Plane builds I’ve shown at FSWeekend, Airventure, Cosford FlightsimShow, FSKonferenz, PC Flugtage, etc.. It does not support async time-warp, nor does it allow targeting a 75Hz display in native refresh rate. In order to get this, we need the special display driver from Oculus between us and the Rift, instead of the OS’s default driver. Problem with the Oculus driver is it blue screens windows for our openGL setup.

      1. Thanks for the detailed reply, Philipp. This clarifies the challenges you face and why there is such a long delay in getting Rift support out. I’m still greatly anticipating flying with the Rift, but I now understand that it will be a matter of months and not weeks before being able to do so.

      2. 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.

  11. Thanks for the news! So this will be my first update. How do I go for it? Will the update reinstall all or only replace some files? Do I risk to have all my custom sceneries replaced? or if I replaced some of the default textures (like the runways)? and what about plug-ins? Sorry for all the questions but I am used with Windows always messing things up when I upgrade something, so I worry.

    Thanks again

    – Andy

  12. Virtual reality is no doubt the future technology, not only for entertainment but also for science, research, prototype modeling etc. Oculus Rift is nowadays at the front of this development since Facebook investigated $2 billion. (I was one of those who donated this kickstarter but earned zero..). X-Plane cannot stand by side and handle this important development in the simulation world as if it was another nice feature.

    I think that you Ben and you team must put this issue on the top of your list of further X-Plane developments . This because X-Plane has in my opinion the potential to be the best simulation software to use with the highest stage of hardware technology. It is the famous question of to be or not to be at the edge of virtual reality of flight simulation.

  13. Thanks for the update on Oculus integration. It’s nice to at least know where it stands given that I have invested heavily in xplane and haven’t been able to use it on a 2d monitor since trying it on the Oculus Rift DK1 with third party software.

    Hopefully oculus give OpenGL some love soon. My Oculus based cockpit will have to be used with lesser helicopter sims for another while I guess.

  14. Hi,
    hopefully OSVR will give you a better OpenGL integration as Oculus did.
    http://www.osvr.com/

    I would like to see a Leap Motion / Nimble VR ingetration so that the user is able to use knobs and switches by hand. This would push flight simulation into next level.

    Thx

  17. i guess everything has been said about the rift so:

    10.32 fixes for situations – weather is still not being auto regenerated when loading a situation. Is this an internal decision? If not, can we have it in 10.35 please.

    Any possibility of being able to assign “glider winch” and “Glider Aerotow” to keys or buttons. Unlike powered A/c, we can’t just select a runway and go. For us it’s an extra trip to the menu bar. Probably a very low priority but ………

      1. Sorry Ben, I was just querying whether it was a bug or an internal decision. I know in our email to-ing and fro-ing, you said you were going to “measure twice -cut once” with regard to situations.

        If it’s a bug I will of course report it.

  18. Hey,
    I’m also extremly eager to get X-Plane running with Oculus… until now, I have to “fly” the Oculus with Prepar3d and DCOC. It’s nice, but of course, no flying and not as beautiful as X-Plane… We are hoping for building a simulator based on this…
    Good work with the new ignitionmodel.recipEng in .32, btw!

  19. Will WED 1.4 be able to make .ter-files with orthophotos? I´m working with a large photoscenery and have imported an orthophoto scenery into WED with .pol-files( for object placement). The third-party photoscenery program I´m using cannot make .ter- files without bad looking artefacts in the scenery, so I´m pretty much stuck with .pol-files for a large area.
    On the other hand, is there a big difference performance-wise between using .pol or .ter- files in a large photoscenery? I´ve made some tests and saw no significant differences, but I know .ter-files are the preferred way.

    1. No, because WED doesn’t process .ter files or base meshes at all.

      In the long term I’d like to program WED to create scripts for Meshtool – and in that case it would make sense to make .ter files. I also need to produce a v10-era Meshtool.

  20. So, I know this comment may seem somewhat force but…what about Oculus Rift support? 😛
    It would make X-Plane really complete from the immersion point of view!
    I’ve seen project using Oculus rift together with Leap Motion, that would be awesome so we can really look around, pilot, and interact with the cockpit.

  21. Dear Philipp,

    thanks for the update regarding the Occulus RIFT.
    I understood, that RIFT support might come much sooner on Windows, as you are actually testing on this.
    So is it still the case, that OPEN GL on Mac is lagging behind massively?!
    As flying solely helicopter on my X-Plane for Mac I am heavily interested in any news about that.

    Thanks again & Best Regards, Markus.

      1. Philipp have you seen these working examples of OpenGL code working in direct mode on oculus SDK 4.4

        https://forums.oculus.com/viewtopic.php?f=20&t=17842

        I’m not sure if they are relevant to the issues you have faced with implementation but it seems some progress has been made with OpenGL since the blue screen issues you first reported in September.

        I’m anxious to see xplane working in the rift so I did some digging. I’m not a programmer so apologies if the link is not relevant.

  22. Steam updated to 10.32 and now it crashes on start. 🙁 Removed Gizmo64 and it does run. Does anyone here have the same problem on a Mac? Thanks.

  23. After experiencing extended load times at start-up due to this new GPS “feature”, I must ask, why in the world would you replace a few known controlled datasets with infinite points of failure?

    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.

  25. Oculus Rift support is wonderful – I haven’t personally tried it out yet but it sounds excellent, at least in theory. I’m looking forward to a full, working implementation. Meanwhile, I’ve got a couple of questions —

    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.

    1. 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.

    2. 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.

Comments are closed.