New approach-capable GPS navigator in X-Plane 10.30

X-Plane has been lacking a decent navigation solution for general aviation aircraft for a long time. The built-in GNS430 instrument could only do direct-to navigation and not use X-Plane’s FMS plans, making long IFR flights inconvenient.

In X-Plane 10.30 we are introducing a new generation of the X-Plane 430 GPS navigator, modeled more closely after the Garmin 430W that is very popular in general aviation aircraft. The 430W is a popular aftermarket GPS replacement in many older general aviation aircraft, because it is approved for WAAS approaches and thus an easy upgrade to allow flying instrument approaches at lots of smaller airports without ILS.

The new X-Plane unit can create and fly multi-leg flightplans in addition to the direct-to function:
Screen Shot 2014-03-21 at 12.46.53

You can create directs or flight plans using a worldwide database of airports, fixes and navaids:
Screen Shot 2014-03-21 at 12.44.25

Loading or saving the route works using the X-Plane FMS format. Many online services for virtual flight planning are compatible with that:
Screen Shot 2014-03-21 at 12.41.50
Screen Shot 2014-03-21 at 12.48.46

You can then navigate along your flight plan using one of different map views that provide situational awareness:
Screen Shot 2014-03-21 at 12.47.12

While flying under VFR, stay alert to any Bravo, Charlie, Delta or special use airspace in the United states (open database, user-expandable):
Screen Shot 2014-03-21 at 12.38.32

You will be warned when you are about to violate an airspace:
Screen Shot 2014-03-15 at 13.04.03

using the nearest airport function you always know your nearest alternatives for landing (though we all know X-Avion does a much better job at that!)
Screen Shot 2014-03-21 at 12.39.23

With a little help from your friend, knowing when to start your descend becomes easy:
Screen Shot 2014-03-21 at 12.31.28

Before landing, always know who to call:
Screen Shot 2014-03-21 at 12.39.10

For IFR approaches, load precision and non-precision approaches from a world-wide, updatable database:
Screen Shot 2014-03-21 at 12.47.27

Screen Shot 2014-03-21 at 12.47.39

Review approach transitions and initial approach fixes:
Screen Shot 2014-03-21 at 12.47.59
and then load any approach and transition into your flight plan:
Screen Shot 2014-03-21 at 12.48.15

Under ATC (read: when flying online) the vector-to-final function will often be used instead of a transition:
Screen Shot 2014-03-21 at 12.24.22
Screen Shot 2014-03-21 at 12.24.04

The X-Plane 430 is there to help you stay alert to common errors in approach navigation:
Screen Shot 2014-03-21 at 15.07.22

The GPS is capable of flying non-precision GPS-approaches with a localizer-like guidance and varying CDI sensitivity:
Screen Shot 2014-03-21 at 12.33.33
Screen Shot 2014-03-21 at 12.34.17

If you don’t see the runway at the minimum descend altitude, continue to the missed approach point and the flight plan sequencing will go into suspend. At the missed approach point, if you still don’t see the runway, begin your missed approach:
Screen Shot 2014-03-21 at 12.35.09

and then get help choosing the right entry to the missed approach holding:
Screen Shot 2014-03-21 at 15.47.16

The new GNS430 is a drop-in replacement for the old one, so every X-Plane aircraft equipped with the GNS430 automagically becomes more IFR-capable with the 10.30 update. We also provide an additional instrument in style of the bigger GNS530, that designers can use in their aircraft starting with Plane-Maker 10.30. It also allows for dual installations that can either use separate flight plans or cross-fill.
ijaadgjh

The interaction of the GPS with the rest of the panel, especially the CDI and the autopilot, has been improved, offering a few more options for aircraft designers. Two additional posts explaining the new options in Plane-Maker will follow shortly.

The database from which approaches are loaded is provided by Aerosoft. A current database will be provided once with X-Plane 10.30, and further updates will be available on a subscription basis.

You might have noticed stupid COM frequencies in some screenshots. This is not a bug, but a feature: X-Plane 10.30 supports 8.33kHz channel spacing, that is now mandatory in the European upper airspace and will become more important over the next few years.

For the inevitable question “will it have X and does it simulate Y?” I do have one answer:
I chose the feature-set for the 10.30 release carefully to fulfill two requirements:

  1. It must simulate the functions I use every day. After spending about 40 hours flying a C172P with this equipment, I have developed some pattern in day-to-day use. The simulated equipment must have the functions I use every day.
  2. It must simulate what I need for my IFR checkride preparation. I’m currently studying for the instrument rating. All IFR GPS functions that are needed during the lessons must be simulated so I can use X-Plane to practice at home.

This does not cover all functions of the real unit, but it covers what the pilot absolutely needs every day.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in News | 88 Comments

Better Long-Range Visiblity in X-Plane 10.30

I have been working on visibility and fog-related bugs in X-Plane 10.30; two fixes will improve high-altitude long-visibility viewing:

  • 10.25 has a bug where the fog color changes abruptly at the cut between DSF and planet rendering, particularly when atmospheric scattering is on.  This is fixed in 10.30
  • The 64-bit version of X-Plane 10.30 will load 12 DSFs instead of 6, for longer-range drawing of detailed DSF terrain.

These comparison shots show 35k above KSEA looking at Mount Rainier with max visibility.  (Note that at 35k feet, it doesn’t make a huge difference what ground visibility you pick – the planet-wide upper atmosphere model is almost entirely in control.)

These pictures are taken at “very high res” – the most my Mac Pro can survive with an old GPU; you might get a little bit better definition on “extreme” res.

More DSFs

A few notes on loading more DSFs:

  • My current plan is that the 64-bit version will always load the 4×3 DSF box – if we have to make this a setting for compatibility we will, but I think it’s preferable to not add more rendering settings.
  • The 32-bit build will stay with a lower DSF count for memory reasons; generally speaking, I don’t think we will have any additional visibility improvements in the 32-bit build since we are almost always going to hit a memory wall.  If you have a 32-bit OS, consider upgrading to 64-bits!  (In particular, if you are running Windows XP, please upgrade to Windows 7 or 8 64-bit – there are no more service packs for Windows XP, so you’re just asking to get malware!)
  • In 10.30 the DSF loader can load up to 4 DSfs at a time (for 4×3) or 2 at a time (for 3×2).  So if you have a multi-core machine, the load time should be better even though there are more DSFs being loaded, thanks to multi-core.  (The limiting factor here is that adjacent DSFs can’t be loaded at the same time because their edges need to be matched.)

I am still hoping to address other low-visibility fog issues, but that code is not complete yet.

The Planet Could Look Better

X-Plane renders nearby terrain using DSFs, but it renders the very far terrain and entire planet using a single “planet” model, which is a textured sphere displaced by a normal/height map.  As of X-Plane 10.25 (and 10.30) we are not including as much detail in the 3-d planet mesh as the data on disk contains.

This pair of pictures is 45k above LOWI; the second texture has the mesh spacing on the planet artificially increased from 3 km to 2 km.  (The data on disk is at 1 km spacing, but my machine can’t cope with that.)

You can see we pick up a little bit of definition in the far mountains.  In the long term, I think we could ship a 500 meter planet mesh, which would make the far view in X-Plane as good as the close view used to be in X-Plane 7.

I’m not sure when we’ll ship a higher density far-planet, but I think it will have to be post-10.30.

If 1 km or 500m seems like bad resolution, do consider how far away the planet mesh is. With a 4×3 DSF box, the planet starts 100 km from the viewer.  At 90 degrees FOV (an extreme case, but it makes the math easier) the screen is 200 km across at the DSF cut-over.  With a 2 km planet grid, that means we will show 100 planet vertices left-to-right. At 1080p the planet triangles are thus at 20 pixel increments – not bad for a low res mesh.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Scenery | 42 Comments

Clearing the Approach

Last week I spent a little bit of time looking at a bug: some ILS approach paths have tall buildings in the way.  For an example, fly the ILS 22L into KBOS, and look to your right on short final.  I hope the people living in those apartment buildings like watching airplanes!

A Library Bug

It looks like the bug is caused by a bad mapping of art assets in the library.  The global scenery DSFs contain virtual paths for art assets, which are then mapped to real autogen art assets by the library.  The virtual paths indicate the legal height ranges that the autogen can extend to, e.g. the library path

lib/g10/autogen/urban_high_solid_f_30x40_v0.agb

Indicates that this art asset fills a square block at least 30m deep with roads on all four sides, and the buildings should be between 32 and 40m tall for the tallest ones included. (The actual encoding of the library is partly handled by scripts we use to build the global scenery, and the encoding is byzantine enough that neither Alex nor I understand the entire thing.)

Well, if the virtual library path calls for a low building but the physical art asset contains tall buildings, you get skyscrapers in places you did not want them.  And that is exactly the bug causing the ILS incursions.

I have an edit to the library paths for our next release (probably 10.30) that should fix this problem.  The good news about this being a bug in the library (and not the DSFs) is that a single library fix will fix the problem everywhere.

For the Brave

(This is a hack to the sim…don’t try this if you aren’t willing to break your copy of X-Plane.  If you try this and your sim dies, please don’t contact me or tech support!)

If you want to patch this bug yourself now in 10.25, simply locate the file

Resources/default scenery/1000 autogen/library.txt

and replace it with this file: library.txtWarning: because this is a mod to the sim itself, when you go to update, you will get a warning as to whether you want to overwrite the file.  When the next beta or release comes out, do overwrite this file!

What About the Raw Data

I also wrote some code to attempt to ‘protect’ the ILS approach path in our DSF generator.  Here’s a picture:

ksan_approachWhat you see here is a color-coded trace of height limits for autogen.  Red are the strongest height restrictions, yellow less so.  The height restrictions take into account not only the glide slope, but also the terrain; in the case of KSAN, the airport is at the bottom of a hill next to a mesa, so the ‘red’ (low flying planes) zone is quite large – even when a plane is on a 2 mile final, the plane is low to the ground because the ground is higher up.

The logic of the code is to let all ‘known’ tall buildings exist, but limit any generated tall buildings to follow the height restriction.

Here’s the thing: having coded it, I have not caught any cases where the autogen buildings were violating the height restrictions!

Buildings that we generate (without obstacle data) always have a maximum height that is a fraction of the FAA-spec’d tallest building.  The idea is that if the FAA says there is a single 80m (roughly 20 story) building, then the nearby buildings are probably somewhat tall, but they’re not also 80m – if they were, the FAA data would include them.  So we might generate some 40m buildings near the 80m building to create a plausible ‘neighborhood’.

From what I can tell, the fact that the generated buildings are so much lower than the FAA datapoints keeps them out of the approach path, and the actual cause of tall buildings has been the library path misalignment.  (For example, in the KBOS 22L case, the block has an 8m height restriction and yet the buildings are either 50m or 70m tall, I can’t remember which.)

I think I am going to keep the ILS-protecting DSF generation code around – it’s useful to have approach paths noted, and it’s something we’ve been intending to do for quite a while.  But the library fix is what will make a real difference.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Scenery | 21 Comments

Driver Update – AMD Drivers Fixed

An update on the state of drivers:

  • AMD’s latest Catalyst Beta (Catalyst 14.2 V1.3) fixes the translucency artifacts in HDR mode.  This driver also supports the newest cards and has correct brightness levels in HDR mode, so if you’re an AMD user on Windows, this is the driver to use.  This change hasn’t made it to the Linux AMD proprietary driver, but it probably will soon.
  • I have received reports of faint red lines on the latest NVidia Windows WHQL drivers (334.89) under cloudy conditions, but neither Chris nor I have been able to reproduce them.  If you can reproduce this, please file an X-Plane bug.  (I have not reported this to NVidia because I can’t reproduce it.)
  • Some users have reported crashes with Intel HD 4000 GPUs on Windows; getting the latest drivers from Intel seems to fix the issue. I don’t have good info on what versions work/don’t work but it appears that plenty of machines have shipped with old drivers for their motherboard graphics.  I believe X-Plane does run correctly with the Intel HD4000 series GPUs on Windows as long as the right driver is installed.
  • OS X 10.9.2 is out, and I think it may have new drivers (the NVidia .kext files changed versions), but I don’t see any change in framerate for either NV or AMD cards.

Update: NVidia has been able to reproduce the red lines bug – we’re still working out the details of what’s going on, but it’s a known issue now.  Thanks to everyone who reported it.

If you find a driver bug on Windows or Linux, please repot this to us (via our bug reporter) and to NVidia, Intel or AMD.  I try to bring known bugs directly to the driver teams, but having the bug in their public bug reports is good too – it makes it clear that real users are seeing real problems with a shipping product.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Hardware | 9 Comments

Irons in the Fire

Here is a quick update on some of what we are working on.  This post won’t contain everything, as some development efforts are still under the radar, and it’s not a comprehensive list of 10.30 features.

(I am not ready to post a 10.30 feature list yet; please do not comment with “will XXX be in 10.30″.)

The Airport Gateway.  That’s what we are calling the website we are developing for sharing lego brick airports.  The X-Plane Airport Gateway is under construction and has already reached an internal milestone; when finished it will be the portal through which you can share lego-brick airports with the community for inclusion in X-Plane.

We have decided to provide direct upload to the gateway from WED in the initial roll-out of the gateway; it’s a simpler work-flow and it is what we always planned to do eventually.  So there will be a WED release (probably 1.2.2) to match the gateway.

I believe the gateway may go live before 10.30 goes final. (I believe this mostly because I think 10.30 will need a loooooong beta) so at this point we’re looking at how to transfer all shared airports into the gateway, rather than looking at how to release airports without the gateway the way we did in 10.25.  We do want to upload all of the data we already have into 10.25.

Autogen.  Alex is working on a set of autogen that will greatly improve the coverage, variety, and correctness of US autogen.  I do not know when he will complete this task; we will release the work whenever it is ready, possibly in a point release of X-Plane just for autogen.  Basically if 10.30 is in beta when he is done, the work will be rolled into 10.30 betas; if it isn’t, we’ll do a 10.35 or something for the autogen.  The autogen is basically an art-asset update, so it isn’t strongly tied to X-Plane code.

Bug Fixes.  A big part of 10.30 is bug fixes and quality improvements, and a lot of the bugs that we are working on are hard to fix.  (If they were cheap to fix, we would have fixed them in 10.22 or 10.25.)  Our view of X-Plane 10 is that there are a lot of new features that need tuning to meet their full potential, so we are trying to focus on high quality for what X-Plane 10 does, not on expanding X-Plane 10 into (even more) new territory.

As get some of those bugs fixed, I may post a few “call to test” posts – we are looking to do significantly more private beta testing in 10.30 to get specific features tested before the flying circus of public beta starts.  (Please do not request private beta access unless we’re calling for testers.  Our goal is to have new features and bugs fixed by people who are specialists in that part of the sim.)

Third Party Interfaces.  We’ve built up a number of requests for datarefs, third party interfaces, etc. that we haven’t been able to implement in ‘small’ releases like 10.22 or 10.25.  I’m hoping we’ll get through most or all of these in 10.30.  I’ll write up more details when we get closer to a public beta.

DSFs.  We still need to figure out how we will release DSF recuts, but they should be ready when 10.30 is; pretty much all of the work for the recut is already done.

I’ll post more on the 10.30 beta process in a few weeks when we get closer to it.  As of now, the basic coding work for 10.30 is not yet done, so while we have some code to test, 10.30 is not “in the can”.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in News | 11 Comments

A New Particle System Is In the Roadmap

I think I have randomly mentioned this to various developers, so I might as well randomly mention it to all developers.  A new particle system for X-Plane is in our road-map – that is, a particle system where authors can control the properties and graphics in detail (similar to what you’d get in one of the AAA game engines).

If you have feature requests or ideas for things you need for a particle system, please write something short and coherent and email it to me; I can file it with my design notes for later integration.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development | 24 Comments

X-Plane Platform Breakdown

When X-Plane checks X-Plane.com for updates, it calls the server with an identifier for itself that contains a little bit of information about the host machine it is running on: operating system type and version, whether it is the 64-bit or 32-bit version, and whether it is running as a demo.*  (X-Plane does not send any personally identifying information about you, but the server can see your IP address because all servers can see the IP addresses of all incoming network traffic.)

I sometimes get asked by third party developers: what percentage of users are using 64-bit, or what percentage of users are on Mac or Linux.  So I wrote a script to analyze the incoming data and break it down by platform, etc.  Here are the results.  (I have done this kind of analysis before, but this is the first time I wrote a good script to remove possibly confounding results.)

Platform Breakdown

The data set consists of 24,917 unique IP addresses that ran a non-demo, global X-Plane 10.25r1 in the last week of 2013.  This excludes users who have the regional version, a demo, don’t have their DVD in the drive, are running an old version, or who don’t have net connectivity.  So that’s a big enough sample to get good data, even though it’s only a fraction of the total X-Plane 10 copies sold.  Here’s the platform break-down:

IBM: 65.7%
APL: 32.2%
LIN: 2.0%

This matches  the number we’ve seen ever since FSX development was halted: growing market share for Windows. (We used to be 60-40 Windows/Mac back in the day).  Since X-Plane 10 is selling better than X-Plane 9, I believe that what we are seeing is growth, and the growth is disproportionately among Windows users.  The Linux share appears to have shrunk, but it’s hard to tell since past data wasn’t as carefully analyzed.  (The highest percent I have ever seen for Linux was 5%, but from this data I estimate the error bars on old data might be +/- a few percent, so who knows.)

64-Bit Adoption

Here’s the rate of 64-bit adoption for each OS.

All OSes: 82.0%
APL: 85.1%
IBM: 80.7%
LIN: 72.7%

It doesn’t surprise me that OS X has the highest 64-bit adoption – every Mac is running a 64-bit operating system and OS X has the least available address space.  What does surprise me is that Linux has the lowest 64-bit adoption rate, since Linux users have had the strongest desire for 64-bit.  (This desire is, I think, driven by the difficulty of setting up cross-64/32-bit operation on modern distributions.)

Operating System Breakdown

We don’t have a break-down of Linux distros or Kernels – the Linux version of the sim doesn’t report that, but we do have operating system versions for Windows and Mac.  On Windows the _32 and _64 bit suffixes tell whether the user is running the 32 or 64 bit “edition” of the OS.

The numbers include the 64-bit adoption rate for that particular OS; naturally the 64-bit adoption rate on the 32-bit editions of Windows is 0% because those OSes can’t run 64-bit X-Plane.  Fortunately 64-bit editions of Windows are becoming the norm – of the users running Windows 8, over 98% have the 64-bit edition.  On OS X, every version of the OS is 64-bit capable.

Windows:
5.1_32: 1.8% (64-bit: 0.0%)
 5.1_64: 0.2% (64-bit: 0.0%)
 5.2_64: 0.1% (64-bit: 100.0%)
 6.0_32: 0.9% (64-bit: 0.0%)
 6.0_64: 0.8% (64-bit: 77.8%)
 6.1_32: 4.1% (64-bit: 0.0%)
 6.1_64: 66.0% (64-bit: 87.2%)
 6.2_32: 0.4% (64-bit: 0.0%)
 6.2_64: 25.7% (64-bit: 87.3%)
OS X:
 10.6.5: 0.1% (64-bit: 42.9%)
 10.6.6: 0.0% (64-bit: 100.0%)
 10.6.8: 8.8% (64-bit: 78.9%)
 10.7.0: 0.1% (64-bit: 28.6%)
 10.7.2: 0.1% (64-bit: 100.0%)
 10.7.3: 0.0% (64-bit: 100.0%)
 10.7.4: 0.1% (64-bit: 81.8%)
 10.7.5: 11.3% (64-bit: 78.7%)
 10.8.0: 0.0% (64-bit: 100.0%)
 10.8.1: 0.0% (64-bit: 0.0%)
 10.8.2: 0.4% (64-bit: 88.2%)
 10.8.3: 0.3% (64-bit: 88.0%)
 10.8.4: 0.7% (64-bit: 84.7%)
 10.8.5: 15.0% (64-bit: 82.0%)
 10.9.0: 8.0% (64-bit: 84.3%)
 10.9.1: 54.7% (64-bit: 88.5%)
 10.9.2: 0.2% (64-bit: 100.0%)

Hopefully this is useful for third parties in deciding what operating systems and platforms to support.

* This is a standard practice – the update check runs over HTTP, just like your web browser.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development | 42 Comments

Airport Authoring: Sharing Airports

For my final post on airport authoring, a few comments on the sharing process and moderation process.  This is where we’ve gotten the most questions about procedure, etc.

A New Website

Traditionally, airports have gone to Robin Peel – he maintains a private SQL database where submissions are tracked.

We have a developer working now on a new portal website for the global airports – the website will support upload of new airports, tracking of airports by administrators, and downloading of pre-release airports before they are brought into X-Plane.

The site provides back-end tracking for us so that we can see what has been submitted and changed, etc.

To upload data on the site you’ll need a free account – this way we will have contact information for anyone sharing airports.  (Very often we want to email the author and say “could you please fix the one PAPI that is facing in the wrong direction.”)

The Ratchet

The big question is: what about quality?  How will we fix problems in the shared airports, and what will the quality bar be?

My current thinking is: quality should be like a ratchet: no user submission should ever make things worse than they were before.  Over time, this will allow us to continually improve the airports.

This means a few things:

  • If you upload a newer version of an airport, and your work is worse than what was there before in some way, your upload will probably not be used as the new official airport version.  For example, if you add buildings but accidentally delete a runway, the upload is worse and won’t be used.
  • This also means that you have to include every type of data present before-hand.  If the previous airport has buildings, you need to include these buildings in your version even if you are only editing ATC data.  You can’t upload just one kind of data.*
  • If you upload new data (E.g. new buildings) they don’t have to be perfect.  We should not reject uploads because they aren’t as perfect as possible – over time we’ll ratchet up quality.  Let’s walk before we run.
  • On the other hand, if your upload just looks totally broken, expect it to not be used. If there are no buildings at the airport and you put a hangar on the runway itself, we can’t use it.

One reason that we want you to include all data in every upload is that it’s important to check that the data is all synchronized.  If users submit apt.dat and ATC data separately, the taxi routes could be misaligned from the pavement and the authors would not see this.  By having everything in your package you can see that alignment is correct between all data sources before uploading.

Moderators and Collaboration

The system is being designed to support multiple moderators; one thing that seems clear so far is that the work of keeping an eye on this data has gone way up now that we have buildings too.

If there is a conflict between two legitimate layouts, both very good but different, we have the emails of the authors – we can email both and say “you guys work out a compromise for the location”.

One final thought: I have seen a lot of postings on forums, email to me, and blog comments, all expressing concern about what to do about bad data and how to stomp it out.

I think it’s important to take a step back and not get too carried away here.  The goal of the global airports is to share data, with the moderators spotting bugs.  No author that I have spoken to has ever said “I really want to post bad data to your database!”  The moderators will be more like editors of a book than police catching criminals.

I bring this up because I have participated in other crowd-sourced projects, some that presume the authors are innocent until proven guilty (e.g. they assume authors know what they’re doing) and some that are guilty until proven innocent (e.g. no contribution goes up without a super-thorough review).

Invariably, the more relaxed projects end up with significantly more contributions, and in the long term end up with higher quality data, driven by a larger and more motivated authoring community.  By comparison, the projects that put a huge emphasis on stopping contributors from erring as a primary goal end up deterring user contributions, and end up with worse data as a whole due to a lack of man-power.

One thing Robin has done right for quite a long time with X-Plane’s airport (which might not be obvious – sometimes when you do soemthing correctly its invisible) is to not alienate contributors who have had data quality issues.  I want to make sure that we preserve a positive attitude toward contributors as we grow the global airport process.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Scenery | 32 Comments

AMD Drivers Are Still Dead

Update: this driver bug has since been fixed – see here.

bork bork bork

If your X-Plane screen looks like this with HDR on, you may be running the new Catalyst 13-12 drivers.  If you can, back up to the Catalyst 13-9 drivers to get back HDR mode.

(If you have a really new AMD card, you might not be able to run 13-9 – in that case please turn off HDR until AMD has a fix.)

This is a continuation of this problem – what’s new is that the 13-12 drivers are WHQL drivers and not just beta drivers.

Thanks to the users who reported this to me.  I try to keep an eye on all driver combinations, but the help is appreciated!

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in News | 3 Comments

Airport Authoring: Airport Boundaries

Since X-Plane 8.50, airports have had a border polygon that defines the boundary of the airport surface area. The airport boundary polygon is probably the least understood aspect of airports, particularly because it takes effect when we cut DSFs, not when you load X-Plane.

The airport boundary does a few things:

  • If sloped runways are not enabled, it defines (roughly) the area that X-Plane will flatten to the airport elevation. If you have ever entered a silly field elevation in WED and then turned off sloped runways, you’ll see that the flattening process is not exact.
  • When we create base mesh DSFs, the area of the boundary polygon gets a grass surface texture.
  • When we create base mesh DSFs, the area of the boundary polygon has no autogen buildings.  (These two points are actually one in the same – the zoning of ‘airport’ in the DSF creation tool adds grass and removes autogen at the same time.)
  • When we create base mesh DSFs, the elevation under the boundary polygon has large bumps and spikes removed.

No More Bezier Curves

If you’ve used WED 1.2, you may have noticed that it refuses to validate airports with bezier curve boundaries.  This is because we are trying to stop the use of bezier curves for airport boundaries.

The problem with  bezier curves is that they can very easily be self-intersecting, but WED has no good test for this.  The result is (apparently) valid WED airport layouts that later crash the DSF generator.  Every time we cut DSFs, we find a handful of boundary polygons that need to be hand-fixed due to bad bezier outlines.  There were 3 in this last batch.

Furthermore, the DSF generator cannot actually use bezier curves – it has to convert them to polygons.  So the author will not get a surface area like the one they expected – there is a conversion that must take place.

Faced with a bezier curve technology that produces crashes and isn’t actually used, I decided to switch to straight polygonal airport boundaries.  So: when you work on new airports, please remove bezier curves from your boundary polygons.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in File Formats | 16 Comments