Life would be easier if the Earth was a big cube.* I was reminded of this yesterday when I discovered (thanks to a bug report from an author) that X-Plane has been drawing objects with slightly incorrect heading for the last who-knows-how-long amount of time.
The bug (present in 945 and going back who-knows-how-long) is that the object’s heading can be off by up to 1 full degree clockwise or counter-clockwise. (This maximum error occurs at the north pole – average error for real use cases is more likely to be about 0.35 degrees.) The amount of rotation depends on how the scenery system is shifted.
The case the author sent me was a converted scenery pack, where a pair of parallel runways were modeled partly out of draped polygons (which don’t exhibit the bug), but with markings modeled as an OBJ. Depending on the scenery system’s “centering” the markings would be a little bit to the left or right of the draped polygon.
A brief aside: do not model your scenery this way! A bug is a bug, and X-Plane 950 beta 1 fixes this problem, but there are a number of reasons not to use a giant OBJ to model your runways.
- OBJs do not “hug” the terrain, and the Earth is round. You will never really get clean, artifact-free flat surfaces unless they can follow the terrain contour. Even if you “flatten” the terrain, it’s not flat – it’s constant MSL.
- The case where I see this more often is with buildings, where authors build every single terminal building in one OBJ. X-Plane only “connects” the OBJ to the ground at one point (0,0,0 in the object). So to get a good ground connection, you need your objects to be smaller, so they can all “sit” on the ground. (Technically they need to be rotated slightly to wrap around the Earth, but for the scale of an airport this error is only about 1/30th of a degree or so – hard to see.)
- Finally, X-Plane chooses to draw or not draw an object on a whole-OBJ basis. So if you have a huge object, it’s always in view (because at any one time some part of it is in view). In fact, even if the object is not in view, the larger the object, the more the “sloppiness” of the visibility check causes false positives. (The visibility check is optimized for speed, so it really answers “this object is probably in view”, erring on the side of drawing too much by doing less analysis.) So the bigger your objects, the more they are drawn.
Enough ranting – in this case the scenery was the output of FS2XPlane, and the author hadn’t gotten to cleaning the results. Fortunately the interim product showed the rotation bug.
X-Plane 950b1 (in beta now) fixes this problem – rotational alignment of a very large OBJ with a draped polygon should match between X-Plane (with all frames of scenery system reference) vs. WED 1.1 preview 2 pretty much exactly.
*This post is in the long and distinguished tradition of “life would be easier if” musings relating to scenery, e.g. global scenery would be easier if the entire planet was paved in asphalt, cities would be easier if their road grids only ran perfectly north-south and east-west, clouds would be easier if they weren’t translucent, and rendering would be easier if nothing on the planet ever was translucent or cast a shadow. So apparently a programmer’s paradise is somewhere between “Mad Max” and a Dali painting…
There’s a slight performance win to be had by grouping taxiways by their surface type.
Now clearly if you have to have an “interlocked” pattern of asphalt on top of concrete, on top of asphalt, this isn’t an option.
But where you do have the flexibility to reorder, if you can group your work by surface type, X-Plane can sometimes cut down on the number of texture changes, which is good for framerate.
X-Plane will try to do this optimization for you, but X-Plane’s determination of “independent” taxiways (taxiways whose draw order can be swapped without a visual artifact) is a bit limited and can only catch simple cases.
For what it’s worth, interlocked patterns of surfaces were much more a problem with old X-Plane 6/7 type airport layouts, where the taxiways were sorted by size, and there could be hundreds of small pieces of pavement.
Some of the newer text file formats for art assets (.lin files, roads, etc.) require you to specify how wide the texture is.
Huh? Why does X-Plane need me to tell it how wide a texture is? Doesn’t it know?
Well, first, the answer is: no! When X-Plane builds the roads and draped lines, the texture that is needed may not actually be loaded. It may only be on the todo list of textures that need loading, and if you have orthophoto scenery, that list could be very, very long. There is no guarantee that the texture is loaded before the geometry gets built. If you have a multicore machine, both might happen at the same time!
So the first reason why the road and .lin files require you to declare the size of your texture is: to allow X-Plane to build the mesh on a separate core from the one that loads the texture, for faster loading. Isn’t multi-core fun?
There’s another reason, and it’s a little bit more subtle: you can change the size of your X-Plane textures. Imagine that you get a new graphics card and you decide to “upgrade” your scenery pack. So you double the size of all of your textures, and then go in to photoshop and add more detail.
But if X-Plane were to look at the size of the texture, then all of your .lin files will be wrong! For example, let’s say you have a .lin file with a line from pixels 0 to 16 across the texture. When you double the size of your texture, you’d have to go in and change this to be 0 to 32 pixels across the texture.
But here’s the trick: since X-Plane gets the size of the texture from you and not from the actual texture, you can just leave your .lin file the way it was – with the old texture size and the old coordinates. X-Plane will do the math out and generate correct texture mappings even though the texture size is double.
In other words, the important thing about texture coordinates is that they are self-consistent, not that they reflect the actual texture size. This is because internally all texture mapping is done in ratios.
(So why not just use ratios in the file format? Try entering the size of 10 or 12 lines as ratios and tell me whether you like it. The ability to enter the line coordinates in pixels is to make it easier to set up the line files from the image file.)
X-Plane 9 has a number of recent features to let you customize the exterior lighting of your aircraft; see the wiki for notes and a sample plane.
X-Plane 940 introduced the concept of parameterized lights to support these features. Here’s the basic idea:
Named lights (available for quite a while now) let you add a light billboard to your model that we define. The idea is that since the lights are specified against a real world model (this light billboard should look roughly like a landing light) it lets us upgrade art assets and back the light with the fastest path on the graphics card.
The problem with landing lights is that they are one-size-fits all, and this is particularly problematic for airplanes, where the lights can look quite different in size and angle based on the size of the airplane. Parameterized lights fix this by letting you specify a limited number of parameters in your OBJ. By limiting the parameters that you can set, it means that we can still optimize the light when possible.
I took a few minutes today to round out the list of parameterized lights, and I think there will be 9.46 patch in which we can release them*. When we put 9.46 in beta I’ll update the example plane; the new set of lights will give you parameterized control over the navigation and taxi lights, as well as the generics, beacons, strobes and landing lights.
* We have a few small bug fixes we’ll roll out in 9.46.
In past blog posts I have tried to contrast two very different different approaches to simulation, which I would loosely call:
- “Predictive” (or reality-based). Input data comes from real world measurements, and the simulator predicts the expected behavior based on those inputs.
- “Prescriptive” (or specification based). The input data describes the desired output directly through preset formula.
In particular, when it comes to the flight model, X-Plane is predictive, via blade theory (X-Plane adds up all forces) while FS X is prescriptive (a table describes aircraft behavior).
But – not all of X-Plane is predictive. In particular, the “systems model”, which is a loose term for the modeling of electrical systems, hydraulic systems, and a number of other parts of the plane, is actually prescriptive in X-Plane, while the aerodynamics of the plane are predictive.
To illustrate: when your plane takes off, it leaves the ground because X-Plane has calculated and summed all forces and torques on the plane and has found that it has positive lift. You don’t program this in – you simply provide a number of parts that, under some conditions, influence the lift calculations. (Wings are good for this, btw! 🙂
But when you turn off the avionics master switch, X-Plane does not calculate the electron flow through the wiring harness to the glass PFD. Rather, the PFD is tagged with input data saying it requires the avionics master to be on. The PFD’s behavior with respect to the avionics switch is prescribed, not derived. (If we had a true “wiring editor” in Plane-Maker, it would be different – X-Plane would trace electrical routes and see if enough current makes it to the PFD.
In truth the distinction is a little bit fuzzier. For example, the gyroscopes actually do model the spin of the internal gyro (fail the vacuum system and watch them slowly pick up error like in a real plane) and the electrical system does internal current calculations. But in general the systems modeling is a bit of a mix, mostly prescriptive. This is in contrast to the physics of flight, which are completely predictive.
Periodically I see the question asked: why does the global scenery take up so many DVDs? Or more typically the question is: if it is so big, why is X missing, where X is the detail the user expected to see but did not find.
The size of X-Plane’s global scenery is due to two factors:
- Some aspects of the scenery are very detailed, and this takes up disk space.
- Some aspects of the scenery are computed ahead of time, not by X-Plane, and this takes up disk space.
Big Data
A few data sources make the scenery pretty big:
- The scenery is generated from 90m SRTM data for the entire world.
- US scenery includes the entire US road grid.
- Coastline data is fairly detailed in the US and for most oceanic coasts.
In other words, part of the size of the scenery comes from having reasonably accurate topography and coastlines everywhere.
Precomputation
The other source of file size is that X-Plane precomputes aspects of the scenery to reduce load on X-Plane while you fly. (We do this to improve frame rate.) In particular, the scenery uses a class of algorithms that are expensive to compute, and thus we compute them ahead of time and save the result (using up file space).
- Land class changes not on a regular grid, but along iregular polygonal boundaries following the shape of the terrain. This produces much more natural terrain transitions in the mountain, but requires more storage.
- “Auto-Gen” forests and buildings don’t follow a grid – rather, they fit into the irregular spaces made by vector roads and water. This fitting process is too slow to run inside X-Plane, so every auto-gen building and forest area must be pre-computed and saved.
Room To Grow
One interesting side effect of saving the end results of building locations (“pre-placement”, what X-Plane does) rather than the formula for how to place them (“auto-gen”, what FS X does) is that we can make the placement algorithm for buildings significantly smarter without any increase in file size or decrease in frame-rate. Having already eaten the cost of putting every building into the DSFs, we can make those locations better without hurting performance.
That algorithm to pre-place buildings also can have access to source data that isn’t available in the final DSF, allowing for effects that might not be possible in an auto-gen system.
I have blogged in the past regarding the rendering settings in X-Plane, but this seems to come up periodically, so here we go again. Invariably someone asks the question: “what computer do I have to buy to run X-Plane with all of the sliders set to maximum?”
I now have an answer, in the form of a question: “How hungry do you have to be to clean your plate at an all-you-can-eat buffet?”
There is no amount of hungry that will ever be enough to eat all of the food at an all you can eat buffet – you can always ask for more. And when it comes to rendering settings and global scenery, X-Plane is (whenever possible) the same way. You can always set more traffic, more birds, more objects, more FSAA.
Now the all-you-can-eat buffet doesn’t have infinite amounts of food in the building – just enough that they know that they won’t run out. And X-Plane is the same way. There is a maximum if you set everything all the way up, but we try to make sure that no one is going to hit a point where they want more eye candy but they’ve maxed out the settings. Eat all you want, we’ve got more.
Why on earth would we set up X-Plane like this? The answer is choice.
If you go to an all you can eat buffet, you can fill up on nothing but potatos, or you can have five pieces of chicken. It’s up to you. X-Plane is the same way – you decide if you want objects to be visible farther away or more densely. Would you rather have roads or trees? Birds or high frame-rate? You decide!
Not everyone’s appetite is the same, and not everyone’s taste is the same. This is very true when it comes to flight simulation. There are huge variations in hardware capability, target framerate (some users don’t mind 20 fps, some demand 80 fps) and in what part of the visual experience people care about most (objects vs. FSAA vs. visibility distance, etc).
Given such a heterogeneous environment, the only way to meet the needs of a wide group of users is to present choice, and make sure that we have enough of everything.
So when you go to set the rendering settings, don’t think that setting objects to anything less than maximum is like only eating half the steak you bought at a steak-house. Rather, the rendering settings are like picking which food from the buffet makes it to your plate. You choose how much you want based on what you can consume, and you pick and choose what is most desirable to you. And like an all you can eat buffet, don’t eat too much – the results won’t be pleasant!
A few days ago Austin made the recently cut X-Plane 9.45 “final” – that is, it is now the version you get when you update or grab a demo. This (hopefully) ends a sequence of 940 patches that represented a mix of fixing last-minute bugs and breaking and then fixing the throttles for a few add-on airplanes.
As always, if your add-on worked in an older version 9 but is broken in 945, please let us know. I believe the compatibility situation with 9.45 is pretty good though.
Will there be a 9.46? I don’t know, but I think the answer is: “probably”. I found a driver bug (occurs only on OS X) we can work around a few days after 9.45 was cut. We maintain a list of fixes, and when it starts to add up, we’ll cut a new patch to address them. Normally a driver bug would get a patch immediately, but from what we can tell, this one is very rare, so we’re not going to fire-drill and cut a new patch 1 day after 9.45 went final.
What kinds of bug fixes make it into these “bug fix patches”? To give an example, I received a report that the “clipping” checkbox on instruments is not preserved when you export an instrument as a text file. That’s the kind of thing we’ll fix in a patch, but we won’t cut a new patch immediately for.
I just finished fixing some bugs with WorldEditor and DSF precision. A WED user was seeing draped polygon tiles exporting with alignment error, and the culprit turned out to be DSF precision. This begs the question, how precise are the lat/lon coordinates in a DSF?
DSFs are based on 16-bit coordinates, for a precision of one part in 65536. Now before you go screaming that 16-bit is dreadful, here’s the key: those 16-bit coordinates are interpreted within an arbitrary sub-rectangle of your tile, called a “pool”. If we only had one pool covering the DSF we’d have 1.5 meter precision. But by having many smaller pools, we can have high resolution within a pool.
All of the current DSF writing tools from Laminar Research are based on DSFLib, and DSFLib will create a number of pools along a pair of offset grids. In practice what this means is that you specify a number of pools across the DSF.
In WorldEditor 1.1dp2 the DSF exporter uses 8 pools. Since a DSF is about 100 km across, each pool is 12,500 meters in size, and the internal resolution of each pool is 19 cm. This is pretty good but there are cases where you can see the limits of precision. The new code (which will be in preview 3 or beta 1) uses 32 pools, for 5 cm precision.
If you use DSF2Text, you can simply use the DIVISIONS command to specify how many pools you want.
WorldEditor’s internal representation is 64-bit floating point, which gives precision better than 1 mm.
I have blogged about this before, but I keep seeing this issue come up in the forums, so I want to go over it again. If you want to effectively tune X-Plane to trade off maximum visual quality with desired framerate, you must first reduce your rendering settings all the way to the bottom, then work your way up. Let me explain with an analogy.
I have fallen off my motorcycle and hit my head, skinned my knee, and broken my arm; the bone is sticking right out of my skin! Ouch! So I go to the hospital and the Doctor examines me. Here is how the conversation goes:
Dr: How does your arm feel?
Me: My arm hurts so much! OUCH!
Dr: And how does your leg feel?
Me: My arm is burning and stinging! Please make it stop!
Dr: Do you feel dizzy or light headed?
Me: Please fix my arm!!!!!!!!
Clearly with a bone sticking through my skin, there is no point in doing a physical examination. My arm hurts so much that I can’t tell the Doctor whether I have any other aches or pain. I feel one thing: the arm.
What does this have to do with framerate? Well, framerate is just like pain. The low framerate you see is caused by only the one worst problem with your setup. If your graphics card is a little bit overloaded, you are a hair short on VRAM, and your CPU is absolutely being killed, then the low framerate you see is totally because of the CPU. The weakest link decides your framerate. And like the Doctor, if we go trying to deal with the VRAM problem, we will see no change because it’s the CPU that hurts the most.
This is what I see over and over: a user is running X-Plane, his framerate is bad, and he has turned some but not all of the settings down. At this point the user is usually pretty grumpy – his visuals now look bad and his framerate is poor.
The problem is that the user hasn’t turned down the setting that really matters. This is why the first thing you need to do in order to tune framerate is to turn everything down, so that you are running with framerate at least as high as what you want for your target value. Then you can turn settings up one at a time and watch which one lowers framerate.
(Don’t worry, you’re not going to stay at the lowest settings. The key is just to always be turning settings up, not down.)
Here are some of the settings I see that need to be turned down but often are not.
- Full screen anti-aliasing. (FSAA) Always turn FSAA down to none. FSAA will kill fps on any graphics card that is fill rate limited.
- Pixel shader effects – every one of these should be turned off to start. And when you do start them, try them one at a time and have the water reflections off – work your way up in small steps. The gap from shaders without volumetric fog, shadows, reflections and per pixel lighting to shaders with all of these effects is huge!
- Turn objects all the way down to default, or even off. If your CPU is the problem, objects could be a factor.
- Leave texture compression on in your “rock bottom” settings. Texture compression improves fps and lowers visual quality, so having the check box be on is the minimal setting.
- Don’t run at a huge screen res or FOV. Run 1024×768 and 50 degrees FOV.
What happens if you turn everything down and you still see 19 fps? Now it’s time to investigate your video drivers and control panel settings. If your setup is even remotely better than minimum hardware, it should scream when all of those settings are turned down. If you still see low fps, check drivers, check control panel settings. There are a lot of control panel settings, for example, that will completely kill framerate.
