Some of our users have the bad luck of having a laptop with Intel 4th generation graphics. This is the last generation of the “GMA” graphics cores – they generally come on motherboard (and often you’ll have one that you don’t use even if you have a PCIe graphics card) and they’re not very powerful. Motherboard graphics are designed to lower the cost of the entire computer for users who don’t need 3-d. They are not designed to make X-Plane look awesome.
These GPUs are causing two problems with X-Plane 10.10:
They crash on startup when we ask the driver about our window’s format. Why it does that is not yet clear to me, but there may be a work-around.
Our shaders won’t run on the GPU, which claims we ran out of texture units.
I consider this second problem very silly, as the card tells us how many texture units it has, the number is the same as every other GPU, and we don’t use more than those numbers. There may not be a work-around to the second problem; in particular if the shader compiler has a bug that causes it to misunderstand our shaders, we won’t be able to do anything.
So at this point X-Plane compatibility with the gen-4 Intel GPUs is an unknown. It looks like there are subtle core differences within the series that may also cause problems.
I can tell you this: if we ever get them running, it’s not going to be pretty or fast. I have the 6th generation GPUs (Intel HD graphics in an i5-2500) and the performance is not on the same planet as a discrete GPU.
Other Intel Cores
We do not support the 3rd generation and earlier GMA GPUs. The numbering scheme is really nutty, so that table can help.
We do support “Intel HD” graphics – they’re not great, but they do run. That includes any built-in mobo GPU from a “core i5” or “core i7” chip.
TL;DR
The short version is: if you have a gen-4 Intel GPU and see crashing, please stand by; we are investigating now. We will either fix the crash and provide a work-around in the upcoming 10.20 patch or declare the GPU unusable. I’ll post an update in a few days.
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.
X-Plane 10.11 is now final, so you will receive an update notification even if you have not participated in the beta program.
Starting with 10.11, I am stripping the ‘r’ designation off the end of the build; the complete build number is still visible in the log file and properties, but what you see on your startup screen will just read 10.11.
I do not know if we will cut an X-Plane 10.12 before we get into a 10.20 public beta of 64-bit; I have seen a number of bug reports for 10.10/10.11 that need investigation, but I don’t know if the problems are due to bugs, running out of memory, rendering settings cranked too high, etc.
The main goal of 10.20 is to get us to 64 bit; we’ll also ship better anti-aliasing and autogen in that build. We aren’t sure what will come in 10.30, but at this point more performance tuning and stabilization is likely.
A while ago, I wrote up a summary of the issues with OSM and water. I still do not know a time-frame or plan for OSM recutting, but I can say it will be after getting 64-bit done, and once 64-bit is done, it will be high priority. If the water you care about is not in the OSM map itself, a recut won’t help until you or someone else in the OSM community updates the map.
(For Americans who are frustrated about water that was in X-Plane 9 but is not in X-Plane 10: X-Plane 9 used US Government data. There is work in the US mapping community to get the NHD data into OSM; I suggest participating in this effort. You can import and check a single water shed and thus bring a local region up to date, and the changes are ‘forever’ since they are in the OSM data set themselves.)
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.
