Category: Scenery

Autogen Is Here, More Coming

X-Plane 10.20 beta 5 is out now – beta 4 was defective (installer-kitting problem).  This build drops in a lot of new autogen.

The most immediate bug report I’ve gotten is third party scenery packs that are broken because they use library paths that are no longer available.  I need to investigate what’s going on here, but I believe that we will need to post an updated library file that is not missing library definitions in a future beta.  It may take a few betas to get this set up.

I also have not had time to attack most of the ‘meat and potato’ bugs that have been reported, so again it may take a few betas.  We’re not rushing hard on the 10.20 run; I think it’s better to give third parties time to get their feet wet with 64 bits and make sure we address all of the technical concerns that come up from third party plugins.

 About the New Autogen

The new autogen included in 10.20 beta 5 includes some of the new buildings that Alex has been working on; there is more that is not yet complete or published.  The autogen art development actually consists of two tasks:

  • Creating buildings and fragments of buildings (both mesh and texture) that look good and have high performance. Because we want to make the autogen fast, Alex tries to reuse sets of autogen where possible.
  • Taking that “lego kit” of fragments and putting them into specific autogen art assets – autogen art assets are not just individual buildings – a single art asset builds an entire city block, encoding the rules for how a subset of the building fragments are used.

The main problem from 10.11 and earlier is that we had no autogen that provided urban buildings to irregularly shaped blocks – hence we fell back to the ranch houses, which just looked silly.  The new drop has more irregular autogen with higher density urban buildings.

There is another chunk of autogen Alex is working on that is not done yet: buildings that respond to vertical information.  This is why the Manhattan skyline just isn’t that “tall” – the DSF contains the height information.  But while we have art assets that cover the shapes of the city without ranch houses, we don’t have enough art assets that can respond to the “tall” directive.  When Alex drops that in we should see more vertical development.

I do not know what the timeline is for more autogen, but the general plan is simple: Alex will keep working on more art assets and we’ll periodically drop them in as we get them, each time bringing more realism to the existing global scenery.

Posted in News, Scenery by | 58 Comments

DDS and V10 – What Does It Do?

This post follows up on the case for DDS and DDS in v10 and answers some basic questions.

DDS and Texture Compression are Not the Same!

This is the first and most important point: the decision to compress textures and the decision to use DDS are not the same!

Texture compression is decided by the user.  If the user clicks “compress textures” (and nearly all users should do this) then 99% of the textures in your add-onwill be compressed.  You can’t avoid this.  The user has spoken and said “sorry, I don’t have 3 GB of VRAM, we need to tighten things up.”

DDS is a pre-compressed format; DDS says “well, if you are going to compress, I have already done the compression for you with DDSTool, so it will look better.  See the pictures in the posts above for why this is so important!

I cannot emphasize this enough: most users are going to have to use compression to save VRAM, so you should ship DDS files so that the compressed images look good.  You can ship DDS and PNG if you want to ensure that the uncompressed case looks good too, but I think that users running uncompressed is going to be rare.

Does DDS Improve Framerate?

No!  See the above post: the user may be running compressed textures regardless of whether you ship a DDS, so when you ship a DDS you may see no VRAM savings and no FPS change.  All you will get are compressed textures that look better.

Does Compression Improve Framerate?

Sometimes.  Texture compression will improve framerate under two conditions:

  1. The texture unit bandwidth on the GPU is exhausted.  This is very rare now – I haven’t seen this happen since the Radeon 9600 XT.
  2. The user is out of VRAM.  This is quite common.

But recall how free VRAM affects framerate:

  • When the user runs out of VRAM, the fps loss is often catastrophic.  The user might see huge jerking, big pauses in framerate especially as the camera moves, and performance will be unusable.
  • When the user has extra unused VRAM, there is no benefit – framerate does not go up indefinitely by freeing up VRAM.

So most users will simply turn down texture resolution until they can fly.  Thus the real effect of texture compression is to let users turn their overall texture resolution back up again one notch, improving the overall look of the sim.

Is There Any Way to Make DDS Look Less Bad?

Sometimes DDS is relatively harmless to a texture, and sometimes it just absolutely destroys it.  I don’t have a good answer to this, except: be sure to run the latest DDSTool/XGrinder (see the “command line tools” option on this site) when targeting X-Plane 10, and never set your gamma to anything other than 2.2.  I do hope to someday look at improving DDS grinding capabilities.

Posted in Development, Scenery by | 16 Comments

A Flicker of Hope for Flicker

I’ve seen a few bug reports complaining about ‘flicker’ with HDR enabled. It took me a few tries to understand that the users were not actually reporting Z-Thrash (which is what I think of when someone says ‘flicker’, but were actually reporting temporal anti-aliasing of anisotropic meshes like roofs and roads.

Ants are alienating an icy tropical metro what now?!?

Sorry, graphics programmers have lots of big words for things that aren’t actually that complicated.  (Seriously, we call a daytime texture an “albedo”.  Who is Mr. Bedo anyway??)  But basically the issue is this:

  • We have something that appears long and thin on the screen, like the roof of a far off building (wide, but not tall, in pixels) or a road (again, wide, but not tall – a road might be 20 pixels wide but only 1 pixel tall on screen).  Anisotropic just means different lengths in different dimensions, more or less.
  • The road or roof will be rendered in a stair-step manner, as the graphics card tries to approximate a diagonal with pixels.
  • As the camera moves, which pixels form the stair-step will change every frame, causing parts of the road or roof to flicker into and out of existence on a per frame basis.

Going for a Swim

In the old days, this effect used to be called ‘swimming’.  A diagonal line would appear to ‘swim’ as the stair-step pattern changed as the camera changed.  The swimming was annoying, but if you had a lame graphics card, you could live with it.

The problem is that in X-Plane 10, a lot of the meshes we draw are a lot smaller.  As we build more 3-d detail and improve the engine to draw more detail on screen, the result is a lot of really small things.  In X-Plane 9 we could draw 5-10k objects; now we can draw over 75k objects.  That means that individual objects on screen may be 1/10th of their size (since there are more of them).

So instead of having big objects with big triangles that ‘swim’, we have tiny triangles that flicker out of existence entirely.

Anti-Aliasing 101

One reason I haven’t blogged about this before is because there are a ton of different full-screen anti-aliasing technologies out there and the prospect of explaining them was daunting.  Fortunately Matt Pettineo did an awesome job with this post.  Go read it; I’ll wait here.

The main idea is that full screen anti-aliasing draws everything bigger and then down-sizes it to get softer edges.  Diagonals don’t look stair-stepped, and a tiny roof won’t flicker into and out of existence because relative to the larger size that it was drawn, the roof is no longer tiny.  In other words, 4x MSAA makes everything 4x less tiny from a perspective of a triangle being ‘too small to not flicker’.

The second reason why I am getting bug reports about flicker (besides a larger number of smaller triangles) in v10 is that HDR mode doesn’t use conventional MSAA.  For various technical reasons, MSAA works poorly with a deferred renderer, and HDR is a deferred renderer.  So like many games today, X-Plane’s problem is to anti-alias without letting the hardware do it.  If you’re used to 16x MSAA from your graphics card, HDR with no FSAA is a rude surprise.

Current Option Number One: FXAA

FXAA is an anti-aliasing shader written by Timothy Lottes at NVidia.  FXAA is typical of a whole category of anti-aliasing solutions in that it is a post-processing solution – that is, it takes an aliased, jagged image and attempts to smooth out the image after the fact.  (MLAA is also in this category.)

FXAA has a few things going for it that are good:

  1. It’s very fast. The cost of enabling FXAA is very low compared to other anti-aliasing algorithms.
  2. It doesn’t consume any extra memory or VRAM.
  3. It produces smooth diagonal lines, more so than lower-levels of FSAA.

It does, however, have one major down-side: because it doesn’t actually draw the scene at a higher resolution, any mesh that is so small that it is flickering is still small, and thus it will still flicker.  On any given frame, the roof will have no jagged edges, but the roof may simply not exist in some frames.  If the roof isn’t drawn at all, FXAA can’t fix it in a post-process.

So FXAA is fast and cheap and makes still images look nice, but it can’t deal with temporal artifacts, that is, flicker between frames.

Current Option Number Two: SSAA 4X

4x SSAA simply means we draw the entire world at double the resolution in either dimension, and then down-size it later.  Jagged edges become blurred in the down-size and thus aliasing is reduced.  (Nerd note: when technical papers talk about OGSSAA, they mean ordered grid super-sampled anti-aliasing, which just means the image is bigger. 🙂

The up-side to SSAA is that it reduces flicker.  Because the drawn image is bigger, very small elements won’t flicker (since they are bigger when drawn).

The down-side is the cost: 4x SSAA is the same as doubling your screen res in both dimensions.  And if you’ve experimented with monitor resolutions, you know that once you are GPU bound, doubling the resolution in both dimensions uses 4x the VRAM and cuts  your framerate to a quarter of what it was.

So the big problem with 4x SSAA is cost.  Since we’ve improved HDR performance in 10.10r3 I’ve seen more users reporting the use of 4x SSAA.  But it’s not cheap.

Newer, Better Options

I have two new tricks for HDR FSAA that I’m hoping to roll into 10.20.  (They’re new to X-plane; I am sure someone else has coded these things in other games before.)

First: FXAA and SSAA can be used at the same time in the engine, for better quality than either can provide on their own.  SSAA does better at fixing temporal artifacts like flicker (because it makes things ‘4x bigger’ relative to the size at which they flicker) but FXAA does better at making diagonals ‘less jagged’.  Now you can have both.  (10.20 features a newer version of FXAA.)

Second: I realized that our aliasing is anisotropic (there’s that word again) meaning it’s not the same in both directions.  X-Plane’s worst aliasing comes from long thin horizontal screen elements like roads, and roof tops.  Therefore having more anti-aliasing vertically than horizontally is a win.

So rather than just have SSAA 4x (which is twice as big horizontally as vertically) we can now do 2x (only vertical) and 8x (2x horizontal, 4x vertical).  This provides a range of options; 2x SSAA will be affordable to some users who can’t run 4x SSAA at decent framerates.  8x SSAA will provide anti-flicker that should be as similar to non-HDR with 16x MSAA for urban scenes, for those who have a big new graphics card.

I posted a set of technical test pictures here.

What about TXAA?

NVidia has announced a new anti-aliasing technology, called TXAA.  At this point there isn’t enough technical information published about it for me to comment meaningfully on it.  My understanding is that TXAA is not yet available for OpenGL based games.

I can say that in the future we will continue to try to adopt the best anti-aliasing technology we can find, and the problem X-Plane faces (anti-aliasing for a deferred renderer) is not at all unique to X-Plane, so it is likely that there will be good solutions forthcoming.  Far smarter minds are working on this problem at ATI and NVidia as we speak.

Posted in Development, Hardware, Scenery by | 14 Comments

WED 1.2: Recovering from a “bad token error”

There is a bug in WED 1.2 beta 1 right now: if you somehow manage to get non-unicode data saved into your file*, you won’t be able to re-open it.  This is definitely a bug and something I will fix as soon as I can, but it also means you can lose your WED project.  This blog post explains how to fix an file that produces “bad token errors”.

An file is basically a very big text file.  These instructions are for a Mac; on Linux the same tools are available – on Windows you can use the port of xmllint or find another, more friendly XML validator.

From the terminal, run xmllint like this:

xmllint --noout "/Users/bsupnik/Desktop/EHAMaptdatxml/"

If you have an XML bad character bug causing the bad token error you will get something like this:

/Users/bsupnik/Desktop/EHAMaptdatxml/ parser error : invalid character in attribute value
<hierarchy hidden="0" locked="0" name="parkeerlijntje?"/>
/Users/bsupnik/Desktop/EHAMaptdatxml/ parser error : attributes construct error
<hierarchy hidden="0" locked="0" name="parkeerlijntje?"/>
/Users/bsupnik/Desktop/EHAMaptdatxml/ parser error : Couldn't find end of Start Tag hierarchy line 168705
<hierarchy hidden="0" locked="0" name="parkeerlijntje?"/>
/Users/bsupnik/Desktop/EHAMaptdatxml/ parser error : PCDATA invalid Char value 16
<hierarchy hidden="0" locked="0" name="parkeerlijntje?"/>

In this case, the ? is the bad character being mapped to ‘?’ by OS X’s terminal.  I now open the file in a text editor (I used X-Code), go to line 168705, and simply replace the string inside “name” with a new string, without a bogus character.  Resave (make sure you are in UTF8 format) and you are good to go.

A future beta of WED 1.2 will fix this, but for now you can hand-edit; once you remove these XML errors your project should be good for further use.

* This bug is particularly insidious because WED 1.0 would very happily write junk data out to disk, then read it back again, so you could have non-unicode junk strings in your project for years and only upon moving to WED 1.2 realize what happened.  A common way to get junk data is to import an apt.dat file with non-UTF8 airport names.

Posted in Development, Scenery by | 1 Comment

Scenery Packs – the New Rules

X-Plane 10.10r3 is out – release notes here.  Go use Rc3!  This might be the final RC – we’ll know in a few days.

Now that people are using 10.10 more frequently, I’ve received some bug reports that turned out to be problems prioritizing scenery packs.

The rules for how scenery packs are prioritized have changed!  Please read this carefully!

The Rules

Old: Scenery packs are loaded alphabetically by name.

New: Scenery packs are loaded according to the .ini file in Custom Scenery

That’s pretty much all there is to it.  The .ini file means that you can organize your scenery by reordering the .ini file rather than renaming packs.  That in turn means you don’t have to worry about having crazy names like a_Overlay b_SecondOverlay, and you don’t have to do a massive rename of a lot of packs to get the names right.

If you don’t want our scenery, disable them in the .ini file (by replacing SCENERY_PACK with SCENERY_PACK_DISABLED).  The installer won’t re-download them.

The .ini file sets the stage for a future UI or third party utilities that edit priorities, and installers that can set up custom priorities.

How Packs Are Added

When X-Plane runs, any packs that are found in Custom Scenery but not in the .ini file are added to the top of the .ini file.  If more than one “new” pack is found, the new packs are added in alphabetical order (but still before every old pack).

Any missing scenery pack is removed from the .ini file when X-Plane runs.

This means a few things:

  • If an overlay isn’t high priority, you can remove it, run X-Plane, then put it back and run X-Plane.  This moves it to the top of the list.  (Or just edit the .ini file – which is probably easier.)
  • If you simply want alphabetical order, delete the entire .ini file – every pack will then be added on the next sim run, in alphabetical order.


Posted in Scenery by | 21 Comments

New OBJ Commands

I have updated the OBJ8 specification with the new X-Plane 10.10 commands.  This blog post explains why we added some of these commands.

Pixel-Space Drag Manipulator

The pixel-space drag manipulator is a new axis manipulator whose drag length is measured in screen pixels instead of meters; its drag axes are always screen aligned, but it works both horizontally and vertically.

The goal of this manipulator is to make draggable knobs that:

  • Have a good response speed for both slow and fast drags via a non-linear curve and
  • Have the same drag sensitivity no matter what camera angle.

The axis manipulator has the problem that it works in 3-d; depending on how you look at the manipulation target (both position and rotation) the sensitivity of the drag can change radically.

Recommendation: use the regular drag-axis manipulator for levers and other physically moving items.  Use the pixel-space drag manipulator for drags where the underlying target does not move, like knobs.  Use button-type clicks for anything that just toggles – it’s easier on the user.

No Shadows

Three new attributes (GLOBAL_no_shadow, ATTR_no_shadow, and ATTR_shadow) allow you to exclude part or all of your object from shadow casting.  Shadows can make certain types of geometry, like grass billboards, look silly; excluding them from shadows fixes artifacts.

Note that ATTR_no_shadow is different from ATTR_shadow_blend..

  • ATTR_no_shadow: the geometry simply does not cast a shadow!  This is meant to exclude objects like vegetation.
  • ATTR_shadow_blend: the geometry does cast a shadow, but only if the alpha is greater than a certain ratio.  This is meant to make windows with tint cast shadows correctly.

Recommendation: fix shadowing bugs using ATTR_no_shadow for non-instanced objects, and GLOBAL_no_shadow for instanced objects.  Use the Plane-Maker check-box for parts on aircraft.


This attribute lets you have your cake and eat it.  In X-Plane 9, ATTR_cockpit gives you alpha blending, but ATTR_cockpit_region gives you correct 3-d lighting.  You have to pick one or the other.

In X-Plane 10.10, GLOBAL_cockpit_lit gives you both.  It makes ATTR_cockpit use 3-d lighting (while maintaining translucency) and it makes ATTR_cockpit_region respect alpha translucency (while maintaining cockpit lighting).

You can add this attribute to any airplane.  This attribute should make it easier for authors to adopt correct 3-d lighting in their airplanes.

Recommendation: use GLOBAL_cockpit_lit on any airplane that uses ATTR_cockpit to change to 3-d lighting for your panel texture.  Also see here for more guidance.

Posted in Cockpits, Development, File Formats, Modeling by | 11 Comments

Exterminate! Exterminate!

(Oh come on, I know at least some of you are Dr. Who fans…)

If you have not read the news, OpenStreetMap will be removing their non-license-compatible roads this week.  I stopped following the debate on this years ago, but basically they changed open licenses and have had to drop contributions that could not be re-licensed from the original authors.  My understanding is that the amount of data that will have to be nuked will be very small.

If you have already contributed to OSM even remotely recently, you probably agreed to the new license terms and your data is fine.

My thought: after the redaction is finished would be a great time to check your home town and help put back any lost roads, etc.

Propsman sent me this rather zen bit of OSM the other day…

I certainly hope they won’t have to redact it. 🙂

(Seriously though, one of the major data quality problems with X-Plane is people creating train platform and building footprints out of actual train tracks.  If you are working on an area, please check the tagging of stations and platforms to make sure they’re not actually railways!)

I do not have a schedule or plan for recutting from new OSM data – it’s an aspiration right now but there’s a lot on the short list we have to deal with first (like 10.10).

Posted in Scenery by | 11 Comments

Not A Bug, Apparently

When I saw this near KMSY in New Orleans my first thought was: oh hell, what bug created that?  All of the roads seemed to run over these channels of water, as if someone had created mini-rivers for them.  I assumed bad OSM data.

Then I looked the area up on Google and…no, they actually built the road over water intentionally.

View Larger Map


Posted in Blooper Reel, Scenery by | 10 Comments

scenery_packs.ini: What Was I Thinking?

One of the changes to X-Plane 10.10: custom scenery packs now are tracked in an .ini text file called “scenery_packs.ini” that sits in the custom scenery folder.  This blog post explains how the .ini file works and what problems it was trying to solve.

The Old Days

Long ago, in X-Plane 10.05r1 (and every version before it dating back to X-Plane 8) X-Plane would load custom scenery packs in alphabetical order from a folder called “Custom Scenery”.  This simple convention was a work-around for not being able to “manage” scenery pack load order.

In the old days, you could change priority of a pack by renaming it and disable it by moving it to a different folder.  I have a number of packs called a_Some_Overlay and z_Base_Mesh and I’m sure others do too; I also have a folder called Custom Scenery (Disabled) that I dump stuff into.

Unhappy Installers

The problem with the old way is that users have to manage scenery packs by renaming and moving them.  If an installer has installed a pack, it won’t be able to find what it installed again.  We started to see this with X-Plane reinstalling the Aerosoft custom scenery packs that come with the global edition of X-Plane; users would delete or reprioritize the pack and our installer would not be able to update the pack because it had moved.

scenery_packs.ini: Explicit Priorities

scenery_packs.ini simply contains a list of scenery packs to load in priority order: top of the file is highest priority.  Listing the pack as SCENERY_PACK_DISABLED disables loading entirely.

This means that a user or third party utility can now organize and prioritize scenery without having to rename files.  Installers will still be able to find their installations and packs can have their “factory” names.

How Does scenery_packs.ini Get Updated?

What happens if the file system and scenery_packs.ini are out of sync?  Here are the rules:

  1. Any scenery pack listed in scenery_packs.ini but not present is removed from the .ini file on load.
  2. All scenery packs present in Custom Scenery but not in the .ini file are added to the top of the .ini file in alphabetical order.

Note that this means that your new packs are installed in alphabetical order relative to each other, but they are installed with higher priority than any existing packs.

We can’t easily install new packs in alphabetical order compared to all packs because all packs may not be in alphabetical order if the packs have been reorganized.

Ways to Reorganize Scenery

There are a few work-flows I can think of to easily re-prioritize scenery:

  1. Edit the .ini file.  It’s just a list of files, and can be reordered as desired.
  2. Remove some packs, run x-plane, quit, and add them back.  Those packs will go to the top of the list.
  3. Delete the .ini file.  The entire file will be rebuilt in alphabetical order.

The Future

Someday I do hope we’ll have a UI to organize scenery, but we don’t have one yet and won’t have one for 10.10.  My thinking is that it’s still an improvement to not have to gum up scenery packs with prefixes to control their load order.  But this does cause some work-flow changes.  (If you want to continue to use alphabetics, simply delete the .ini file after editing.)

Posted in Scenery by | 23 Comments

Variation Safety Valves

I fear one of the main points of my last post was perhaps lost in the excited discussion of how to cope with conflicting crowd-sourced airport submissions.  The engineering principle is:

Fix real bugs, not hypothetical bugs.  Solve real problems, not hypothetical problems.

By this I mean: it’s invaluable to wait until you actually have evidence of a problem before you design the solution.  Without a real data point showing what the bug is, the solution might not actually fit the problem as it actually happens.  In a program as complex as X-Plane, particularly when third party content is thrown in, it’s hard to predict in advance what is going to go wrong.

In the previous case (coping with conflicts) the key here is that I want to see a few conflicts before I choose a plan.  I see proposals for a revision system, public logs, a registery, a voting system…any one of these ideas might be the right solution, but we don’t know yet because we don’t have two people submitting buildings.

The same principle applies to another issue that was brought up a while ago:

Won’t all of the default airports look the same since they all use the same library?

First, to be clear: we’re not trying to make the default library airports look like the real world airports, we’re not trying to duplicate custom scenery, and if people submit buildings for all 20,000 airports in X-Plane there’s no way we’re going to have 20,000 control tower libraries in the library.

But there is a valid issue: what if people heavily use the assets?  Won’t we start to get a “sameness” either between two airports or within an airport as we use the library more and more?

This brings up the second half of “fix real bugs”:

Identify possible solutions, but don’t use them until necessary.

I am not worried about collisions of airport because there are a huge number of possible solutions, many of which are easy to implement and have been proven to work well in the real world in other problems.  In other words, the problem of merging crowd-sourced data is a solved problem, and we can use the right existing solution when we have enough data to pick that solution.

The same thing applies to repetition in the library: we have ways of fixing repetition.  I want to develop a few airports and see what looks repetitive before asking our artists to spend their time making more stuff* but we at least know how we can fix the problem when the time comes.

Options to Deal With Repetition

So what are the safety valves here?  How can we deal with repetition in the library?  There are a few ways:

  • Every object in the library can have multiple real OBJ models for each “virtual” object.  X-Plane picks randomly among the choices, so we can always add more real objects.  We already do this for cars. (There are something like a dozen cars and trucks backing up one or two library entities.)
  • Some of the library elements are .agp (autogen-point) files – these files are mini-scenes made up of other objects, and the objects referred to within the scene are also subject to library variation.  So we can have a mini-scene where some of the decorations are constantly changing.
  • The facade engine contains some fairly flexible rules for picking which segments of walls go where, so there’s a lot of potential to break up the order of facade walls.
  • We can add more types of facade walls to a given facade without hurting X-Plane’s performance.

All of these changes can be put into an X-Plane update.

In summary, there are a lot of ways we can make the library more diverse and less repetitive, and as we see the library get used (and certain elements become over-used) we can add more variation to keep things looking fresh.

* For example, it wouldn’t make sense for me to ask Tom to make 50 variants of the administration building if almost no one places it in any airport.  We need to see what kinds of assets get used the most and then make decisions.

Posted in Development, Scenery, Tools by | 16 Comments