Art controls are internal tuning constants in X-Plane that we put in so that our art team can modify the behavior of X-Plane while they work without having to recompile the sim from source code. We leave them in the final product because they are sometimes useful to third parties, useful for in-field debugging, and because we are generally okay with people hacking the sim if they understand the limitations. X-Plane has always been a relatively open sim to play with and lots of X-Plane authors got their start just poking around. Our first instinct isn’t to encrypt everything.
We don’t go out of our way to break art controls. We don’t go in and change their names in every beta just to mess with third parties. But we also spend absolutely zero time trying to maintain art control compatibility with previous versions of the sim. Backward compatibility takes a lot of planning and effort and there’s just no way we can keep a bunch of internal tweaks the same while modifying the sim.
In X-Plane 11.30, a number of art controls have stopped behaving the way they used to. They aren’t going to go back to the way they were, because we don’t spend time trying to support hacks based on art controls. Here’s what happened and why:
As part of our work to port X-Plane to Vulkan, I rewrote the code that renders a frame in two ways:
- All off-screen rendering needed to draw the frame is now done before the frame is rendered; up to X-Plane 11.25 some of this work was done as a diversion, mid-frame.
- The graphic resources (mostly off-screen rendering buffers in VRAM) are allocated once when the configuration of the sim changes, rather than being allocated “just in time” when we get into a frame and realize something has changed.
Change 1 was needed to match how Vulkan and Metal handle off-screen rendering*; change 2 helps avoid stutters by allocating expensive resources early when we are not flying.
The side effect of this is that art control edits take effect only when the sim is reconsidering its graphic setup anyway (e.g. due to a window size change or rendering setting change); if the art controls change mid-frame, any code that does resource allocation ignores them because it is no longer “sniffing” for configuration changes per-frame. Other code that uses the art controls notices the change, and the result is often haywire drawing due to a half-used art control.
* This was an example of the OpenGL driver doing a lot of work for us, and hurting performance, to support an abstraction that doesn’t make sense. The real graphics card has to do real work when a rendering pass begins and ends; the OpenGL driver automatically synthesizes these rendering passes on the fly for the GPU as the app runs. Because Vulkan/Metal requires that we spell out the passes explicitly, we (the app) know exactly when we are doing something expensive (starting a new rendering pass) and we can minimize the cost.
We’ve been breaking X-Plane apart so we can put it back together with a revised flight model, shaders, joysticks, and particles. All these changes have resulted in some interesting effects at times. Here are some of the best mistakes I’ve seen as we’ve been hammering away at 11.30. Enjoy! Read More
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.
XPlane2Blender is now X-Plane 11.30 ready! Not much has changed since beta.3, just some fixes to the particle stuff.
Bug Fixes
#373 – Test Script’s –filter flags now needs less escaping for its regexes
#377 – Show/Hide animations on empties is now being exported again
#384 – Particle follow non-colocated animations
Sound Emitter has been removed from the Empty Special types menu. One day it will be back in!
As you may have seen on our social media, we have new joystick features coming in the next major update. There are two major features here:
- Custom response curves
- Special (semantic) ranges for certain axis types
The first may be of general interest, while the second is almost exclusively useful to hardware makers and custom cockpit builders.
Custom response curves
For as long as I can remember, X-Plane has had a “control response” setting, which makes your controls respond non-linearly. More of your joystick’s range is mapped to the center of the your pitch/roll/yaw axis’s center, and less of the range is devoted to the extremes. This gives you fine-grained controls in the region where the controls are typically used, at the expense of more coarse controls at the limits.
In X-Plane 11, these settings live in the Control Sensitivity window (launched from the bottom of the Settings > Joystick screen), and they will continue to be there in the 11.30 update.
The problem with the existing control response setting, though, is that it applies to all joystick hardware you might plug in. You get just three values—pitch, roll, and yaw—that apply to every axis of that type, no matter the device. Moreover, if you have a different type of axis whose input you want to curve (e.g., throttle, tiller, etc.), you’re simply out of luck.
So, in 11.30, we’re adding support for setting custom curves on any axis type. When applied to a pitch, roll, or yaw axis, this will override the global control response curve; applied to other axis types, it will support new functionality not previously available.
These curves are incredibly powerful. They can do things like:
- Manually configure a null zone
- Create a smooth curve (a straightforward replacement for the old “control response” setting)
- Create really complex curves, with loads of control points, and your choice of interpolation method (linear, or one of two methods of smoothing)
But the fun doesn’t stop there!
New semantic ranges
There’s a new component to the curve editor that bears calling out explicitly.
When you’re editing a response curve for certain axis types (throttle, prop, or mixture), you’ll have the option of also configuring the ranges for certain axis-specific behaviors:
- Beta & reverse ranges for throttles
- Feather range for prop controls
- Cutoff range for mixture controls
X-Plane has always set these ranges automatically based on the aircraft model you were flying. For the first time, though, you can configure it yourself to match your hardware.
These are aimed primarily at hardware builders who have physical detents on their controls—you can make X-Plane’s idle point exactly match your throttle’s physical detent, for instance. This makes it possible to build really nice throttle-prop-mixture quadrants that play nicely with X-Plane.
If you’re a commercial hardware maker, and you’d like X-Plane to correctly configure your hardware by default for your users, you can set up both the axis & button assignments and the semantic axis ranges from the settings UI, then click the “Create Default Configuration File” button. Send the file it creates to me (my email is my first name at X-Plane.com) and I’ll get it shipping in the next release.
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.)
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.
As you saw at Flightsim Expo, X-Plane 11.30 offers a wide range of new features for airplane authors, who wish to make their airplane engines and systems more realistic. This post links to the documents with technical details that are of interest to aircraft authors mostly. End-users are encouraged to try the Cessna 172, King Air C90 and Boeing 737 of X-Plane 11.30 to experience more fidelity in true-to-life autopilot and other system simulation.
Oxygen System
X-Plane has two separate oxygen systems, bottled/compressed O2 and chemical oxygen that can be used for both general aviation aircraft and airliners with separate crew and pax oxygen. How to set up the system for you airplane is explained here: https:/article/the-x-plane-oxygen-system/
Anti-Ice and De-Ice Systems
Airplanes can make use of electrical or bleed-air thermal anti-ice systems, inflatable boots de-ice or chemical TKS anti-ice systems, each with their own characteristics: https:/article/the-x-plane-anti-and-de-ice-systems/
Vacuum and gyro systems
Besides engine-driven vacuum pumps, X-Plane can now also simulate venturi-powered vacuum systems as found on vintage aircraft and electrical backup pumps that are sometimes found in slightly better equipped general aviation aircraft. The interaction of all the pumps, manifolds and instruments is explained here: https:/article/vacuum-systems/
The traditional vacuum-driven attitude indicator is now subject to the same limitations as in real life, and can be equipped with a caging or fast erect mechanism to help cope with them: https:/article/vacuum-gyro-limitations-and-caging/
Propeller Governors
Propeller-driven aircraft can have distinct behavior of the prop governors reaction to engine failure or loss of oil pressure. Depending whether your plane is a single or multi-engine, whether it is driven by piston engines or propeller turbines, and wether the turbines are of the free-rotating or single-spool design, the equipment might be drastically different. X-Plane now features negative torque sensing in addition or instead of auto-feather, overspeed governors and fuel topping governors, to make turboprop aircraft even more true-to-life: https:/article/propeller-feathering-systems/
Turboprop engines now have additional overspeed and fuel-topping governors for free turboprops, and fuel delivery control for fixed shaft turboprops. How to set up fuel delivery control is explained here: https:/article/setting-up-a-fixed-turboprop-engine-governor/
Autopilots
X-Plane now comes with a few pre-configured autopilots for airplane designers to chose from, and offers more flexibility in creating a custom one.
General Aviation Autopilots
X-Plane 11.30 adds support for single- and dual-axis rate-based autopilots, control over the trim servo, and a separate static system for an altitude pre-selector.
Airliner Autopilots
Airliner autopilots learn new auto-throttle modes, Control Wheel Steering, have two independent flight directors and up to three channels for auto land. They can optionally even have a directional servo for CAT 3 landing rollout guidance.
Learn more about the X-Plane autopilots here: https:/article/preconfigured-autopilots-and-other-autopilot-changes-in-11-30/
The documentation for tuning the autopilot constants has been clarified and expanded with new sections about the new autopilot functions in 11.30: https:/article/x-plane-autopilot-params/
Finally, have a look at the X-Plane airliner autopilot in action, performing an auto land in a gusting cross wind:
https://youtu.be/EAOKNaSPuo8
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.
X-Plane 11.26 release candidate 2 is available for users who check “get betas” in our installer or who select public betas on Steam. It’s just like RC1, but without the giant 60 nm jump when the DSFs load.
Posted in News
by
Ben Supnik |
