One big massive bug fix! (and some optimizations!)
#264 caused some people’s lights to be put in the wrong place. The fix involved Ben coming up with awesome math to put things back in their place by a certain offset, and then us creating a way to parse the light.txt file that controls much of the lighting in X-Plane.
This Changes Nothing in Your Blend files!
Seriously! No Blender data should change!
However, It Could Change Your OBJs
XPlane2Blender is now more consistently WYSIWYG! Meaning that if you point a spotlight at a wall, it should show up pointing in that direction, regardless of what a named spill light thinks or the parameters of a param light think.
This is good news for new authors and authors suffering from the bug, but depending on how you’ve been making your lights appear rotated, it could result in needing to change the rotation or parentage of existing lights.
What Lights Are Affected?
All of the following conditions must be true for a light to be affected by this change
- Be a Blender non-point light, for instance a spot light
- The light’s
XPlane Type must be Named or Param
- The light’s
XPlane Name must be found in the lights.txt file inside the addon’s new resource folder
In rare edge cases, special and less used lights will be excluded from auto correction.
So, as you can see its either somewhat common or very specific which lights are affected. So, if your eyes haven’t glazed over yet,
Please Send Reports Of How This Affects You – Good, Neutral, Or Bad!
We try our best for backwards compatibility and a bug free existence, but we don’t know everyone and their situation until they say hi! If you are faced with large hurdles to continued productivity, please file a bug! Preferably with before and after pictures and .blend files. Automated fixes may be developed for people affected.
This is just one step to a more WYSIWYG XPlane2Blender.
With 11.10 there is a new way aircraft only shadows are done, as well as how aircraft icons are generated. The big change is how we calculate the volume of the aircraft which up until now was based on all OBJ files that the aircraft ships with, including things like ground- and fuel trucks, stairs etc. The reason this is undesirable is because the greater the volume of the aircraft, the worse its realtime shadow quality will be because we use the volume of the aircraft to calculate our shadow map area. The bigger that area, the worse the shadow quality and the more pixelated it will look like. In an ideal world, the aircraft volume tightly hugs around the actual aircraft and we get the best shadow quality possible. With 11.10, hopefully this ideal world is finally here!
Why and how we failed before
Before 11.10 the aircraft volume was based on the volume of, well, the aircraft. However, this includes things such as the aforementioned ground trucks, fuel trucks and what have you, that artificially blow up the volume calculation. The problem is, all these objects are technically part of the aircraft (eg. we move them around with the aircraft), but they are for the most part invisible and most people wouldn’t actually consider them to be part of the aircraft proper.
In 11.05 we added a change to also consider the physical volume which kind of has the right size for the plane but doesn’t include OBJs. It is based on the physical size of the plane only, which sounds like it’s the right thing. However, as it turns out, this volume breaks badly for things such as helicopters because the rotor of some third party helicopters are attached OBJs and won’t be considered part of the physical volume of the helicopter.
At this point I should probably also quickly note what happens if the shadow volume is too small: Everything that gets clipped by the shadow volume will cast a shadow into infinity and beyond due to the way the shadow mapping works. This is especially bad for the helicopters that now have very quickly rotating bits that are constantly clipped by the shadow volume resulting in shadows flickering all over the place.
In short: What we want is a shadow volume that is as tight as possible around the aircraft for shadow quality, but not too tight because that also leads to problems.
What’s new in 11.10
In 11.10 the algorithm to compute the shadow volume has been completely changed. Instead of trying to jiggle around with the physical volume and the volume of all OBJs together and then coming up with a sane value, X-Plane now looks at what is actually being rendered. We start out with the physical bounding volume as before, but then we look at what is actually rendered! For that, we go through every OBJ that is marked as casting shadows and run the OBJ engine as if we were to render the whole thing. So OBJ animations as well as kill datarefs etc are considered. This happens during the first frame, so everything is set up the way it would be during normal rendering. Everything that is visible will be marked as such and the shadow volume will be expanded to include this OBJ.
The result is a volume with a tight fit around what is actually visible and therefore considered “aircraft”. Everything else is not included in the shadow volume and therefore stops casting shadows altogether. Of course, this is only in aircraft only shadow mode and is not used when scenery shadows are on. In that case, everything is handled like it was before and everything that is supposed to cast shadows does cast shadows. So, if you see missing shadows in aircraft only shadow mode, this is probably due to this change.
To visualize the differences, here are 4 screenshots showing the quality difference as well as the new shadow volume:
One thing that should be noted though is that going forwards these kinds of extra OBJs should really be done via the new drawing API in the 3.0 SDK! This allows us to very accurately determine the size of the aircraft but it also means that culling will become more accurate. The old method will of course continue to work, but it’s not the best or most efficient way to approach ground vehicles and other ground clutter.
The calculated volume for the whole aircraft with attached OBJs was also used for the aircraft icon generation. This led to some weird cases where the camera was positioned in such way that the aircraft was incredibly tiny due to the fact that we tried to get “everything” in at once. So far the recommendation was for authors to create a version of their aircraft without all the extra OBJs attached, but now that we have an adequate measure of the aircraft volume this is fixed as well! Aircraft icons should be correctly generated now with the camera positioned to capture the plane at the right distance.
There is one more fix for aircraft icons: Some authors created aircraft that did some clever culling based on where the pilots head is and then using the kill dataref to prevent parts of the aircraft from being rendered. Reading the view dataref now correctly reports the camera as being an external camera so that those custom culling solutions work with the aircraft icon generator. If your aircraft still doesn’t generate proper icons after 11.10, please file a bug report and let us know!
AI planes face two major issues in X-Plane 11:
- AI aircraft are often way more resource-intensive than they need to be. Users are fine paying a performance penalty to load, say, a super detailed 3-D cockpit model for their own aircraft, but for AI planes, where you’re never going to be in the cockpit, there’s no reason for that sort of thing. A significantly “dumbed down” version of the same aircraft would allow users to load more AI planes at once, with no visible downsides during normal use.
- Many aircraft, for one reason or another, simply won’t function at all when used as AI planes. This is most commonly due to one of two issues:
- reliance on third-party plugins (which only work for the user’s plane)
- lack of support from X-Plane for flying aircraft like this (for instance, the X-Plane AI doesn’t know how to fly gliders, seaplanes, or rockets)
As a user, this is really frustrating, because it’s difficult or impossible to know in advance which aircraft will work as AI planes and which will either a) just sit on the runway, never able to take off, and/or b) tank your frame rate.
Coming in X-Plane 11.10: AI-Only and User-Only Aircraft
In the upcoming X-Plane 11.10 beta, we’ve added two new options to Plane Maker’s Author window: “supports user flight” and “supports AI flight.” By default, all aircraft support user flight, and do not support use as AI aircraft.
If a plane is configured for AI flight only, it will never be shown in the normal aircraft grid—only in the AI aircraft window.
If a plane is configured for user-flight only (or if it’s a pre–11.10 aircraft with no “supported flight type” info), it will be hidden in the AI aircraft window by default, but for the sake of backward compatibility with old planes, users will still be able to reveal them by checking a box labeled “Show aircraft without AI support.”
The upshot for aircraft authors
In the Glorious Future, we envision third parties shipping two versions of their aircraft:
- one marked user only, which include all the bells and whistles, plugin-enhancements, and as much detail as possible
- one marked AI only, which is stripped down for performance, only using plugin enhancements that have been tested in AI configurations.
The result will be a faster, more consistent, less error prone experience for users.
These smaller features are likely to be overshadowed by the release of the G1000 for default aircraft in 11.10, so I decided to dedicate a blog post to promote the articles I’ve written – you can find them among all the guides for aircraft developers: http://developer.x-plane.com/docs/aircraft/
Electric and remote gyro systems
Back in April, I flew a Mooney M20J with a KCS55A HSI in it, and realised that it was impossible to model in X-Plane correctly, so I got to work. See the manual for an explanation of this popular HSI/remote gyro system.
I’ve written a usage guide on the new datarefs and commands that I added, along with some more detailed explanation of all the different gyro systems X-Plane simulates, in this guide for aircraft developers. I also talked about the systems at length in a Youtube live stream earlier this year.
Separate GPSS autopilot mode
This is a feature that many add-on aircraft already simulate to some degree, but by means of more or less reliable plugin trickery. The X-Plane 11 default 737 and 747 are no exception. With X-Plane 11.10, a separate GPS steering mode for the autopilot becomes a standard feature.
The new datarefs and commands are explained in detail here.
Screen-only popup instrument windows
Several people who build home-cockpit setups have asked about removing the bezels from the popup displays, so they can have only the screen of a GNS430/530, FMS or G1000 instrument to put on an external monitor, with a hardware bezel around it. While this can already be achieved through some clever hacking in the Miscellaneous.prf file, we now offer a more straightforward way to do this: The popup and pop-out windows now get their bezel graphics from the library system, so you can override the bezel graphics. How to override the bezel with nothing, if your bezel is made of hardware? Simply supply a 1×1 pixel blank .png as a bezel graphic, and X-Plane will know that you really want no bezel at all. In the case of a bezel-less 430, you’d put a 1×1 pixel png as the “cockpit/radios/GPS FMS/Garmin_430_2d.png” resource of your plane.
If you have been doing work with manipulators during beta.1, please download this new one and review the notes! Download the latest here: io_xplane2blender_3_4_0_b3.zip
- #ATTR_layer_group_draped causing KeyErrors
- Reverts bad change to manipulators properties*
“.beta.3” will be printed on all OBJs. This is not permanent, expect something better in the future
What happened to the manipulators?
A poor decision to change the Manipulator Type (Drag XY, Push, Command Knob, Toggle, Delta, etc) means that if you changed the type of manipulator between
7fe534ad1f906b7853827 if you constantly check out the latest cutting edge commits [which I do not recommend for this exact reason]), this beta will make those changes irrelevant.
Example, suppose on 8/1/2017 you create a switch and set the manipulator type to
Toggle, then with beta.1 you change the type to
Push. Beta.3 will show the type as
Toggle. All you need to do is go back to the switch and change the type back to
Push. The rest of the values you set will still be there. If you created manipulators during the beta, they will be set back to the default “Drag XY” type and will need to be fixed.
This is an unfortunate lesson to be learned, and if you are facing a lot of tediousness (30 manipulators to hunt down and change) or potential errors (you can’t remember how many or which ones you changed) please contact me!
I will personally help you recover the changes you made during beta.1 – present.
XPlane2Blender v3.4.0-beta1 is out!
The next version of XPlane2Blender is right around the corner, come test it! Highlights of this release are Optimized Animations, Increased Usability, and X-Plane 11 OBJ8 features (mainly Blend Glass mode and Normal Metalness). Read more about what has been changed on the release page and download it!
(Link to beta removed until major breaking bug has been fixed. Make backups of files before using any beta product.)
As with any beta, make backups before using a partially tested product. We don’t predict there should be anything breaking in it, but its never a bad idea to be safe.
Bugs and feed back on Github is preferred over this comment section, but most of all I want to hear your feedback. To stay focused, only comments related to XPlane2Blender, the beta, and Blender will be responded to for this section. The status of other 3D Modeling Plugins/VR/Weather Systems/etc is off topic.
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.
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.