Category: Development

X-Plane 11.30 Public Beta: Are We There Yet?

Almost! we’ve been running a small scale private beta for the last few weeks while we finish new features and fix major bugs. I don’t want to curse the beta, but it looks like we may be able to get the public beta posted this weekend.

In the last two days we’ve had two major show-stopping bugs, but both are fixed, so we’re going to keep trying to nail this thing down and get it posted.

The public beta features not only the new particle system, available to third parties, but it is now in use for most (but not all) of the built-in effects in the sim. New Plane-Maker options let authors specify which effect categories (e.g. engine effects, wheel effects, etc.) they want to replace.

At this point it looks like we won’t have anything public for Vulkan this year, although I do think we will hit some internal milestones.

Posted in Development, News by | 158 Comments

4K Panels and Cockpit Objects in 11.30

A quick note on 11.30: we have an internal build of 11.30 that seems to be working and we’ll be rolling out private betas next week, as soon as we get menu items for the particle system editor. Once we get some feedback on the private beta we’ll know if we’re close to public beta or not.

Two new feature for aircraft authors coming in 11.30:

4K Panels. I do not promise that this is going to have good performance, so try it and go back to 2K if things get slow, but in X-Plane 11.30 you can use a 4K texture for your panel. This is mostly useful for aircraft that are generating a lot of plugin-based dynamic texture effects.

Cockpit Objects. Before X-Plane 11.30 the cockpit object is a magical object found by file name (aircraft name_cockpit.obj). In X-Plane 11.30 the cockpit object is just one among many “misc” objects in Plane-Maker, with the “cockpit object” check-box set.

X-Plane and Plane-Maker will automatically upgrade/interpret old planes, so there’s no “todo” here or compatibility loss.

This feature means that, starting with 11.30, you can now share a single cockpit object amongst multiple .acf files in the same folder. This means you can create multiple editions of your aircraft (e.g. for engine types) and not have to duplicate your cockpit .obj files.

Update: just to clarify something that a number of authors asked about, you cannot have multiple cockpit objects under the new system. You are still required to put all of your manipulators and camera-stopping surfaces in a single cockpit object. Now you have complete control over which object that is. (Panel texture may be used in any aircraft-attached object; this is true for all of X-Plane 11 and some X-Plane 10 versions.)

Posted in Aircraft & Modeling, Development by | 38 Comments

Austin and Ben, to Scale

Those who know Austin know that he is really tall. It’s a running joke that at company events, he ends up half a mile ahead of the group because each of his steps is quite a bit longer than the rest of ours. If he and I want to see eye-to-eye on something, I literally need a step stool.

But for those who haven’t run into him at a convention or event, this picture should put things into perspective.

Posted in Development by | 32 Comments

Nvidia RTX ends with an X, X-Plane starts with one. Perfect match?

Nvidia announced their latest bitcoin graphics cards on August 20th at Gamescom this year. Among the usual increase in transistors, they also disappointed all crypto miners by adding a feature that cannot (yet) be used to calculate cryptographic hashes: Ray Tracing! Ray tracing has long been seen as somewhat of a holy grail of graphics rendering, because it’s much closer to replicating the real world than traditional rasterization and shading. However, doing ray tracing in real time has been close to impossible so far. But hey, Nvidia just announced their new RTX GPUs that can do it, so when is X-Plane going to get a fancy ray traced renderer? This and various other questions that have been asked by X-Plane users, as well as some myths, shall be answered! If you have a question that isn’t answered here, feel free to ask it in the comments.

What Nvidia has shown is absolutely impressive. Unfortunately, the fine print of all the marketing hype is that sadly it can’t just be thrown in without engineering effort. The first thing needed is actual RTX hardware, which no one at LR currently has. The second thing needed is a Vulkan-based app; we are getting there, but not in any way that would support RTX. (the whole goal of the Vulkan renderer is to not change the way the world looks, so we’ll first need a shipping production Vulkan renderer.) But then… well, it’s not entirely clear what it takes to actually write a ray traced renderer in all of its details. Nvidia has not yet published the specification for the Vulkan extension (VK_NV_raytracing), but they have published slides from presentations. One thing is very clear: you can’t just copy and paste five lines of Nvidia sample code and suddenly wake up in a ray traced world.

What Nvidia provides is the scaffolding necessary to describe a scene, as well as to provide new types of shaders that allow casting rays from point A to point B and then report back what they hit along the way. This is a huge amount of work that the hardware is providing here, but it’s not the promised “5 lines and you’ll have ray tracing in your application” that’s being promised. To adopt ray tracing you will have to write the whole ray tracer yourself, from scratch; the hardware just enables you to do so now. This is akin to implementing HDR or PBR: Shaders are the base requirement to implement both of these, but once you have shaders you still need to actually implement HDR or PBR on top of them. Another example is building a house and being provided a plot of land that can support it. Sure, it’s great, now you have a place to build your house, but you still have to come up with a blueprint, pick materials to use and then actually build the thing. Implementing ray tracing will take a great amount of engineering effort, nobody is throwing in awesome reflections with every purchase of one RTX2080Ti for free!

The other thing that’s not entirely clear is how well ray tracing will even perform in an environment like X-Plane! Worlds in X-Plane are huge and open, not small scenes from a shooter with tight spacing. Lot’s of rays are needed, and they have to travel quite far, potentially intersecting with large amounts of geometry. How good does the hardware and API scale up to these sizes? Only time will tell. That’s of course not to diminish Nvidias achievement here, it’s an incredible feat of technology in its own right and this is just the first generation!

The other thing worth mentioning is that ray tracing is not just something that Nvidia secretly cooked up in their basement for a decade. This is going to be an industry wide thing, with APIs that will work across vendors! Historically one vendor has come out with a fancy new way to do things which then became the standard adopted by other vendors. Nvidia has come forward and offered their extension as base for a core Khronos extension for Vulkan. They have a vested interested in making a cross vendor, cross platform API available.

In the foreseeable future, rasterizing renderers are unlikely to go anywhere. Rather, ray tracing for the time being can be used for additional effects that are otherwise hard to achieve. Clearly Nvidia is acknowledging this as well by providing a traditional rasterization engine that by itself is more powerful than previous generation ones. This also means that if X-Plane were to adopt ray tracing tomorrow, you could still run it on your old hardware, you’d just get extra shiny on top if you have ray tracing capable hardware.

Last but not least, this is another reason why you should stay away from the shaders! One day we’ll wake up in the glorious Vulkan future which will open the door to the glorious ray tracing future. All of this means that we’ll have to keep changing our shaders.

Posted in Development, Hardware by | 43 Comments

Art Controls Are For Hacking

Sidney posted a detailed write-up a few days ago as to why developing an add-on by modifying our shaders is not a good idea. The short version is that, like art controls, the shaders are an internal part of X-Plane that we don’t lock up so you can see them and muck around with them. But there is no stability, documentation, or any attempt to make them useful the way the plugin system is.

This confused a number of commenters. Do we want you to use them or not?

To resolve the mixed messages, Sidney created this fantastic flow-chart.

Hopefully that clarifies where the line in the sand is between “I was poking around” and “I made a serious add-on”. Pretty much everything here goes for the shaders as well as the art controls, only more so.

Posted in Development by | 24 Comments

Our shaders don’t like to be touched

X-Plane has always shipped with the shaders visible to everyone as plain text in the Resources/shader directory. Partly this was due to making it convenient to load the shaders into OpenGL itself, but we also don’t have anything to hide there either so it doesn’t make much sense to try to hide them. You are more than welcome to look and poke at our shaders and if you learn something about X-Plane in the process, that’s awesome!

However, the one big caveat to that is that we never considered the shaders to be part of the publicly accessible interface and they are in no way stable across versions. X-Plane is an actively developed product and we are making a lot of changes to the codebase, including the shaders, so you should never ever distribute a plugin or tool that modifies the shaders. Since we give no guarantee that our shaders will remain stable across versions, you’ll always be left worrying that we might break your add-on.

Additionally, there is a big change to the shader system coming in 11.30 that will definitely break all existing plugins that are modifying shaders. This blog post will cover the upcoming changes and hopefully convince everyone that the shader system is in flux and not to be relied upon as a basis for add-ons. Read More

Posted in Development, Plugins by | 30 Comments

XPlane2Blender v3.5.0-beta.2 is out!

This beta brings in many new bug fixes and heavily requested new features! As with any beta, be aware that this could break your project SO MAKE BACKUPS! We don’t think there are any drastic changes to the data model, but, better safe than sorry.

Bug Fixes

  • #355 – A small UI fix relating to too many manipulator fields being shown
  • #360 – A bug fix for Drag Rotate manipulators giving false negatives
  • #353, #363, and #260 – All relate to warning people and correct what was allowed with NORMAL_METALNESS and BLEND_GLASS. Previously Blend Glass was in the same drop down menu as Alpha Blend, Alpha Cutoff, and Alpha Shadow. Now it is a checkbox allowing you to correctly specify a Blend Mode and apply Blend Glass to it. Existing materials with Blend Glass will see this new checkbox automatically checked. Blend Mode will be set to Alpha Blend or, if your plane is old enough to have been worked on during X-Plane 10, it will be set to whatever it was back then.
    3_5_0_beta_2_blend_glass_checkbox

See the internal text block “Updater Log” for a list of what got updated, including this. You may see, for example:
INFO: Set material "Material_SHADOW_BLEND_GLASS"'s Blend Glass property to true and its Blend Mode to Shadow

  • #366 – An Optimization! Useless transitions in the OBJ were being written, now they’re not. Custom Properties still work, there won’t be any visual changes to your OBJ. We haven’t done any profiling but it might have decreased OBJ loading time by a small amount too.

Features

Command Search Window

Thanks to #361, just like the Datarefs.txt Search Window, we now have the same capabilities for searching Commands.txt (for manipulators). We are shipping with X-Plane’s latest Commands.txt file, but of course you can replace it with your own (as long as you keep the name the same). One day we hope to make it much more flexible.
3_5_0_beta_2_command_search_window

Particle Emitters (not very useful to most yet, I know)

Thanks to #358, some people who have access to X-Plane’s cutting edge particle code can use XPlane2Blender to specify particle emitters. Don’t worry, we’re all working as hard as we can to get these into the hands of others. Fortunately, XPlane2Blender users can hit the ground running the minute it drops!
3_5_0_beta_2_particle_screenshot

Build Scripts And Test Runners

  • #302 and #307 – Are you a professional XPlane2Blender maintainer and developer (if so we should probably talk!) Then you need a better build script, and a test script to match! Introducing mkbuild.py, the build script for the modern developer! It creates, it tests, it renames without messy mistake prone human intervention! To top that off, how about a testing script that doesn’t give false positives!
Posted in Aircraft, Aircraft & Modeling, Cockpits, Development, Modeling, Panels by | 8 Comments

X-Plane Live TODAY

A quick correction – the X-Plane Live session will actually be today, Tuesday at 4 pm (20:00 UTC) – I apologize for the total confusion and chaos on this one.  We have your questions from the developer blog and social media, and we’ll try to take live questions as best we can.

EDIT: T-minus 30 minutes to live stream! We’ll be live here on YouTube.

EDIT 2: If you missed the live stream, you can watch the recording: Part 1 and Part 2 (split due to technical difficulties).

Posted in Development, News by | 30 Comments

FlightSimExpo 2018 Slide Deck

I meant to post this weeks ago, and basically just lost track of it, so thanks for the reminders in the comment sections.  Here is a PDF export of our slide deck from FSExpo.

Flight Sim Expo 2018 Slide Deck

There is professionally shot video of the event, but it wasn’t shot by us, and I’m afraid I have no idea when it will be posted. We’re looking into using our own cameras next year so that we can ensure a video post on a more timely basis.

 

Posted in Development by | 24 Comments