When it comes to video cards, I’ve always been in the “don’t spend more than $200” school of thought. My logic is: video card technology moves so fast that paying a lot of money for the “first six months” of any new technology level is very expensive. Bless all of you who are early adopters – you’re helping keep nVidia and ATI humming, but it’s an expensive hobby to main an up-to-date machine.
This is one of my favorite tables (there is a similar one on Wikipedia for ATI). It shows performance of graphics cards and when they came out. Compare the GeForce 7950 GT2 and the GeForce 8800 GTS. If you want 24,000 MT/S of fill rate, you could buy a top-of-the-line two-cards-in-one-via-SLI 7950, but if you waited six months, a SINGLE intermediate-speed 8800 would give you the same thing while supporting DX10 shaders (e.g. geometry shaders, instancing, and all that awesome stuff). The 7950 GT2 apparently retailed at $600+, which was a real discount compared to actually chaining two separate 7950’s together (that’d get you up around $850). Look on newegg.com and you’ll see that GeForce 8800 prices aren’t that expensive (compared to an SLI combination). And the 7950 GT2’s come down a lot from what it used to cost.
For another datapoint, compare the Geforce 7600’s to the GeForce 6800’s. The 6800 was the monster card when it came out, putting nVidia back in the number one spot. But the next-generation’s intermediate range cards can do what was top-end before. (The 7600 can be had for a little over $100. Compare that to several hundred for the 6800 ultra about one year earlier.)
Simply put, you pay a huge premium to get a given performance level when it’s new and top-end. Wait one generation of cards (by buying last-year’s top end cards or this-year’s middle-range cards) and you save a lot.
It’s in this context that I don’t believe that SLI makes a lot of sense. In an environment where (IMO, and my opinion only) the top-end video cards are already expensive for what they do, SLI simply makes the situation worse, by allowing you to spend double what the already-high-end cards cost to get performance that will be available in one card in the next generation.
To do the math, does it make sense to spend double the price on your video card to extend its useful life by six months? Only if you intend to change cards every six months.
(nVidia makes an argument that SLI allows developers to preview the next-gen hardware, and this is true. My strategy is different: simply run X-Plane slowly and assume that the next-generation hardware will go faster.)
I don’t feel good about criticizing nVidia and ATI because overall I feel that their products provide an extraordinary value at a very good price, and the growth of performance in video cards has been astounding. Todays cards just hit it out of the park.
But to me SLI and CrossFire strikes me as a solution looking for a problem. They solve the problem of making the most expensive cards more expensive, but I don’t think they’re the best way to spend money on a flight simulation system. (Better might be to not buy at the “SLI/Crossfire” level of video cards, meaning spending $700+ on your video cards, but rather to go down a level and upgrade your motherboard/CPU more frequently.)
Some users email me asking for video card recommendations, in particular whether to buy an SLI/Crossfire configuration. The bottom line is, it depends on how much you value your money vs. your graphics card performance. If money is on object, and you want maximum speed, SLI configurations will provide the fastest performance (by some marginal amount). I believe that a good value lies below $200.
On the other side of the equation, I do recommend that everyone spend at least $100 if you’re going to buy a video card at all. Below $100 the price cuts come from remaindering really old inventory and removing parts from the card to save cost. For the savings of $25 you might lose half your card’s performance or half of its VRAM when you get down to the really cheap cards.
The other thing I tell users is the truth: no one at Laminar Research has an SLI system, so the reports we get on SLI come from users. Some users have told us they’ve gotten some benefit at very high FSAA levels. But at this point a single 8800 wll do the same thing. And SLI doesn’t address CPU speed at all. Consider this list of features – nothing on the CPU side will get even remotely faster with SLI.
And in full disclosure: my two Macs have a Radeon X1600 Mobility, a Radeon 9600, and a GeForce 5200 FX sits on the shelf for testing purposes. (This isn’t intentional bias toward ATI, it’s what Apple ships.)
I can’t say enough good things about Jonathan Harris (Marginal) — his work on X-Plane has been fantastic, he is one of the most advanced third party scenery authors I know of, and when he sends us a bug report, it is usually so perfectly patched up that I’m looking at the bad line of code in minutes! (One of these days I’ll post one of his bug reports — he always isolates the bug in a simple package that makes it very clear, with no extra “stuff”.)
He emailed me a while ago with some questions about layer groups, and I saved them to rewrite into a blog entry. A little bit of background:
X-Plane 850 and 860 introduce the concept of “layer groups”, which provide a way to control the draw order of scenery to some extent. Objects naturally fall into a layer group based on their type (e.g. objects go into the “object” layer group by default, and runways always go into the runway layer group). However, some scenery elements let you customize their layer-group placement in two ways:
- By changing which layer group the element goes to entirely, or
- By providing a “bias number”, which indicates that within the catagory of scenery elements, this one must be drawn early or late.
Layer groups let you do a number of useful things:
- Make sure that polygons and objects are drawn under runways or over taxiways when needed.
- Make sure that runway markings with polygon offset are drawn before 3-d objects.
Simply changing the order of objects in the DSF is not a reliable way to control draw order! Layer groups are. You can read about layer groups in the OBJ8 spec.
With that in mind, some Q and A. (I will elaborate on my answers from what I originally sent Jonathan.)
J: I assume that objects and polygons within a single layer can be drawn in any order – ie there’s no defined drawing order between different scenery types.
B: You assume correctly! Within a layer group, X-plane is free to reorder to improve fps. So you cannot rely on the draw order of any two scenery elements without assuring that they are in different layer groups, either by using different group names, or different relative offsets.
J: But is there are defined drawing order between objects/polygons and apt.dat-generated scenery?
B: Yes because airport scenery goes into specific layer groups! (In fact, all scenery has a “default” layer it goes into, and they usually vary by type of scenery element.)
J: eg if I have an object or polygon with ATTR_layer_group runways 0 will it be guaranteed to be drawn after the runway?
B: You’re close. The runways go into the runways group so
ATTR_layer_group runways -1
will always be before runways and
ATTR_layer_group runways 1
will always be after.
ATTR_layer_group runways 0
is the default layer group for runways, so your object or polygon would be in the layer group with all of the other runways, and X-Plane would be free to change the order amongst your object and runways in any way that would optimize framerate.
J: If not, is there any other way to insert objects and/or polygons between the taxiways and the runways?
B: The numeric offset is provided for this. The “spacing” of the layer group numbers is such that you can have up to 5 groups before and after each “named” group. So anything from runways -5 to runways +5 is fair game. (In other words, you can separately control up to 5 different “layers” of elements with a well-defined order for any layer group name.)
A few days ago, Austin posted part of an, um, “animated” discussion between himself and an author regarding blade-theory vs. table-based flight models. (You can find it on the xplane-news yahoo group message archive.)
I’d like to ignore the whole “my flight model can beat up your flight model” thread and look at one of the side effects of physics vs. table based flight models.
In this previous post I commented on the nature of specifications in a flight simulator.
– Some data simulates real-world data. (“Reality-based”) The sim has open authority to interpret this data for maximum “quality” and the standard is “how close to reality are we”. The specification clearly sites reality as the authority on behavior.
– Some data is arbitrary and has a clearly defined interpretation. (“Specification based”.) The behavior of the computer program is unambiguous.
What I find interesting is that a blade theory flight model is a “reality-based” flight model; a table-based flight model is a “specification-based” flight model.
What this means is that, just like reality-based specifications in the scenery system, you can’t tune your flight model in X-Plane to achieve a desired end result without understanding the real-world meaning of the parameters you are changing, or you risk a compatibility problem with future versions of X-Plane.
Imagine that, for some reason, your plane seems to feel sluggish when turning. So you increase the area of the control surfaces and the problem goes away.
You can’t do that with X-Plane’s flight model! The area of the control surfaces mean something other than “a variable you can change to affect how the plane turns”. They have to match how the real-life airplane is built. If you increase the area, straying from reality, to “fix” a problem, what really happens is you create a new problem later when X-Plane goes to simulate your model.
Simply put, if you put intentional errors into your plane’s flight model to compensate for limitations to the sim, any improvement in the simulation accuracy of X-Plane is almost guaranteed to make your plane fly worse in the future.
So one of the important differences between a table vs. blade-theory flight model is how you talk about “bugs”. If your plane doesn’t fly the way it used to in a table-based flight model, that’s probably a bug (well, depending on how interpolation is done). In a blade-theory model it’s not a bug per se.
In a table-based flight model, how the real plane flies is moot – the table is king. In a blade-theory flight model, if the real plane flies differently and the input parameters of the plane are the same, it is a bug, or perhaps a design limitation.
If your X-Plane is framerate low, or you want to increase your rendering quality, you might think “time for a new graphcis card But is it?
Some rendering settings actually tax the CPU more than the GPU (graphics card). Here’s a simple rule of thumb: if you increase the setting (and restart X-Plane) and your frame-rate does not go down, a new graphics card isn’t going to make it go up!
For example, if you have one of those new-fangled GeForce 8800s, you may have noticed that when you turn on FSAA the framerate doesn’t dip at all. That’s because the 8800 is insanely overpowered for X-Plane (at normal monitor resolutions) and has plenty of extra capacity that will be sitting idle on an older PC. When you turn up FSAA, you are simply wasting less of the card’s excess capacity. It goes without saying that if there were a card faster than the 8800, it wouldn’t improve your fps any more than the 8800, it would simply be even more bored.
Here’s a rough guide to which features tax the CPU vs GPU:
CPU-Intensive
- World Level of Detail
- Number of Objects
- Draw Cars On Roads
- Draw Birds (not that expensive for modern machines)
- Draw Hi Detail World
- World Field Of View (wider view means more CPU work!)
GPU-Intensive
- Texture Resolution (requires more VRAM)
- Screen Resolution
- Full Screen Anti-Aliasing (FSAA)
- Anisotropic Filtering (most cards can do at least 4x)
- Draw Hi-Res Planet Textures From Orbit
- Cloud Shadows and Reflections (not that expensive)
- Draw Hi Detailed World
A few specific framerate-optimization warnings:
- FSAA is equivalent to a higher screen resolution – that is, running at 2048×2048 and no FSA is similar to running at 1024×1024 and 4x FSAA. Both of these tax the video card with virtually no CPU increase. This is probably the only setting that can be helped only with a video-card upgrade.
- Texture resolution: do not worry if the total size of all textures loaded is larger than the VRAM of your card. To find out if more VRAM would help, measure frame-rate with your normal settings, with texture resolution down a notch, and with anisotropic filtering down a notch. If turning texture resolution down increases fps more than turning down anisotropic filtering, more VRAM may help. Machines with faster graphics busses (like PCIe x16) will be less sensitive to VRAM.
- Most Important: do not ever turn “World Detail Distance” beyond the default setting – you will simply destroy your fps and chew up your CPU for no benefit. I strongly recommend trying “low” for this setting – if you like a lot of objects, this setting can make a big difference in performance.
- The number of objects is virtually always a factor of how fast your CPU is, not your GPU — that is, most GPUs can draw about a gajillion objects if the CPU could only get through them fast enough. If you are unhappy with the number of objects you can draw, do not expect a new graphics card to help – it probably won’t.
- Cars on roads hurt fps on machines that don’t have the fastest CPU.
- Draw Hi detail World is doubly dangerous – it uses both the CPU and GPU. Quite literally this is where we stash “luxurious” options. Everything this checkbox does chews up framerate. (If these options didn’t, we’d leave them on all the time!) So you should not use this option if you aren’t happy with fps, if you don’t have a fast CPU, or if your graphics card isn’t that modern. (HINT: if your nVidia card has “FX” in the title, don’t use this!)
Start with the default settings and experiment – turn a setting up one notch, then restart, then turn it down and try another. Different machines will be faster for some things and slower for others.
EDIT: one user correctly determined (by observing CPU utilization relative to settings) that puff-style 3-d clouds bottleneck the GPU, not the CPU! This was not what I expected – when Austin originally wrote that code, our measurement indicating that sorting the puffs from far to near taxed the CPU a lot, making this CPU-intesive. At the time the old Rage 128s would also get bogged down by filling in translucent puffs as you flew right into the thick of the cloud.
Times have changed and neither the sorting nor the alpha-drawing is even remotely expensive on a modern machine. So I was surprised to see the CPU not being used. After some investigation, it turns out that while the CPU and GPU have gotten a lot faster over time, the communciations channel between them has not. The result is that they both do their jobs really quickly, and as a result clog up the communications channel…the CPU simply can’t talk to the GPU fast enough to get the clouds out.
This is a great find by this user, as this is something that didn’t matter on old machines, but can be optimized in the future for new ones.
If you have a dual core Intel Mac, OS X 10.4.9, X-Plane 8.60 and an Intel Graphics chip, try running the sim with this command-line option:
–use_threaded_ogl
You can read about how to use X-Plane with command-line options here.
This series of posts will discuss how the LOD system works for objects. Understanding LOD is very important for tuning the performance of custom scenery that uses either very complex objects, or a very large number of objects.
Authors View vs. X-Plane’s View
A “level of detail” for an object is a complete representation of the model with complexity changed to fit a viewing distance. In other words, LODs are copies of your objects, some of which have been simplified so they will draw faster when far away.
Each LOD for an object contains a viewing range, indicating for which range it is appropriate to use this LOD.
An X-Plane object can have LOD information, via the ATTR_LOD attribute. If it does, it may have one or more “LODs” – that is, separate representations of the same object.
If an X-Plane object has no ATTR_LOD command, X-Plane turns the entire object into one LOD by automatically calculating the viewing range based on the size of the object. (I’ll discuss this in more detail in later posts.)
This last point is important because it means that, to X-Plane, every object has at least one LOD. If an LOD is not provided by the author, one is created!
Picking an LOD
When X-Plane draws an object, it measures roughly how far away it is and picks the LOD within the object to draw. This can save some frame-rate but isn’t a cure-all.
– The cost of animation and attributes is based on the LOD drawn. So if you have an object with a lot of animation that is not visible a long way away, using a second, simpler LOD with no animation will help framerate because X-Plane won’t evaluate the animation when the complex LOD is not drawn.
– The cost of moving the texture to the graphics card is incurred no matter what LOD is picked, so you don’t save on “working set” (that is, the effective amount of VRAM X-Plane needs) with LOD. If your object has a huge texture, you pay that cost any time it is drawn.
– The cost of the number of triangles in the model is partly saved by using a simpler LOD, but it is partly global to the entire object. The problem is that all of the geometry coordinate data for objects is kept together in one giant glob. So when the tiny simple version of your model is being drawn, X-Plane may be shoveling the complex version to the card anyway.
This last point is important: making more LODs may actually increase the total amount of geometry data and make performance worse. Therefore while it may help a lot to have a second LOD that is much simpler, having 10 LODs, each slightly simpler than the last will probably hurt performance. Be sure to try your objects on a computer that doesn’t have a lot of free VRAM to see the effect of more LOD!
Don’t Draw That Object
While you can save some frame-rate by having X-Plane draw a simpler LOD, the true power of the LOD system happens when an object is so far away that none of the LODs apply. For example, if my object has 3 LODs from range 0-1000 meters, 1000-3000 meters, and 3000-6000 meters, then once the object is over 6 km away, X-Plane simply doesn’t draw it at all!
Not drawing an object is great for framerate. Not only do we save the time on the animations and attributes, but X-Plane never has to process the texture or geometry data, and that’s where the real framerate win comes from. Therefore the most important question for object LODs is “what is the maximum LOD” – that is, what is the farthest distance before X-Plane can stop drawing your object. X-Plane is pretty efficient at recognizing cases where objects, or even whole classes of objects, are simply too far away to draw.
(Consider the runway lights with the new “high detail world” setting…X-Plane places an object for every single runway/taxiway light, of which there are almost 10,000 at Chicago O’hare. But since the maximum LOD for these tiny objects is only 500m, X-Plane then eliminates the vast majority of the objects very early on and doesn’t bother to draw them, keeping framerate up.)
To draw a stupid analogy: the shorter the grocery list, the quicker your shopping. But if your grocery list has NO items and is totally EMPTY, you don’t even have to drive to the store, which really saves you time.
In the next part I will discuss world level of detail and maximum LOD didstances.
Here’s one of those little details that probably isn’t in the scenery docs but needs to be: if you are making base DSF meshes and they use water (the special terrain type “water”) it must be on the bottom of the stack of terrains – it can’t be used as an overlay!
I just finished an example scenery package that shows how to place orthophotos using .polygon files. Check out the scenery website (look under tutorials) to download the package and also read the illustrations. (This is an experiment: this is more of an annotated scenery example tha a true step-by-step tutorial.)
The basic anatomy of an orthophoto-in-a-polygon is:
- A PNG file contains the orthophoto. (In the case of our example, ksbd_alpha.png.)
- A .pol file references the PNG file and defines the physical properties and layering information. (In the case of our example, ksbd.pol.)
- An overlay DSF references the .pol file. (In our case this is +34-118.dsf.)
- The DSF overlay contains exactly one usage of the .pol file, with a polygon parameter of 65535 (a flag to indicate that texture coordinates are in the DSF) and each vertex of the polygon contains texture ST coordinates.
This pattern is actually the same design pattern that is used everywhere in the X-Plane scenery system:
- PNG files are never used directly by DSFs, they are always referenced by some kind of “definition” file, like an OBJ, .pol, .ter. Sometimes the definition file has a lot of info (like an OBJ, which contains a 3-d model), and sometimes they just contain some basic attributes (like a .ter or .pol file, which contain info for the physics engine).
- The artwork definitions are always separate from the DSF, so that they can be reused easily in a lot of DSFs.
- The DSF says where the polygon goes and the .pol file says what it looks like, just like the DSF says where an object goes and the OBJ says what it looks like.
One decision I made early on in my work on the scenery system was to stop using “magic file names”. Prior to X-Plane 8, in a number of cases it was enough to add _LIT to the end of a texture file and a lighting mask would appear. In all modern file scenery format, there is a texture command (usually TEXTURE_LIT) to add this information.
Now this is probably more confusing to new users, and certainly a little bit confusing to anyone who was used to X-Plane 7. To some extent my goal is to have most scenery files be generated automatically – we’re still a long way away from that, so my decisions to prefer extensibility to ease-of-use in the low level formats cause problemes for now. (But try the new AC3D X-Plane plugin version 3.0 – with UI to edit all X-Plane properties, does it matter anymore whether OBJ8 files are easy to read? We now have a real UI for editing X-Plane specific properties.)
In the case of file formats my concern was extensibility. There are only so many “tricks” that we can possibly cram into a file name, and the more we try to make the file name do, the less simple it becomes. When textures can only be “lit”, tagging _LIT on the end is simple, and haivng to add TEXTURE_LIT can be annoying. But since then we’ve also added layering information and physics information. Imagine ksbd_LIT_AIRPORTS_-1_GRASS.png. Now we’re getting into the domain of confusing file names.
Take a look here at some of the things we’d like to someday do for textures…seasonal textures would really make the texture names crazy. (MSFS9 accomplishes this using four seasons, which keeps the names simple…but what if we want to customize the time range for seasons?)
And dataref-controlled textures? Well, you can’t encode a dataref in a file name – the / is reserved!
So all of these text files (.OBJ, .pol, .for, .ter, etc.) provide extensibility – they let us add new features to the way that DSF content is viewed without requiring cahnges to the DSF file format itself.
Since this blog post has gone off into a philosophical rant and the real info is in the tutorial, let me drift totally off subject by mentioning that while you’re looking at tutorials, take a look at Kriss’s tutorial on OBJ8 animation using the new AC3D plugin. If you’ve tried using the old system of animation (by typing cryptic goo into the AC3D object naes) you’ll find the new plugin will let you work a lot faster!
Before I do this, an important disclaimer: we want you to use the .pol files that are found in the default scenery using the library system, not to copy the files! I encourage you to look inside the X-Plane resources folder to see how the system works, but don’t copy a file if you can use it via the library; the library system saves loading time and VRAM.*
With that in mind, here’s a line-by-line of what we might find in a .pol file. This one came from my X-System folder in Resources/default scenery/820 world terrain/pol/apt_desert_hot.pol. We have:
A
850
DRAPED_POLYGON
This is a standard header for a .pol file, which defines the look of a draped polygon.
TEXTURE ../textures/apt/apt_desert.png
This defines what texture the polygon will be drawn with. In this case, we are using our apt_desert.png file, found elsewhere in our package. (The double periods, .. move us up to a higher level directory. This is legal within a single scenery package.)
SCALE 500 500
This defines how large the texture appears in the X-Plane world. In this case, the horizontal span of the entire texture (before it repeats) is 500 meters (the first number), and the vertical span is also 500 meters.
NO_ALPHA
This tells X-Plane to ignore the alpha channel on the PNG file. Often PNG files used for base textures have alpha channels consisting of noise, for the purpose of creating terrain transitions. Since seeing this alpha isn’t desirable in an overlay polygon, this command can be used to strip out the alpha. This lets us use one PNG file for two purposes.
SURFACE dirt
This defines the physical surface properties of the polygon. In this case, it is “dirt”, which for X-Plane means some dust puffs will come off the wheels and your plane will clonk around. See the OBJ8 specification for a list of all possible surface types. (These names match the ATTR_hard command in X-Plane 8 objects.)
LAYER_GROUP airports -1
This defines where in the drawing stack to draw. In this case, we will draw one layer under airports (-1 means under, +1 would mean over). This means that this surface will be seen right below all aspects of the airport, but above regular terrain, which is what we want. The names here correspond to the same names you’d find in an OBJ8 in ATTR_layer_group – see the OBJ8 spec for the complete list of names.
* Basically any time there are two PNG files on disk, the VRAM is allocated twice, but any time one PNG file is referenced multiple times, the VRAM is shared. Since the library system lets you share other packages’ resources, using it almost always means a savings in VRAM.
In my previous post I discussed airports using the apt.dat and polygons and when to use custom artwork in a DSF.
One problem with the X-Plane scenery system (and a topic for another blog) is that, because scenery is fully pre-processed*, introducing a new airport won’t put grass underneath the airport surface area. (Only airports that existed at the time the global scenery was created have grass underneath them.)
To make an airport there are two types of processing you need to do to the underlying area:
- Flatten it, if it has bumps. Since our mesh comes from SRTM, which is “first return” (meaning whatever the radar bounces off of first, that’s the height of the terrain, even if it’s a tree top), it often is quite bumpy.
- Change the underlying texture to something appropriate for an airport.
With X-Plane 8.60 (in RC as of this writing) you can do both! I’ve blogged about airport flattening (and why it isn’t very good) before; today I’ll try to describe how you can fix the base terrain.
You can cover the base mesh with a draped polygon in a DSF overlay. All you need to do is:
- Create a .pol file that references a PNG for the texture and describes the resolution it will be applied at (i.e. how many pixels per meter) and
- Use that .pol file in a DSF with a polygon in the overlay to describe where to put that texture down.
In X-Plane 8.60 we provide .pol files for you for all of the basic airport terrain textures. If you open the file Resources/default scenery/820 world terrain/library.txt you will find the library listing for the global scenery terrain. Toward the bottom you will see a section like this:
EXPORT lib/g8/pol/apt_sdry_cold.pol pol/apt_sdry_cold.pol
What this means is: the library path lib/g8/pol/apt_sdry_cold.pol is apped to the file pol/apt_sdry_cold.pol in this scenery package. You will see a fairly large number of .pol files on the left. Basically these represent the basic “environments” that an airport can exist in.
So to make an overlay DSF that has wet cold grass underneath it, make an overlay DSF with a .pol file using the path “lib/g8/pol/apt_wet_cold.pol”.
EDIT: Important — there are actually four .pol files in this library that do not work!! They are:
apt_desert.pol
apt_dry.pol
apt_grass.pol
apt_sdesert.pol
You will know they don’t work because your scenery will not load with them. Basically, they are accidental hold-overs from a previous naming scheme for airport terrain, but were never deleted. Note how they name only an amount of rainfall (except for apt_grass, which tells us nothing). The rest of the files are named things like apt_sdry_cool, which gives us both temperature and rainfall. This 2-dimensional climate grid (with rainfall and temperature) is how most of the X-Plane terrains are organized.
Why use the library system to do this? Three reasons: copywrite and VRAM, and compatibility.
One advantage of using our library is that it gives you a way to use our artwork without copying our artwork. Remember that you cannot copy the X-Plane PNG files into a custom package and then sell it – it’s a violation of X-Plane’s EULA. But you don’t need to! You can simply use the .pol file and X-Plane will load up the appropriate PNG files.
This is also a win for VRAM. If the wet grass texture is being used in the base terrain (for an airport that has wet grass underneath it from the global scenery) and in your overlay DSF (via the library .pol file) X-Plane will only load one copy of the texture, saving VRAM, speeding up load time, etc. If you copied the PNG file, besides being a EULA violation under some circumstances, you’d also be wasting VRAM. So the library system is more efficient!
Finally, by using our polygons, you ensure that your base grass will match the rest of the scenery system. If we update the look of our grass, because the library .pol files reference our artwork, you will see the same thing in your airport that we have in the default ones.
(Of course my warning from last week applies: if you use a wet airport grass polygon for something other than wet airport grass, then in the future our improvements on the artwork may make your scenery look strange. With these airport polygons we are aiming for “as much like an airport as possible”, not “as much like 850 used to look as possible”!!)
* By this I mean, all the decisions about how scenery will look are made ahead of time, so the look of scenery does not respond to the combining of multiple packages by changing the underlying packages – only by superimposing the new ones on top. Thus a new apt.dat layout does not change the underlying terrain from urban and forest to grass. This is a design trade-off; full pre-processing has both good and bad aspects.
