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

First, X-Plane 10.45 release candidate 2 is out. There was a bug in RC1 where the instructor’s operator station (IOS) couldn’t change aircraft over the network. I’m hoping we don’t have any other last-minute fire-drills; the IOS bug was reported the day I was going to call RC1 final.

I keep on telling myself during the day “I’ll blog some developer news later when I’m too tired to code” and (shockingly) at 10 pm, after the second round of coding after the kids have gone to bed, I find myself too tired and go “meh, I’ll blog tomorrow.”

So in an attempt to post something rather than keep delaying…

Spock And Friends

The Vulkan API was released today. Vulkan is the third new next generation 3-d graphics API (the other two are Metal for OS X and iOS and DirectX 12 for Windows). Vulkan should be available on Windows, Linux and Android devices. The specification is 651 pages long, so I have some light reading to do.

Faster Cockpit Lights

FlightFactor sent me a test case to look at a while ago – a possible bug in the Blender 2.49 exporter. While exploring the performance of the test case, I discovered that the code that runs ATTR_lit_level in a cockpit OBJ was a lot less performant. (If you don’t create 3-d cockpits, ATTR_lit_level lets you turn the brightness of a 3-d model’s night texture up and down based on a dataref; it is crucial for creating cockpit lighting animations, including annunciators.)

I ripped out a pretty huge pile of code in the process, and I am hoping we’ll see a performance boost. On the mobile product (this code is shared on mobile and desktop) the changes cut the number of driver calls we make down by about 25%. (That doesn’t mean a 25% speed-up – not all calls are equal, but it shows that there was a real win in there.) My measurements of the ATTR_lit_level test case run the OBJ itself 10x faster. (Again, that doesn’t mean 10x the framerate – it means this one very small part of X-Plane runs 10x faster).  Once the work is done I’ll post some performance numbers.  This code is targeted at X-Plane 10.50.

 

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.

24 comments on “X-Plane 10.45 RC2 is Out (and Other Nerdy Stuff)”

  1. early tests are showing Vulkan to be much slower then predicted…. slower then DX11 even and no Apple support

    1. I’m not surprised – it’s been out for less than 24 hours. The DX11 drivers have been out forever and have been tuned within an inch of their lives.

      An Apples to Apples test between a long-shipping tuned driver and a brand new one – I know who will win.

      Any comparison of the two is also potentially a strange comparison – the whole point of Vulkan, Metal and DX12 is to make programs faster by doing things that are -illegal- in DX11. These APIs will be faster when engine and game devs start doing the things we can’t do now in GL/Vulkan.

      And no – no Apple support – I’d be surprised if there ever is.

      1. well thats the thing Vulkan works at a low level there isnt much to the drivers to change or fix

        and Metal is still missing a lot of advanced features

        kinda silly Apple wont even support newer OpenGL versions

        1. OpenGL supports newer GL versions than we use – the real issue is that they don’t support ARB compatibility, so for example we can’t run plugins + x-plane in a modern context.

          1. Frontier had an issue where they needed Compute Shaders for Elite which the current ver of OGL on OS X does not support (amusingly if they would just move up 1 point release it wouldnt be an issue)

      1. the one upside is Vulkan is faster then current OGL
        and adding is trivial if the guys that made Talos Principle are to be believed

        they added it in to there game in weeks

        so in theory it could be put in to XP10 easily

  3. So Vulcan API Ben, will that mean tessellation ability or even a step forward to this? How do GLSL work with X-Plane, any performance gain here or new features such as weather physics, lighting etc.? Since Vulcan is better suited for memory allocation and you get direct GPU control, what gain would you say this will have for X-Plane?

    Thanks for answering Ben, i guess you need to read up, but perhaps you know something already you want to share?

    And oh yea, ps…
    Any tip on a good approach for getting lights on buildings made in 3dsmax and imported into AC3D? Do X-Plane make use of night textures, or can you implement lights via the x-plane plugin in AC3D?

    Thank you for blogging!

    1. Tessellation is already available in OpenGL.

      The potential performance wins of the new APIs (these apply to Vulkan, DX12, and mostly to Metal) are:
      – A better threading model means we can write multi-core code in places we cannot with OpenGL.
      – Lower overhead because the API fits the hardware better.
      – More predictable, less stuttery performance because the API makes clear what APIs are fast and what ones are slow. Slow APIs can be put on other cores.

      Re: ac3d – I cannot recommend such a technique. My suggestion is to use the new Blender 2.7 script when it comes out and go from 3DS to Blender 2.7.

      I am not planning on shipping any new features for the ac3d plugin at this time.

  4. Considering that none of the next-gen APIs will support all of OS X, iOS, Windows, Linux and Android, which platforms are you planning to abandon? Or are you going to choose both Metal and Vulkan in order to retain all platforms?

    P.S. The OBJ8 spec says that a texture_nowrap command can be applied to the draped geometry of an OBJ, but how are we supposed to do this? TEXTURE_NOWRAP_DRAPED does not work.

    Also, any chance of this being fixed in the next update?
    http://forums.x-plane.org/index.php?showtopic=80400

    1. Re: APIs – we’re going to have to be multi-API (e.g. Metal + Vulkan is complete coverage) and we need to be multi-API to not drop GL as a fallback.

      Re: OBJ8 spec, please file a bug with a sample object and the URL of the spec where it says that should work, so we can fix spec typos.

      Re: draped geometry being cut off at the DSF boundary, this isn’t going to be fixed any time soon – it’s sort of a stupid design limit of the draping system. 🙁

      If the object is draped only, you can work around this by manually inserting it into both DSFs – as of 10.20 the DSF can have slightly-out-of-bounds OBJ origins, which makes this “legal”.

      Better is to use draped polygons and cut them to exact lat/lon boundaries, particularly if you’re going to work over a huge area.

      1. that worries me

        you guys need to think long and hard about not dropping Apple
        i get thats what you guys like but Apple REALLY IS holding the sim back do to both hardware and software choices

        Apple really isnt in the consumer performance market any more sure the Mac Pro kinda can keep up but all the consumer level stuff is running on laptop hardware

        and i have not heard good things about Metal most its missing things that both DX12 and Vulkan have

        considering that Apple users can easily install Linux or Windows seems silly to keep spending time and money OS X for what ever comes next

        Frontier had to make the same call with Elite and Apple has made it clear to Occulus that they dont really care about high end consumer computing

      2. Hi ben,

        Thanks for the reply. Before I file a bug, could you confirm that this is indeed a typo? The OBJ8 spec at http://developer.x-plane.com/?article=obj8-file-format-specification says: “OBJs support all of the standard shader features, for use in the draped texture: TEXTURE, TEXTURE_NOWRAP, TEXTURE_LIT, …”. However, it doesn’t tell us how to invoke these commands for the draped texture.

        I found out from a post on X-Plane.org that the command to invoke a basic texture for draped geometry is TEXTURE_DRAPED, but couldn’t find anything on how to invoke a nowrap texture for it. So I guessed commands like TEXTURE_NOWRAP_DRAPED and TEXTURE_DRAPED_NOWRAP but nothing worked. Does a command for using a nowrap texture with draped OBJ geometry actually exist?

        RE: Draped geometry being cut off: Yes, the OBJ contains only a draped orthoimagery tile (4 vertices). I tried manually inserting the OBJ into the other tile (+32-097) but DSFTool throws me:

        ERROR: could not place object -97.048995, 32.887478
        ERROR: !”ERROR: could not place object.\n”
        (..\..\src\DSF\DSFLibWrite.cpp, 1449.)

        I guess I’m placing it too-out-of-bounds?

        The reason I’m not using POLs is to avoid this: http://gatewaybugs.x-plane.com/browse/WED-525
        By creating everything in Blender and then simply placing it at a single origin in WED, I can rest assured that everything is perfectly aligned in X-Plane and I do not have to use trial and error to align OBJs with POLs.

        1. I’ll try to reply to the bug filed soon…the short:
          1. TEXTURE_NOWRAP should work as your draped texture; file a bug if it doesn’t.
          2. Registration of OBJ centers with polygons should be very precise. If it isn’t, I’d like a bug report. I recommend using wind socks as ‘pins’ to test the registration of any given point and the four corners. When doing this, make sure the airport height listed matches the DSF terrain you are overlaying for correct results.

          1. Hi Ben, I have just finished filing 3 bug reports:

            1. I just realized that TEXTURE_NOWRAP isn’t working with any OBJs at all; no matter if they’re draped or undraped. It just returns a solid gray model.

            2. Registration of OBJ centers/origins with POLs is indeed very precise, but the precision decreases with distance from the origin. Even at 300m away, the inaccuracy is enough to potentially require trial-and-error placement in WED for objects that must align to each other. At 3,350m away, the inaccuracy is just massive. It seems that OBJs are uniformly scaled down towards the origin in X-Plane–check the bug report.

            3. The third bug report was for the OBJ8 specification not containing the commands relevant to a separate texture for draped geometry, e.g., TEXTURE_DRAPED.

          2. Thanks for filing the bugs. I fear that what you may need to change your work-flow. Basically you want to never try to get precise alignment at a long arm from an OBJ.

  5. Ben hello, can we expect in the version 10.50 of the Earth’s surface the implementation of the landscape in line with the seasons in the territory, such as a full-fledged winter, autumn or spring, and the year-round green trees in sub-zero temperatures in the winter for example in the Siberian cities, everything around is green.
    Kirill Bondarev.

  6. Hi Ben,

    It’s really interesting to see what stuff you are cheking out for x-plane future!

    A while ago you talked about Physically Based Rendering , could you please elaborate more about it in another post?

  7. Hi,

    I don’t want to be bad but before to move to other api or upgrade 3d models engine or similar, why don’t improve the features that , now, are bottlenacked of XP?
    I prefer to have 10 or more cloud layers, seasonals textures,weather injector that works well and permit to flight into a cloud system and not pass from sun to rain in a bit, theese are the elements the feel XP closely to real.
    I believe that should be fix all the actual features, XP has big potentiality but the time run in april will be delivery the new FSX with 64 bit architecture and totaly rewrite in the code with new 3d Engine, i’d lite to see XP as leader on market and not other sim

Comments are closed.