Please tell me what confuses you about XPlane2Blender on this bug, or here!
We are going to be releasing the XPlane2Blender 3.4 beta soon, and with it, a refresh of the UI and documentation. Thanks to a great e-mail about a lack of documentation, it was put as an important part of 3.4 release roadmap. It goes to show… we can’t fix it if we don’t know what’s wrong, even if its not a code problem. And we do want to fix it, I swear!
In addition, I want to remind everyone a core part of the Laminar Research philosophy, identity, and business plan is a thriving modding and third-party plugin ecosystem. Aside from build scripts and the like, Laminar Research employees use the same scenery development tools that are available to all. This is was a deliberate choice that elevates everyone to the same level – except when there is a gap of knowledge. This is never intentional, and never benefits anyone in the long run, especially third-party-devs. If your work is suffering because we forgot that not everyone knows what every little checkbox means, tell us! We’ll put it in the bug queue like everything else, and try to get back to you, personally, quickly.
We have a new video tutorial on using FMOD to add custom sounds to X-Plane 11. This simple tutorial shows how to add a snapshot and an event in FMOD.
The video also has a permanent home on the video page of this site, and on the X-Plane YouTube channel.
As always, let us know your thoughts in the comments and if you have requests for other tutorials. I’m starting to get the hang of creating movies, and if you don’t troll me too hard about the quality I might make more. 😉
With X-Plane 11.02 the built-in GPS and FMS units for X-Plane 11 aircraft will also display heliports and seaplane bases. While this change is obviously needed badly for the helicopter flying community, improperly configured fixed-wing aircraft might suddenly feel themselves confronted with unsuitable options in the nearest airport selection pages and on the moving map.
Filter criteria
Every X-Plane aircraft has three parameters for airport and runway filtering that can be used to configure the moving map. These settings have existed for a long time, influenced which airports were displayed on the moving map, and kind of worked with the X-Plane 10 GPS as well. X-Plane 11 completely broke those settings for airplanes using the new X430/530 GPS, and not all aircraft authors go through the trouble of setting them up correctly.
X-Plane 11.02 correctly filters airports for GPS and FMS use as well as for the moving map based on these parameters. Because the GPS now also displays heliports and seaplane bases, it is important to set these filter parameters correctly in Plane Maker, to prevent unecessary clutter on the map.
The three settings are:
- Only Airports on Map – If not checked, the GPS and moving maps will show helipads and seaports. Check when you do not want those to show up in the nearest airport list on the GPS
- Only Paved Runways on Map – If not checked, the GPS and moving maps will show airports with no solid runways like grass, gravel and water surfaces
- Minimum Runway Length to Show on Map – This will filter out airports where the longest runway is shorter than this distance
Note that the these settings work on a per-airport basis. That means:
- At an airport with both runways and helipads, the helipads will still be shown regardless of setting.
- At an airport with both paved and grass or water runways, both runways will still be shown.
- In other words, airports are filtered out if they ONLY have helipads, or ONLY soft runways
- For seaplanes, leave the “Only Airports” box unchecked but enter a runway length number in order to supress the heliports.
If you already set these parameters in the past and they worked in X-Plane 10, there’s nothing for you to do. If you never bothered to set them, and suddenly see places inappropriate for landing show up in your built-in GPS, that is why.
Hot off the presses – first draft today: new docs on Using FMOD With X-Plane Aircraft and a file format spec for those .snd files you need to tie FMOD To your aircraft.
This is a first draft, so please: use the comments section to ask questions about FMOD only. I’m going to do something a little bit unusual and delete off-topic comments on this post so the entire comments thread is FMOD specific. FMOD integration with X-Plane is complicated, so it would be really useful to know what needs more explaining.
There is one more piece of the FMOD puzzle that is missing – Tyler is working on it now and hopefully we’ll have it live soon: the FMOD starter project.
The short version is: to get an FMOD project that will properly integrate with X-Plane and other third party FMOD aircraft, you need to get a starter project from us – it will come with the mix buses already in place and set up for X-Plane to use them; you can just add signal processing, etc.
What makes this tricky is: everyone needs a unique starter project or else multiple FMOD aircraft won’t be able to coexist. (And that would be sad – one of the really cool thing about FMOD-enhanced aircraft is that you can finally hear the AI aircraft. It adds a ton of depth and realism.)
Tyler is working on a download link that dynamically creates a unique FMOD starter document to avoid FMOD conflicts between AI aircraft. I’ll post when this is up and running.
In the meantime, the docs hopefully answer some questions about how aircraft like the Cessna work.
Right now FMOD can only be used to add sound to aircraft, but we are looking at adding FMOD to scenery, as well as our own ground vehicles.
Philipp made a change to the Cessna’s autopilot that makes it more realistic, but also slightly trickier to use.
As of 11.30, the Cessna’s autopilot uses HDG + GPSS for nav course selection. Philipp wrote a developer article explaining what all five of X-Plane’s nav course source modes do, but here are a few notes.
Among autopilots that aren’t totally hopeless (e.g. the Sperry, “none” for its course source) there are two major divisions:
- Autopilots that get the heading for a VOR or ILS from the autopilot heading bug.
- Autopilots that get the heading for a VOR or ILS from an (E)HSI, leaving you to use the heading bug to pick your own heading.
This first category is less high tech and less useful to the pilot, and it’s the bucket the Cessna is in. If you want to fly a localizer, you have to set your AP heading bug to the localizer’s course, or the autopilot is going to lose its mind.
What this means is: if ATC gives you a heading to intercept the localizer, you cannot just engage heading mode, arm localizer mode, and fly the course to intercept – when you intercept the localizer, you won’t track it properly. You will have to adjust your heading bug onto the localizer front course once you start intercepting it.
The GPS is a special case: It works like a VOR/LOC when you are in NAV mode (affected by the heading bug) and like you’d expect when you are in GPSS mode (not affected by the HDG bug). So if you want to fly a GPS flight plan with twists and turns fully automated, you must press the NAV button twice in order to turn the autopilot to GPSS.
Something that can trip people up is that you cannot use GPSS and APR/GS at the same time – if you want to fly a WAAS approach with vertical guidance, you have to step down from NAV GPSS to NAV APR, which means you’re dependent on the pesky heading bug again. Confusing? Yes. Annoying? Certainly. Realistic? Definitely! This is exactly as annoying as the real thing.
The second category gets the localizer heading from either magic (GPS/LOC) or the OBS knob “OBS”) and always gets the VOR radial from the OBS course (which make sense). These setups let you fly a “dual mode” approach – engage HDG, arm LOC, and fly the intercept heading – when the localizer comes alive, the AP can switch modes and know which way to turn to intercept without you having to mess with the HDG dial.
You’ll find GPS/LOC-based systems in our Kingair (which has an EHSI) and Baron (which has a HSI).
We’ve been working on a single comprehensive document for aircraft authors – everything that changed in X-Plane 11. Jennifer has posted a draft here. This is still a draft, and we still have work to do, but there’s a lot already there, so we figured better to post it and let people comment and get started.
For entirely new features, we are creating separate articles on how to use them – it would be a little weird to have to look up “v11 aircraft checklist” to learn to use FMOD. This means that this document refers to some unfinished (and unpublished) documents that will be coming soon.
Changing Blending
One of the changes listed in the document is that we changed the blending in X-Plane from blending in sRGB space to blending in linear color space. This is a universal change. It affects: all 3-d drawing, including everything drawn with an OBJ and the 3-d drawing of the panel texture. It does not affect:
- Plugin-based drawing in any 2-d drawing callback, including plugin UI drawing.
- Drawing into the panel (either via Plane-Maker instruments or plugin code).
In other words, your panel is composited in 2-d as it was before, but the usage of the alpha channel of that final panel texture is different.
How Am I Different?
The notes say blending is now linear and not in sRGB space. What does that actually mean, and how does it affect you?
Take a look at the color gradients in this blog post. (The whole post is really good, but the gradients show this issue). When you have a surface with intermediate alpha, you’re getting the intermediate gradient of the thing behind your surface and your surface’s albedo, with some fraction determined by the alpha.
As you can see from the chart, the intermediate colors are all brighter with the new linear blending. This intermediate brightness is more like what you would really see when working with translucent materials; the old model was losing light energy.
(X-Plane 10 was linear in the entire rendering engine except blending – we kept blending in sRGB space – it was very complicated and messy to do and hurt performance. So it was a priority to make things both faster, more correct and less insane on the code side for X-Plane 11.*)
What Do I Have To Do To Tweak My Textures?
Let’s get practical: textures with alpha will not look the same as in X-Plane 10, and while sometimes the new result is just better (light colored alpha-based lettering on panels almost always looks better in v11 out of the box), sometimes you’ll need to retune your alpha channel.
In pretty much every case, the new blending is brighter in intermediate values than the old one, which was losing light. (When we stop losing light, the net result is an increase in light.) So these cases will all involve ways to back off the brightness; you probably made things overly bright in X-Plane 10 to compensate for non-linear blending.
Here are a few typical examples we saw when exploring this feature with our art team.
Tinted Glass: tinted glass typically suffers from two problems:
- It’s just not dark enough.
- The tint color itself is too bright and now “shows” a bit, e.g. non-colored tinted glass looks light gray.
First: make the RGB of your texture darker if possible. Dark tinted glass should almost certainly have a black RGB (and use alpha for “how much” tinting).
Then: adjust the alpha as needed – if darkening the RGB didn’t do it, increase the opacity.
Painted Reflections: if you’ve painted reflections onto your glass, they may look too bright.
First: consider letting the engine be the reflection source – you may want to use BLEND_GLASS for cockpit glass and/or use metalness to increase reflectivity. Do these things first before editing albedo and alpha textures; they have a much bigger impact on your scene than the new blending mode.
Then: when done (or if you will not make these changes) decrease the opacity to turn down the reflections.
Dirt and Grunge: we found that our black markings on the ground looked too light – they were using alpha to anti-alias the edge of the marks and simulate pixels that contained a mix of dirt and the underlying surface in a single point. (This particularly matters when you zoom away from the marking and it becomes small on screen).
First: make sure your RGB channel contains correctly dark colors around the edges of the decal. (In what I’ve seen, artists pretty much always get it right in this case.)
Then: increase the opacity of the effect to make it darker (by emphasizing the dark decal more than the lighter pavement.
As a general rule of all of these, the RGB of a blended surface should be very dark (decals, tinting) or very light (fake reflections) and not be mid-range. Then the alpha can be made more opaque to darken darks or more transparent to darken lights.
* Nerd’s Nook: If you known enough OpenGL to be dangerous, you might be asking “Ben you idiot, why don’t you just turn sRGB blending off and on based on whether the content you are drawing is new to X-Plane 11 or old from X-Plane 10? You can just use glEnable!”
Sadly we cannot. In the forward renderer we might be able to toggle the blending mode per object or something, but in the deferred renderer (HDR mode), we blend all albedos together, all lit textures together (during G-buffer setup) and then we add the total lit to the total albedo during the single lighting pass where we apply the sun.
Basically we’re taking the math of the blending equation and rearranging the algebra. This rearrangement only works if the color space for adding the lit and albedo together is the same color space as every blending operation.
So for HDR to work, we have to pick a single blending equation sim-wide because we have to pick a single way to add lit and albedo together. For X-Plane 10 we picked sRGB color space and for X-Plane 11 we picked linear. Linear is a total win here – besides looking better in a lot of cases, adding lit textures to albedos looks better when done in linear space too. After all, we are adding light.
I just found a bug in beta 15 (and 14, and 13, and 12..etc.): if you use ATTR_shiny_rat or GLOBAL_specular with an intermediate value, e.g. between 0 and 1, you get an oily effect when HDR is off.
This is a bug in one of the shaders. We didn’t see it early because I have encouraged our art team to set the specular ratio to 1.0 and leave it there and use the normal map to modulate specularity. You should take that advice too! The GPU is really good at reading textures, and the CPU is not particularly good at interrupting the GPU to change what it’s doing, which is what ATTR_shiny_rat does.
Beta 16 will fix this; in the mean time, what you see in HDR mode (the top two FX settings) is correct, for the purpose of figuring out if your art looks good.
X-Plane 11.00 public beta 12 is out. A few notes on the engines:
- Jet engine thrust at low N1 should be fixed; you should no longer have to kill the ground crew to taxi around the ramp. If you find weird jet engine N1 behavior, please report a bug ASAP!
- Reciprocating props will need to have their idles adjusted, perhaps a bit higher, particularly if your idle adjustment is < 1.0 in Plane-Maker. We had to bump up our Cessna, which was set to about 0.8 and was stalling if not given a little extra throttle.
- The engine start code has some kind of bug that is stopping engines from starting.
If you’re hitting this last case, please file a bug and include the aircraft that won’t start.
From what I can tell, the beta 11 code is actually correct for some airliners, but is wrong for others. I’ll have more details later and I suspect we’ll have a beta 13 that addresses this by Tuesday.
In a previous post I noted that we weren’t attempting dynamic ambient occlusion inside the 3-d cockpit, due to problems of quality, availability, and because it wasn’t really better than what authors do now: prepare the AO offline using a high quality render in their 3-d modeler.
I’ve been thinking about this a while: while I like to get up on my soap box and shout that X-Plane is not like a first person shooter any time we get compared to a AAA console title, there is one case where X-Plane kind of is like one: inside the user’s aircraft.
First person shooters often specialize in rendering highly controlled, closed, constrained, claustrophobic environments in ludicrous detail at very high framerate. To achieve this, they take advantage of optimizations specific to those closed, controlled environments: lots of things are pre-computed, pre-baked, and pre-calculated.
X-Plane’s scenery engine mostly focuses on throughput; once you climb through 500 feet you can see everything at an airport, so we just try to draw really fast. But the inside of the aircraft is different. Baking at least part of the interior lighting is pretty much a standard practice. We provide object-kill datarefs to let authors script their own culling algorithms to squeeze framerate out of a confined space.* We define sound spaces within the aircraft that can change how sound effects are filtered.** We let you mark which parts of your aircraft receive interior and exterior light. (This feature is called “light groups” in a regular 3-d game engine and it’s very common, particularly in older forward-rendering engines.)
All of this stuff is a lot more like a game with a 3-d level editor than the rest of X-Plane. Techniques that focus on interior spaces are a good fit inside an airliner.
Better Baking: one of the features planned for our next-generation modeling format is to allow multiple UV maps for a given model***. We can then add an ambient-occlusion texture to an object’s shader and you can bake your aircraft interiors at a much lower resolution than you albedo textures.
For example, you could use a high-res repeating texture to draw the seats inside the aircraft, copy-paste the seat down the cabin, and then unwrap a second UV map that covers the entire cabin uniquely. Bake to this second UV map, down-size the texture to super low res (it’s ambient occlusion, “soft” is okay) and you’ll get high-res detail with unique correct lighting queues all over the aircraft. This is a standard work-flow for 3-d game engines and seems like a good fit for aircraft interior.
Edit in the Sim: we can take another clue from game engines and provide editing of graphical aircraft information inside X-Plane. We already do this for the particle system – the editor is built into the sim itself.**** The advantage of editing in the sim is that you can see your work exactly how it will look in real time.
* Engines that focus on interior spaces often have techniques like portal culling built-in and tools to precompute the information for this culling automatically.
** This is part of the new FMOD SDK – we will get this documented around or shortly after 11.0 goes final.
*** I realize this isn’t very “next-gen” in the world of rendering engines – it’s just the next major modeling revision for X-Plane.
**** The particle system isn’t documented because it isn’t quite finished yet. It’s shipping in mobile, enabled on desktop, but it is not running the default effects right now.
This has been a point of confusion for third party developers, particularly ones who were in the private beta (and saw versions of the sim that…cough cough…didn’t work right).
Screen space ambient occlusion (SSAO)*, when enabled by the highest rendering settings, only affects exterior objects. This means scenery and aircraft-attached objects marked “exterior” for lighting.
I tried SSAO in the cockpit interior, and it had a few problems:
- The scale for occlusion in the interior and exterior of the cockpits is really different – I couldn’t find one size for the effect that fit all cases.**
- When I went to apply the effect to our fleet, I found that virtually all of our aircraft already had occlusion baked into the cockpit by the artists. The dynamic AO thus provided almost no value and made the cockpit even darker than it already was.***
- SSAO only works at the highest rendering settings (and requires HDR to function at all), so if artists remove their baked AO, they’re taking a pretty big visual loss in a bunch of settings.
So in net, it just wasn’t worth going to dynamic AO in the cockpit. Our AO isn’t as high quality as what you can bake in a 3-d program (given a few days of rendering time), and it’s not always available.
The real win for SSAO is outside the aircraft, e.g. to cast AO around the wheels of the aircraft on the ground. That’s an effect that you can’t bake, and it helps a lot with lego brick scenery too.
* Nerd note: I’m pretty sure that what we do is actually HBAO
** We could, in theory, apply the effect twice with stenciling at two different scales.
*** The cockpit tends to be dark both due to errors in our approximation for indirect light (because most of the cockpit is in shadow, and thus only lit by indirect light) but also because cockpits are actually pretty dark compared to the great outdoors. But that’s another post.
