10.20 Beta 6 is out – this build fixes the missing paths in the library that were causing the dreaded “Could not load fac/forest/beach” error. This build also puts in some important changes to 64-bit plugis, so below I will try to point out what matters to select audiences:
Users:
If you don’t make an add-on but you are still testing 10.20, there is still a kind of testing that we need (but you may not like it): is anything broken in the 32-bit edition of 10.20 that worked in 10.11?
This kind of bug (it worked in the old version but is broken now) is called a regression bug in the tech lingo, because the sim has “regressed” – it has gone backward. This is the most important kind of bug for us to find for three reasons:
- No one wants to go backward.
- It’s easier for us to find the bugs in new features than random bugs in features we didn’t think we had changed.
- If you report a regression bug against two versions of the sim (it worked in 10.11, broken in 10.20) we have tools to see only the code changes from 10.11 to 10.20, which makes finding the bug much quicker.
So: please try the 32-bit 10.20 and if it fails at something that 10.11 did, please let us know ASAP!
Aircraft Developers
This build fixes the prop disc and airspeed indicator, and finally provides more datarefs for the anti-ice system; I suggest rechecking your airplane with these systems. At this point I think I only have two airplane issues floating around on my radar:
- The new light billboards and spill can be tricky to use, particularly when lights crash through the fuselage of an airplane.
- The manifold pressure indication is FUBAR on helicopters.
Both of these bugs were present in 10.11.
In fact, we have no regression bugs on file in the airplane system between 10.11 and 10.20 32-bit. So if you know of something broken with your airplane that is newly broken in 10.20 32-bit, please report it ASAP. (You do not need to re-report bugs that were already present in 10.11 like the manifold pressure.)
Plugin Authors
This build integrates a fix for LuaJIT on 64-bit Macs; see the release notes and plugin SDK for how to use it.
This build also strips out the symbols of libpng, libcurl, and libfreetype2 on Mac and Linux. These symbols never should have been visible in X-Plane, but they have been for years.
- If your 32-bit plugin used to work on X-Plane 10.11 but stops working on 10.20 32-bit beta 6, please file a bug and we will figure out what to do.
- If your 64-bit plugin use to work on 10.20 beta 5 but stops working on beta 6, your makefile or X-Code settings have a bug; post to the x-plane-dev mailing list to get help.
There may be future changes to 64-bit like this one; this is why I recommend not releasing while we are in beta! Our goal is to ‘get 64 bit right’ now during beta while we can try and test.
Scenery
There are no open regression bugs from 10.11 against scenery; facade textures were borked and are now fixed, and the library should be restored. So if your scenery pack worked in 10.11 and fails in 10.20, please report this ASAP!
I do have one open bug (present in all of the v10 run) that line markings are losing line segments; I hope to get that fixed by the end of beta.
(We also have a report that certain incorrect ATC/apt.dat files will hard-crash the sim – I think Chris will probably be able to get some better validation in place before beta ends.)
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.
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:
- 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.
- 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.
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:
- It’s very fast. The cost of enabling FXAA is very low compared to other anti-aliasing algorithms.
- It doesn’t consume any extra memory or VRAM.
- 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.
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 earth.wed.xml file that produces “bad token errors”.
An earth.wed.xml 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/earth.wed.xml"
If you have an XML bad character bug causing the bad token error you will get something like this:
/Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml:168705: parser error : invalid character in attribute value
<hierarchy hidden="0" locked="0" name="parkeerlijntje?"/>
^
/Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml:168705: parser error : attributes construct error
<hierarchy hidden="0" locked="0" name="parkeerlijntje?"/>
^
/Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml:168705: parser error : Couldn't find end of Start Tag hierarchy line 168705
<hierarchy hidden="0" locked="0" name="parkeerlijntje?"/>
^
/Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml:168705: 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.
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.
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.
GLOBAL_cockpit_lit
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.
(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).
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
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:
- Any scenery pack listed in scenery_packs.ini but not present is removed from the .ini file on load.
- 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:
- Edit the .ini file. It’s just a list of files, and can be reordered as desired.
- Remove some packs, run x-plane, quit, and add them back. Those packs will go to the top of the list.
- 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.)
