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.
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.
X-Plane 10.11 rc3 is ready for testing. If you see a lot of spurious warnings about LOD errors in your Log.txt file on Windows, get this build by running the updater and checking “get betas” – it should help.
Posted inNews
by Ben Supnik|Comments Off on X-Plane 10.11 RC 3 Ready for Testing
Yesterday I was able to reproduce and fix a bug that several people reported against X-Plane 10.10; the bug is random, which explains why, when I tried to follow their reproduction steps, I did not get the same results. The last step in the bug report could have been “get lucky”.
The bug is: on Windows, sometimes the sim would output a ton of LOD warnings for objects (including default objects that ship with the sim) and then framerate would be reduced. Running a heavy framerate test on my PC I saw fps reduced from 25 to 15 fps when the failure happened.
The bug was 8bytes of uninitialized data deep in the OBJ engine; the impact depended on the random contents.
I will cut X-Plane 10.11r3 soon with a fix to this.
Reminder: please do not post bug reports to the comment section. This includes reports of “I saw this bug too or “I saw this, but on OS X” or “it works fine for me” or “why haven’t you guys fixed XXX.” Please report bugs via the bug reporter.
X-Plane 10.11 release candidate 1 is now available online – run the installer, and update with the “get betas” button checked to get it. This is a small bug fix build to get new Japanese strings out; most of these bug fixes were coded during 10.10’s release candidate period but held to keep the sim stable for DVD pressings. It’s a small update.
EDIT: Pleasestand by, the upload did not work right – it should be available later tonight.
EDIT 2: Okay – now we are live.
We may do one more small bug fix release (e.g. a 10.12) before we get to 10.20, which will introduce 64-bit and have a longer beta period. 64-bit porting is going well and I am happy with the progress so far.
What About WED?
A number of WED users have reported a really nasty bug: while mousing around, WED would put up a fatal error dialog box and quit, with work lost. This bug sucks, and what was worse, no one could find a good procedure to reproduce it. The steps appeared to be “do some work, get a lot of changes ready, click, lose work.”
That is, until now; the other day Chris round the reproduction case. I now have a fix, so I will try to cut a WED 1.2 beta 2 in the next week.
Well as I promised (11 months ago), here’s a tutorial on making ATC Taxi Networks in WorldEditor v1.2. Hopefully this clears up some misunderstandings about how the pieces of the system work and how they’re meant to be used. Perhaps the next video tutorial will be on creating Airport flows to teach ATC which runways get used for which operations.
If you need to create a final flat part of a panel out of multiple layers, some translucent, and you are using panel texture, it is better to composite the entire piece of panel in the panel texture than to layer polygons in your OBJ.
For example, consider the annunciator display on the dashboard that many airplanes have. There are two ways to build this panel:
Model the entire thing in the panel texture. The background can be part of the panel background, and each annunciator is a generic instrument.
Each annunciator sits on a transparent background, and the background of the annunciator panel is a separate piece of non-panel texture, on a second mesh, directly behind the first.
Choose option 1! Tom had to convert the Baron’s annunciator panel from method 2 to method 1. A few reasons to prefer method 1:
The sim does not allow for truly emissive translucent lighting in an OBJ, so the results look better if composited in the panel texture.
You can get shadowing artifacts between the polygon layers.
Spill lighting on the dashboard will not look quite right if there is alpha.
You won’t use up that more panel texture, but you’ll make your life easier. This technique wasn’t totally possible before, but now with GLOBAL_cockpit_lit you can alwys have your panel handle real lighting.
First, for the plugin authors: I am hoping to start a 10.20 beta for 64-bit in weeks, not months. I don’t know how many weeks it will be – there’s a huge potential for variation, but if you maintain a plugin, be aware that you’ll be able to actually test your plugin against a 64-bit X-Plane this year.
At this point we have launched X-Plane, 64-bit-style on all three operating systems. That doesn’t make it beta-ready but we have a heartbeat.
X-Plane 10.10 is final, and we may cut a small bug-fix patch (10.11) before we go into 64-bit. We have a handful of lower-priority bug fixes that we kept out of 10.10 for stability that we need to release at some point; the plan hasn’t been finalized.
Mac and 64-Bit: Not That Fast
So once I had a 64-bit X-Plane running on my machine, I did the obvious thing: crank the settings through the roof and see what happens. And I can now report the results:
Very low framerate.
The problem is: my machine was very close to maxed out with 32-bits. When I was able to crank the settings beyond where I could before, I simply overloaded it. Too many objects, too many textures, too many vertices, too much stuff. It’s a 2008 Mac Pro with a 4870 – not a spring chicken.
I mention this now because:
The overwhelming majority of users telling us they want 64 bits are Mac users. On 64-bit Windows OSes, X-Plane has significantly more address space headroom, so you have to push the sim a lot farther to run out of memory.
Macs just aren’t that fast. You either have a laptop (highly constrained by the need to be power-efficient) or an iMac (power constraints and no update for over a year) or a Mac Pro (with the best graphics card two generations old and no real CPU update in a while).
In other words, my Mac may be older and slower, but the very fastest ones aren’t that fast. There is no Mac equivalent right now to an Ivy Bridge i5 or i7 with a GeForce 680.
So while you may be hitting address space limits and crashing on your Mac right now, you may not have that much hardware budget left over, and it may be a short trip from 64-bits to finding you’ve simply maxed out your hardware.
It’s All About the Watts
One last thought on Macs falling behind Windows gaming machines: while this used to be a function of technology it’s really become a race with only two factors: watts and time.
The older a model gets, the farther behind the curve it is. So the Mac Pro is really behind due to being age constrained; if they update it with a current-gen desktop GPU and an Ivy-Bridge based Xeon CPU it won’t be cheap, but it will be competitive. For desktops the big issue is one of cost: you can get the latest mobo at any time for Windows and a game machine is significantly less than a Mac Pro.
Watts: how much GPU power you get is a function of the power budget of the card, and both the iMac and laptops are constrained relative to desktop machines. The new Retina-Book MacBook Pros are nice, new, top of the line laptops, but they are also using the GeForce 650M, a decision to trade off some GPU power for battery life, heat dissipation, etc. There will inevitably be an AlienWare laptop that ways 12 lbs, burns through its battery in five minutes, but ships with a bigger mobile GPU for better performance. I’d rather use the lighter laptop, but my concern is traveling with my work, not flying.
My point here is: these two factors (revision time for models and power use profile) are unlikely to change any time soon – they are fundamental to Apple’s business model. So Mac users, on average you are never going to have the same performance options as your Windows brethren.
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.
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.
If you maintain a plugin for X-Plane, you can already take some of the steps necessary to go 64-bit. I am working on 64 bit code for 10.20; here’s what you can do to be ready for the beta:
Upgrade to the X-Plane SDK 2.1 headers. The 2.1 headers change the use of long to intptr_t to fix 64-bit issues. This will mean a one-time cut-and-paste pass over your code.
Note that you do not have to make your plugin v10-only (or 2.1 SDK only) to use the new headers. Your plugin will require the 2.1 SDK only if you #define XPLM210 to 1. By not defining the new APIs you don’t opt into them. Your plugin built against the 2.1 SDK will work with X-Plane 9 (or 8, 7 or 6 for API 1.0 plugins).
Find and fix any case where you cast a pointer to an int and back – in 64 bits that will fail. as you will see from the 2.1 headers, widget properties are now intptr_t to ensure that the property can hold a pointer.
Once you have have fixed these new header issues and int <-> ptr issues you’ll be in good shape to go to 64 bits when a sim is available.
Update: to clarify, with the 2.1 SDK you can write code that will be 64-bit safe, and you can probably even compile in 64 bits. But you can’t link your 64-bit plugin – we have not released library files or documentation on the appropriate fat packaging structure. So you can get ready by cleaning your C/C++ code, but you can’t actually finish a 64-bit plugin. (And if you could, how would you test it?)
