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

(Spoiler alert: the answer to the “when” question is going to be deeply unsatisfying and annoy you.  Sorry – there isn’t a date.  But at least you’ll know what’s going on.)

It’s been over four weeks since Philipp publicly demonstrated an early X-Plane 10.30 build with the new GPS.  What’s going on now?  What about 10.30?

What’s In X-Plane 10.30

Here’s a rough overview of what’s going into 10.30.  We’ll have a complete change log when we release a public beta; right now the change log is not compiled, and it’s going to be long enough that I can’t go through everything now for a blog post.  (To give you an idea, Austin has 158 commits on his branch going in.)

The one truly big new features is the new GPS Navigator that will ship in X-Plane 10.30.  Please note that an aircraft must be modified to take advantage of it.  It looks like a basic modification (e.g. if the aircraft already has the old G430) should be a few clicks in Plane-Maker.  Similarly, you can add the GPS to your aircraft with drag-and-drop in the panel editor.

Philipp has Oculus Rift support working but we’re still trying to figure out whether to ship it in 10.30 or wait; the actual Rift support is usable but the user interface is still quirky.  Since they’re not actually selling devices to consumers yet we may wait.

We’re working on a number of visual improvements:

  • Tuning and improvements to the look of the clouds, including their behavior as you fly into and out of them.
  • Optionally increasing the distance the DSF scenery is drawn for better long-range rendering.
  • Better fog in lower visibility situations.  (I’ll try to post some experimental pictures over the next few days.)

This stuff is not finished – in particular, my fog work is not done yet, but if we can get it all working together it should make the visual experience in X-Plane 10 a lot better, and a lot closer to what we imagined.

Under the hood 10.30 contains major changes to Plane-Maker’s panel editor and the entire OpenGL stack; these changes don’t provide any immediate features – this is just us putting in new infrastructure for future updates.  I mention this only for completeness; infrastructure changes can cause bugs that we’ll fix before and during beta, but they’re necessary to keep the product evolving.  The OpenGL changes in particular can affect plugins if they haven’t followed plugin SDK guidelines.

10.30 has some small extensions for third party developers, including a number of new dataref-based interfaces to customize sim behavior; we held off on this kind of thing during 10.20 to ship 64-bits faster so now we’re catching up on adding flexibility for third parties.  I’ll post a complete list with the release notes; some of this work is already done and some is still in-progress.

Finally there’s just a huge number of bug fixes, including a number of high profile and stubborn bugs.  Please do not ask about your favorite bug in the comments (I will nuke your comment!).  We will post complete release notes when we reach public beta.

The Release Process

We’re trying two changes to our release process for X-Plane 10.30:

  • We are doing extensive private pre-beta testing before the public beta.  Normally we release a public beta and get 300 reports that all tell us the same one big bug.  This time we are starting with a much smaller group of testers and slowly growing it; this gives us much more efficient feedback and should speed the whole process up.
  • We are doing private testing on parts of the sim individually before we jam them all together.  I’ve had users test my “lots of DSFs” code separately from Philipp having people test the GPS.  Traditionally we’d test everything at once, and the chaos of having so much new code in one single build made life hard for both testers and developers.  So this time we’re  starting small and slowly bringing the pieces together.

(Please do not email or post requesting private beta access – we are not looking for additional testers at this time.)

This process is an experiment; when 10.30 is done we’ll have to step back and see if the added complexity saved us real development time.

When Will 10.30 Be Released

We are currently privately testing some parts of 10.30.  My expectation is that we will reach a public beta of 10.30 with the GPS, but without all fog-related features in weeks. (I don’t know how many weeks – it depends on how fast the current bugs get fixed and what new bugs are found.)  Austin and I have differing views on this; I always push toward “don’t public beta until all of the bugs are gone” and Austin pushes toward “let’s get people the new GPS ASAP.”  I think the actual public beta will be somewhere in the middle.

The current plan is to get the GPS public before we integrate some of the newer fog features so that users can use the GPS (and third parties can start to add it to their airplanes) without everyone being held back on my incomplete fog code.  We’ll roll the fog code in when it becomes stable enough.

What Else Is Going On That’s Not In 10.30

A few things that are not part of 10.30:

  • Alex is still working on autogen; we’ll release art assets when they are complete and shippable, but 10.30 won’t wait for them.  (10.30 does have the autogen engine enhancements he needs.)
  • I still have a bug left to fix for DSF recuts; those also aren’t tied directly to 10.30.
  • The Airport Gateway and WED 1.3 (to send airports to the gateway) are in late development and early test; they’ll ship as soon as they are ready, but don’t require an X-Plane update.
  • Once the Airport Gateway is live, we’ll gather up all of the airports users have shared with us since X-Plane 10.25.  We’ll include those airports in an X-Plane patch whenever they’re ready – if that’s after 10.30 we can do a small update to push out airports very easily.

Put another way, X-Plane 10.30 is mainly about code changes; if the various art asset and data updates become available early enough, they’ll go into 10.30 but if they don’t, we’ll do a 10.35 or some other small patch to get them to you as soon as we can.

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.

73 comments on “The What And When of X-Plane 10.30”

  1. Excellent news, thanks for keeping us up to date with infos! I’d prefer your vision with releasing a (most-)bug less version ^^

    Keep on that good work.
    cheers
    blacky

  2. Thanks for the update !

    I prefer “let’s get people the new GPS ASAP.” Bugs can take forever to fix….

    Is there anything new with the flight model ? Rumor was Austin was looking into the left turning tendencies.

    Regards….

        1. From the commit log:

          planes used to lean off to the right ever so slightly.
          it turned out this was due to an error in the computation of flow along the spar direction in cases where wings had dihedral.
          some component of this lateral flow took an axial component after sweep was applied, so the right wings were moving slightly slower than they should have been
          the effect was a fraction of a knot, but till just enough to lean the plane to the right a hair.
          that is now fixed!

          1. When I say left turning tendencies, I am thinking of spiraling slip stream, torque, p-factor. A example would be the c-172 at climb out, it should yaw to the left instead of rolling to the left like it does now. The inclinometor does not register any yaw movement at climb out.

          2. You’d have to ask Austin about the details. I merely posted what he wrote for the release notes.
            Speaking of the turn coordinator though, there’s also an improvement on that instrument. It used to indicate only yaw rate (like a turn INDICATOR) and now it correctly shows a blend of bank rate and yaw rate (like a real turn COORDINATOR) due to the gyro axis mounted in an angle.

  3. Damn. Was looking forward to a (quote) “Mega list of new features heading your way shortly”

  4. Guess this one is for Phillip as a OR kit 1 developer I am exited to see a full support on x-plane, but how bad would you say the motion sickness effect is in x-plane?

    1. It’s an extremely subjective thing. At the Aerosoft conference there were only two responses to trying X-Plane with the Oculus. Either “oh my god, this is awesome” or “oh my god I need to puke – do you have an air sick bag ready?”. From my experience, it depends more on the person than the software. And, I hate to say that, but apparently the older you are the more susceptible to motion sickness you are (completely unscientific statement after observing people of different ages try it).

      1. Thanks Phillip, I belive it is reduced with the new glasses (1080) in Devkit2, but I do hope they can remedy this in the future for I do see the huge potential and added realism.

      2. Hope you will include the OR support as I have just ordered the new DevKit2…

        henrik

  5. This one is for Ben

    Would 10.30 or later issues tacle the nob turning movement, so that we can use i.e the mouse wheel? This is a feature that I know the community is eager to have and I do not remember reading about it in your blog.

    1. I’m pretty sure the manipulation of controls is like that because XP supports multiple platforms and the mouse wheel is more of a PC only thing.

  6. Thank you for the update, Ben!
    Which OpenGL version will be used in 10.30?
    Best regards Angelo

    1. X-Plane 10 requires OpenGL 2.0 or higher, and 10.30 is no different.

      The main difference is that 10.30 uses significantly -less- of the code that was removed from the core in GL 3.1. For example, Core GL 3 removes the built-in transform stack; X-Plane 10.30 could use the transform stack (since we use GL 2.0) but we don’t. So we’re somewhere between 50% and 75% of the way toward being ‘core GL 3 ready’ (which basically means not using stuff that is dropped).

      At this point we’ve dropped the named attributes, the transform stack, and immediate mode. I think the only things remaining that we won’t get to in 10.30 is use of built-in state for tex-gen coefficients and some lighting parameters. (That we still use these is slightly silly as we’re running 100% on shaders in 10.30, never on fixed-function.)

      One more note: because the GL context is from GL 2.0, plugins are able to use glBegin and other stuff; just because we dropped it doesn’t mean they have to. The 10.30 code does some sync for plugins, e.g. we push our transform stack over to the built-in one before plugin calls.

      In the long term, X-Plane may have a core-only profile; in this config X-Plane will maintain a second, older non-core profile for plugin support.

      Because plugins will, over time, be running more and more in a ‘sandbox’ environment, it’s important that they not rely on behavior that’s not officially supported that comes from being in X-Plane’s context.

      One last note: OpenGL 2.0 is our _minimum_ version; we pick off OpenGL 3.x and 4.x features via the OpenGL extension system where available, so it’s definitely worth it to have a DX11/GL4.x-class GPU. For example, we pick up hardware instancing via an extension.

      1. I didn’t notice your last note before: when you say “we pick up hardware instancing via an extension” you mean that you do it right now (now = 10.30) or it’s one of the features planned for a future (10.3x) update?

          1. Was totally unaware about that, even reading a lot of forums I don’t recall anyone writing about it but I remember well various posts about XP10 using OpenGL version not greater than 2.x, this is the reason I asked which version will be used in 10.30, bad assumption I’d say.
            Is hardware instancing explained anywhere into the blog?

          2. I found this:
            http:/2012/03/whats-new-in-objects/
            there isn’t a ton else written on it. The OBJ spec does mention it partly but is a bit incomplete.

            It looks like I never wrote an article that shouted really loud about how we were using hardware instancing, but it’s been in since 10.00 – it’s one of the reasons why the autogen can draw so much ‘stuff’.

      2. Hi Ben,

        What do you call : “the transform stack”, what’s in there ?

        PhM

        1. The transform stack is the set of matrix stacks applied to vertices in the fixed function pipeline: the modelview matrix stack, the projection matrix stack, and some big pile of texture coordinate matrix stacks.

          1. Ok, I am used to the openGL terminology of “matrix stacks” so I thought this was some software layer on your side. Good then I guess we won’t see any of these lengthy glPushMatrix, glRotatef, …, glTranslatef, … , glGetFloatv, glPopMatrix sequences any more, and that all this will be managed outside of the openGL path.

            PhM

          2. There should be _no_ calls to glGet to access the current transform state anymore…since it’s all inside X-plane, we know what we did.

            Plugins still have to call glGet – I have some notes to provide dataref access to transform so plugins don’t have to do that, as it stalls the driver threads.

            Finally, just because you don’t see transform stack actions in a GL profiler doesn’t mean they’re not happening, and frankly I’m not sure they’re as expensive as you might think, relative to the amount of work they are doing.

    1. No change to the AI, and not much for ATC. We were hoping to have ATC fixes in 1030 but we do not (except for my fix to planes starting up on top of each other).

      This is one of the reasons why I don’t like to pre-announce stuff…we had a solid plan in place to get ATC fixes into 1030 – that plan then totally face-planted for unexpected reasons; all predictions about development over long time periods have huge error bars. Had I posted “we’re going to have all the worst ATC bugs fixed by 1030” we’d be setting up users for disappointment.

  8. I vote for inclusion of Oculus Rift support! I have pre-ordered DK2 pretty much just for use in X-Plane, I kid you not.
    I will happily put up with any interface bugs and other quirks (as I assume most everyone will) simply based on the experimental nature of the Rift. I don’t think anyone expects perfection right from the get-go.

    1. I second Shawn, another vote from me,

      I was so disappointed to read the comment that you may hold this back 🙁

      I have an Oculus Rift DK1 and simply can’t wait for X-Plane to support it, unfinished interface whatever, so long as the actual flying works I’m happy, you can always take the headset off to fiddle with menus and options.

      Please, please leave it in even if unfinished . . . .

    1. What about it? It’s working great for me, apart from the terrible Ubuntu/ATI driver mess. As long as you stay with 12.04 LTS before ATI has sorted their mess out, you should be fine.

    2. The same here … working like a charm since many years (since XP8 😉 that is). Only difference to Philipp is that I am a long time OpenSUSE user and always stayed with NVidia (which nowadays makes for a quite smooth driver experience).

  10. Are cloud improvements considered a “fog-related feature” and thus not in the initial 10.30 release?

  11. Speaking ’bout performance… I’ve bought I quite heavy PC config. On heavy scenery, CPU shows up to 40% of use (i74820K), GPU 30% (GTXTitanBlack)… I’ve red somewhere a post from you, saying that by examples number of objects are BUS (=FSB i guess) heavy. Is there anything done about performance tuning? BUS is a bottleneck on today’s machinery…

    TIA
    best reagards
    blacky

    1. It’s probably not the bus on a PC – that tends to be an issue with OSX ATI drivers only. Perf tuning is _not_ a primary focus of 1030 but it’s possible that perf will be better due to GL changes. We’re aiming for “not worse”.

      1. ‘not worse’… is always a good answer 🙂 Thanks for your fast feedback 🙂 I hope the performance will be revised a day, cause it’s a pain, when fully loaded ^^

        Cheers

  12. And how about the Rio de Janeiro mesh? I read in the .org that there is a fixed version with Lamiar, but not commited to the users. Will it be updated in 10.30?

    1. No – as I said in the original post, DSF recuts are -not- part of 10.30 – like other art stuff we’ll get them released when we can.

  13. Can you give some indication as to how the graphics on the Occulus Rift are derived? If you have a beefy computer with a high end graphics card which shows X-plane at maximum prettiness on the PC screen, that will translate into the same beauty in the OR? Or does the OR do any of the GPU stuff independently?

    In other words, if I am thinking about a computer upgrade in the next year or so, is it worth delaying to see how the OR performs with my current, more limited rig? (On the assumption that you guys will work out ways of fixing the interface issues and OR will become the preferred method of experiencing X-plane)

    Thanks.

    1. Philipp will have to comment in more detail, but I can answer a few questions about the nature of pretty much all 3-d systems and X-Plane:

      1. The OR does not have its own GPU and thus does not take any ‘load’ off of X-Plane and your regular hardware. To the hardware of your PC, the OR is just a monitor (with the odd property of half the monitor being pointed directly into each eye :-).

      2. The current OR is rather low res by PC gaming standards – the original dev kit is 640 x 800 x 2, which is not a lot more pixels than X-Plane on default res…so you’d be unlikely to have to turn down GPU eye candy (HDR, scattering) due to the OR. Wikipedia claims dev kit 2 will be 960 x 1080 x 2 and who knows for the consumer version…but even then, 1920 x 1080p is _not_ killer res by X-Plane standards…users who go nuts sometimes have 2 or 3 2560 x 1440 monitors.

      (Philipp does run X-plane in slightly higher res than the actual OR to get better quality when the lens correction is applied, but that’s not going to tank your fps.)

      3. The real ‘hit’ is doing two eyes – each eye gets a structurally different image – the camera is shifted by the distance between your eyes, all parallax must be recomputed, and the result is 2x the CPU cost of pushing a scene.

      So if you are not held up on fill rate and you’re not using shadows or water reflections, the OR is going to come pretty close to cutting your effective framerate in half. (If you are running shadows, heavy reflections, you’re fill rate bound, or the flight model or panel are taking CPU time, the ‘cost’ of the second eye becomes considerably less.

      Unfortunately I don’t think that gives you much to go on re: performance, except to say that I would expect the OR to need more CPU, not more GPU.

      1. It might not work with the OR (and not even make sense due to its low res), but with standard multi-monitor setups, the parallax compensation can be done at a low performance cost by just running a second instance of X-Plane on the same computer with the shifted viewpoint settings. On my setup (3930K OC’d@4.2GHz and an R9 290X) I can run two 1920×1080 screens at high 30fps with most of my settings maximized (tree hugger, tons of objects, nighest texture settings, global shadows low, HDR@FXAA). Compare that to the same computer running at 3840×1080 (EyeFinity), which could barely go beyond high-teens and would give terrible distortion at the edges…

        So it seems to me that with a high end video card and relatively fast processor, X-Plane is mostly bound by the clock speed of a single core…

        1. Right – and this gets into a fundamental architectural problem of today’s computers and OpenGL (DX has this problem too): there isn’t a great model to express parallel rendering with parallel hardware.

          Going multi-process may potentially help, except the driver is time-slicing multiple applications -and- the entire working set of app data has to be duplicated, which is wasteful of RAM.

          Plus there may be latency between the two processes!

          1. Thanks for that, Ben. Very helpful.

            I’m not sure I understood much of the follow-up comment, but I have every trust that you guys will make the right decisions as to how best to do these things!

  15. Philip, I mean voice engine support in x-plane linux to hear atc voices. Also, I want hear anything about dynamic clouds and traffic aircraft sounds

  16. What about water areas updates? Is there a way to get a .gdb or a .shp file to you so you can implement the data? The amount of seaplane bases with out the lake is just ridiculous. And the inability for the user to add their own water data is even more ridiculous.

    1. That’ll be a DSF update; as I said in the post, DSF updates are separate from 1030, and I don’t know exactly when I’ll ship them.

      We get our water data strictly from OSM, so the thing you can do is:
      1. Check OSM now.
      2. _If_ the lake you are looking for is not on OSM now, you can import or draw the data into OSM.

      If the lake is already in OSM then we’ll get it from OSM directly.

    2. Do you know my side project (side project, because lots of the basics comes from my work for Laminar on the Global Scenery) at http://www.alpilotx.net? There you can have for example the “HD mesh Scenery v2”, which (for Europe and North America) includes updated OSM data too … with a little luck, it already might (not guaranteed – it depends on OSM as Ben pointed out!!!!) have your lakes in it. You can find much more info about it here:
      http://www.alpilotx.net/downloads/x-plane-10-hd-scenery-mesh-v2/

  17. Pingback: X-Plane 10.30 im Anflug... - simflight DE - Simulations Nachrichten & Rezensionen

  18. You mention new dataref-based interfaces to customize sim behavior, is it mainly graphic tweaks ala Raleigh?

    1. No. We will have new official datarefs for some sim controls – I’ll post a real list when the beta goes public.

      Poking the art controls (E.g. raleigh) is unofficial; we don’t intentionally add art controls for third parties, we make them for our own use.

      1. I love x-plane and greatly appreciate your efforts in making it THE best flight sim available. So in this context, I respectfully ask this question:

        Why are the art controls for internal use only? Since Raleigh hit the forums, there has been a huge amount of positive interest and a great deal of excitement about the visuals. I can’t remember anything that has generated that kind of excitement.

        I think many users are asking this question, if they have seen the visual enhancement it brings.

        Again, I ask this from a respectful position.

        1. Hi Mike,

          It’s a good question – hold that thought for maybe 12 hours…I just finished writing a blog post that covers the topic in some depth.

  20. Hi Ben!
    Any chance to get the atomospheric scattering tuning you mentioned with some other users in an earlier post?
    Or will we have to do it and experiment it ourselves as described then?
    Which is not very practical…

    Cheers.
    Dave.

    1. I don’t know – it depends on when it is done. If it is done and we come up with something we can include, we will – if not, it will have to wait.

  21. That is good news!
    I glad to know that soon, the topic of fog and clouds entrance and exits will be fix, merged with all anothers points will make better and better XP.
    Thanks guys needed to know something.
    Cheers!

  22. Hi Ben,

    Are there provisions in 10.30 to hide the playback menu in replay mode? More panning and camera options would be a plus. I think good quality videos of X-Plane promote sales.

  24. Pingback: What to expect from X-Plane 10.30 - The X-Plane developers blog gives an overview of what to expect from the next X-Plane 10.30 upgrade. One of the big new features is the new GPS Navigator.

  25. Hello to all, before I ask for an improvement in 10.30 I like to ask if someone also observed this behaviour in cloud drawing-sequence?
    Currently clouds seem to be grouped in banks, each bank about 5 x 5 miles in size.
    The banks are drawn complete one after the other, the most far bank first, the nearest last.
    But the distance seems to be measured from bank center point perpendicular to the projection plane.
    It happens that the center point of the bank near to me is perpendicular more far away to the projection plane than the center point of the bank beside me.
    In this case the bank beside me is drawn last. Even if a single puff in the bank close to me is nearer to me, it might be covered by the puffs of the bank beside.
    At certain viewing angles the edge of the neighboring cloud-bank pops up where it shouldn’t do so.
    I have build 102503 64bit not modified
    This is my first XP post at all, if it is in the wrong address just push or kick it.
    Thank you very much, Yours,
    VCV

    1. I think what you are seeing is: the clouds are sorted in a two-level process, with outer buckets that are then internally sorted. But the puffs must remain in their bucket. I need to investigate why this causes weird lighting queues…

        1. Yep – there’s one extra gotcha: the clouds are built around the aircraft, so the more you go AWAY from your aircraft the WEIRDER things get. We don’t try to update with the camera because you can move the camera REALLY fast and the async threaded cloud system would not be able to keep up.

          1. I only did external view to easier set view direction. Also and even more in cockpit view the effect is seen while yawing around headings 0, 90, 180 or 270 deg like in this
            http://www.youtube.com/watch?v=L3iqEU5WJkk

            I only mentioned to keep the chance for a slight improvement one time… . No need to take your time now.
            Yours sincerely

  26. Please Ben, solve the white out bug whenever plane is going into the clouds, it’s one of the “best” bugs of this sim. Thx.

    1. Hi Tinamus,

      Sorry, but did you read the Blog post above? I mean really, there is a line which says : “Tuning and improvements to the look of the clouds, including their behavior as you fly into and out of them.” … and the second part of the sentence is about your request!

Comments are closed.