The billboarding scheme for cloud puffs has been rewritten for X-Plane 10; for the most part you should not see puffs spinning or reorienting themselves as you move the camera. However, while poking at the cloud puff shader, I managed to induce this picture on the left. The weather system makes some of the best bug screenshots.
(The post was originally labeled “bug or tornado”…I changed it because it seemed obnoxious after what happened in Joplin, MO – just me being a jerk from the East Coast. A few days later we were hit by a series of Tornadoes fairly close to home.)
Bad preferences have become a superstition in the X-Plane community. If anything goes wrong, the first thing anyone says is “delete your preferences”. This often “fixes” the problem – in that it undoes all of your careful settings and changes about 100 different things, one of which changes enough behavior to fix the problem. It’s the medical equivalent of curing the common cold by transplanting every single organ.
Of course, every now an then the preferences file is the problem. It turns out that X-Plane 9.6x and 9.31 use the same version ID for the binary preferences file, and yet they use different binary preferences file formats. This was a screw-up on our part, and the result was a hang on start for 9.6x users if they had their old 9.31 preferences laying around. In this case, nuking preferences really was the problem. (Thanks to Andy for getting me the files to see this “in the lab”!)
Send Me Your Preferences!
What is frustrating about the 9.31/9.61 preferences bug is that people have known about it forever, and yet I only received a real bug report about it this week. Part of the problem is how people cope with these bugs: by deleting their preferences.
Don’t delete your preferences! Once you delete the preferences files, they are gone! If there was something wrong with them, we’ll never know.
Deleting your preferences is like burning all of your belongings when you get a cold: the Doctor won’t know what bacterium or virus you have because you destroyed every instance of it!
You don’t have to delete your preferences. You can simply move them out of the preferences folder onto your desktop. This has the same effect as deleting them: X-Plane will not find them in the new location, and will start up with its default settings.
What if moving preferences fixes the problem? Well, now you have two sets of preferences: the old “sick” preferences on the desktop that cause a problem and the new “rebuilt” ones that X-Plane made when you re-ran.
At this point you can now send me a bug report. It might go something like this:
You: Hey Ben, I was getting a crash on start. I moved my preferences files out to the desktop and it fixed it. Here are the bad preferences and here are the good ones, in two zip files.
Me: Thank you! That’s great! I will look at the two sets of preferences to see what changed. If there’ a sim bug I can identify it and find it.
You: So…do I get any kind of reward?
Me: Only the good feeling of knowing you’ve helped your fellow X-Plane users.
You: Screw you! I’m going to go use Google Earth Flight Simulator.
Okay, that didn’t go quite as well as I had hoped. But my take-away point is this: if there is a real problem with the preferences system, such that deleting preferences is necessary, we want to look at the files and fix it in the sim! In the long term this will lead to less need to delete preferences, which will save a lot of users a lot of re-doing settings.
Why Do Preferences Files Matter?
Why does moving your preferences files out of the way (so X-Plane can’t find them) sometimes help? There are a few causes that I’ve seen:
Incompatible or corrupt binary files. Sometimes the preferences files actually contain junk, although this is rare. In some cases, we don’t handle the preferences file version change and we need to fix the version check code (this is what we’re fixing in 970).
Sometimes a single particular setting is problematic for a particular machine. For example, your machine might have a driver problem that causes it to crash when “per pixel lighting” is on. If you remove the preferences and the default is to have that setting be off, then you “fix” the problem. In this case, a comparison of the “bad” preferences with the default ones can reveal settings that might be the problem.
Sometimes settings can be set while you fly, but cause problems when the sim starts with the settings turned on. This is rare, but with tweaky graphics drivers we sometimes do see this behavior. Sometimes a setting takes effect on restart, so it’s not until you restart with the new setting that the preferences file causes problems.
Either way, having the “bad” preferences to inspect is critical to catching any one of these cases!
In testing some ATC stuff today, I was curious why I saw smoke coming from the water on the left side of the runway. As I got closer, I found a KC-10 rising from the ground like a mighty Phoenix….struggling to get out of the controlling grips of Air Traffic Control. Ben said it reminds him of Free Willy.
And of course the usual disclaimer…the purpose of the video is to have a giggle at the AI plane’s bug…ignore the ugliness of the rest of the situation. The colored lines are used for debugging aircraft routing issued by ATC.
What is the limit to how precisely you can build scenery in X-Plane using WorldEditor?
In this picture, I created a runway “OBJ” exactly the same reported size of the runway, in the same location and orientation in WED. The windsocks are also placed on the exact corners of the runway in WED. This is a typical “MRI” scenery pack – that is, a test scenery package designed to show how well/poorly the sim is performing.
So what do we see?
The alignment of the windsocks with the runways is pretty damned good. It might not be perfect, but it’s awfully close.
The alignment of the OBJ runway and the real runway below it is not particularly good – the heading isn’t quite perfect enough to stay aligned over a 10,000 foot runway.
This lack of precision is a design limitation – that is, X-Plane does not try to provide unlimited precision in scenery authoring. (At some point, increasing precision increases file size and processing time, which would have a detrimental effect on overall system performance.)
In particular, X-Plane tries to provide high quality point-to-point matching. That is, given two locations that are both specified by latitude and longitude, X-Plane tries to get them to be as close together as possible.
What doesn’t work well is trying to correlate a specific location (specified by latitude and longitude) with another location specified by relative location (e.g. from this location, go 50 meters to the west).
Generally, the longer the “arm” of relative location, the worse the precision. in this example, the runway is specified by the center of the ends, and the windsock locations are specified directly. Thus the runway corner is on a 25 meter “arm” from the runway end center. We may pick up a little bit of imprecision on a 25 meter arm, but the correlation is good.
By comparison, the object end is on a 5 km “arm” because it is specified by its center location and heading, while the runway end center is specified directly. As you can see, over a 5 km arm, a fair amount of error is accumulated.
Thus we can come up with a working strategy for scenery placement:
When placement precision is important, keep objects small.
When two scenery elements must be locked together, be sure to use scenery elements that can be specified by exact location and not by a metric distance from another location.
“Looks close” in WED only means “pretty close.”
The hardest part of this work-flow is using art assets other than objects for large scale features. But (for example), a draped polygon is better both for precise positioning over a large area and for polygon offset/Z-thrash, so you probably need to use draped polygons anyway.
An author recently asked me what the relationship was between the size of PNG files on disk and the amount of VRAM X-Plane uses to store the PNG file as a texture. I actually get that question fairly frequently, and the answer isn’t totally obvious.
The first and most important point: the size of a texture on disk in an image file is not the same as its size in VRAM, so changing the file’s size on disk doesn’t save you any VRAM. (It does save you hard drive space, which might be interesting if you are building a huge orthophoto scenery, or maybe download size, which can be handy.)
The size of an image in VRAM is a function of its dimensions, the amount of color information, an whether texture compression is on. The formula is basically this:
size = 4/3 * width * height * bytes_per_pixel
The 4/3 term is due to mipmapping – we save progressively smaller versions of the texture to improve the speed and quality of texturing when your image is far away.
Bytes per pixel varies depending on whether texture compression is on:
RGB, or RGBA, no compression: 4 bytes per pixel.
RGB, compression on (or DXT1 compressed DDS files): 0.5 bytes per pixel.
RGBA, compression on (or DXT3/DXT5 compressed DDS files: 1 byte per pixel.
Alpha-only: 1 byte per pixel.
That first point might be a little bit surprising to authors: when compression is disabled, you don’t save 25% for getting rid of your alpha channel. This is because modern video cards round up the texture from 3 to 4 bytes to keep the image size a power of 2. It is still typically a win to drop the alpha channel if you’re not using it: X-Plane can fill the screen faster if it knows that there is no alpha (and thus no blending) and the RGB-only texture will be half sized when compression is on.
DDS File Size
DDS (Direct-Draw Surface) is a file format designed to mirror exactly what video card want in VRAM. As it turns out, a DDS file is a good representation of how much VRAM your image uses, because it is already in the format that the card wants – including the 4/3 term. So if you need a quick and dirty estimate of your texture’s VRAM use at extreme res, the DDS size isn’t a bad proxy. (Note that when LOAD_CENTER is in use, your texture is reduced in size most of the time.)
PNG File Size
PNG file size is unrelated to VRAM used; PNG files are internally compressed. In fact, PNG files have multiple possible internal encoding schemes; utilities like PngCrush try all of the encoding schemes to see which one reduces file size the most. The key is: none of this translates into VRAM savings. PngCrush may make your downloads faster, but it won’t make your add-ons use less VRAM.
When I tore my shoulder playing frisbee and went to the Doctor, he took an X-Ray. Why? Well, that’s obvious: my skin makes it hard for him to directly inspect what was wrong inside my shoulder; the X-Ray shows right through the skin – in that case, it revealed a torn ligament.
It’s the same way with X-Plane. If I want to see what’s really going on in the sim, using real test cases makes life hard. Our artists try hard to hide the underlying mechanism of the sim and instead create a seamless plausible experience. In a good scenery pack you can’t see where one object ends and another begins, or what is a beach and what is an orthophoto.
So my life as a developer is a lot like a radiologist – I spend a lot of time looking at the inside of the sim, and I do this by using test art assets. A good test case is easy to build and clearly identifies the underlying mechanism in the sim. What follows are a few examples of the kinds of test cases we use.
This was one of the original global lighting tests. I needed to see if the lights performed on a large scenery, so I used George Grimshaw’s KBOS, and installed two custom lights. The lights are intentionally primary colors (green and red) so make the blending and mixing completely clear.
This is a test airplane panel to look at the effect of odd-sized instruments and resized panels on pixel clarity. The test case goes through every alignment possibility using art-work that has 1-pixel lines to show blurring. This is a test pack of roads – the pack contains one of every kind of road. The sim is put into a debug mode that labels the road with its code. Using this, we can quickly inspect the entire road art asset pack to see if any road types are buggy. This is a very early version of the roads – one of the original mockups. (That’s why a lot of the roads are missing whole sections.)
Here’s another road test – in this case, there is a custom scenery pack that replaces the cars with colored axes, making it easy to debug the alignment of the cars relative to hills and highways.
These two are test autogen packs; the markings allow me to debug the code that places autogen elements in the sim. The real autogen elements blend together, making it impossible to spot bugs; these ones show alignment errors clearly.
This is an older shot from the weather system with the shadowing vectors on – the lines all over the clouds show the measurement of light going into each part of the cloud. Since clouds can be soft and nebulous, the lines show clearly what would otherwise be hard to visualize.
This test object was built by propsman and exercises approximately 100 different features of the version 10 pixel shaders. In this case, each shader ‘trick’ has a piece of artwork with a clear label to show which part of the shader is where. The real art assets use the shaders in subtle ways that make them hard to debug, but in this case, if the albedo is missing (for example), it’s really obvious.
This is a piece of DSF with the beaches replaced with a beach calibration texture. The beaches are solid and have numeric markings to show which part of the texture is being applied at any given time.
Why show these? My point is this: I spend most of my day looking at the sim with test artwork to see what’s really going on. Many of the art assets I work with are specifically built to test – others have been hacked to find bugs. When I take a screenshot, it is usually to illustrate a particular point about the sim; the rest of the picture probably contains random junk that built up on my hard drive.
So: the marketing people will get you nice pretty screenshots that you can get excited about, but for the time being, most of the pictures here are designed to illustrate only one specific point, and are not at all meant to illustrate what the final X-Plane 10 will look like. You’re welcome to speculate all you want on the rest of the picture, but you’ll be using an X-Ray to look for a skin rash.
a·twit·ter (-twtr)adj. Being in a state of nervous excitement
Anyway, Laminar Research is now on twitter…a bit late to the party but at least we showed up and we brought some munchies so it’s all good. Please follow us and help us spread the word.
In my previous post I suggested a few ways that we will try to ease the introduction of new rendering technology in v10: complete compatibility when the feature is off, close-as-possible compatibility when it’s on, and a simple path to migrate to fully using the new tech.
But: if you’re doing something that should be illegal, we can’t help you. And this can be tricky because X-Plane 9 doesn’t always complain about illegal content.
Propsman just hit a case of this: he ran one of his old plugins on an X-Plane 10 development build* and discovered that (unlike X-Plane 9) it accidentally disabled most of X-Plane 10’s drawing.
It turns out that his plugin wasn’t quite adhering to the OpenGL guidelines for X-Plane plugins. But the particular state he was leaving altered had no visible effect on X-Plane 9. That’s not the case for X-Plane 10. So he’ll have to fix his plugin; the fixed plugin will work correctly with both X-Plane 9 and 10.
Unfortunately, it can be hard to find these kinds of problems without a build of X-Plane that actually has problems when you violate a rule. So if you make a third party add-on, when we finally do have beta builds available, I encourage you to check your add-ons for possible plugin or authoring mistakes that might actually cause problems in X-Plane 10.
*Let me nip this one in the bud before it gets out of control: Propsman is one of five authors who are working on the new art content for X-Plane 10. These five authors have development builds of X-Plane 10. No other authors have X-Plane 10. We are not giving out copies of X-Plane 10 right now. We are not loking for testers. Do not ask me for a copy of X-Plane 10. Do not ask me to test X-Plane 10 early. If you send me an email angling for early access, I am going to mark your email as spam in Thunderbird.
Two more pictures from the test package Tom sent me. These illustrate both some cool things that happen in X-Plane 10 with global lighting and the process of adopting the new features. Our strategy for the new rendering features in X-Plane 10 is 3-fold:
When the new features (shadows and global lighting) are off, scenery that works in version 9 should just work. So users always have the option to turn off the new features, use existing scenery, and get some fps back.
We try to minimize the artifacts between new features and old scenery.
We try to minimize the amount of rework necessary to be fully compatible with new features. For example, switching from ATTR_poly_os to ATTR_draped is a simple search-and-replace job.
The hangar during the day, with shadows with visible skylights, required some bug fixing in the engine, and a new attribute. Normally an object is either blended or not blended. The problem is that a blended object doesn’t let light through for the purpose of shadows. (Even with the “bug”, the hangar with shadows still looked pretty good!)
X-Plane 10 introduces a new OBJ attribute, ATTR_shadow_blend, that will make an object translucent for rendering (note the grime and dust on the windows) but fully transparent for shadows (hence the skylights let light through). The attribute works the same as ATTR_no_blend syntax wise, making the update quick.
(You don’t have to use this attribute, but without it, the sim may not be able to produce quite as nice shadows. Note that this attribute is not necessary for objects marked “glass” on an airplane – they are already handled by a separate process.)
There’s a second bug, visible in both pictures, but more visible in this second picture; the static airplane, which is from version 9, contains a ‘fake’ shadow, consisting of a single quad on the ground via ATTR_poly_os. During the day, we have a double-shadow (both the one generated by the sim and the fake one) and at night the fake shadow does not go away.
With X-Plane 10, this kind of problem (a technique that is useful in X-Plane 9 clashes with new rendering settings) can be addressed via the conditional OBJ commands. The conditional commands let you specify that certain parts of the OBJ are only to be used if the user has shadowing off (or global lighting off), for example. Thus the old shadow works for users who turn off shadows, but goes away when the sim takes care of it. The same technique can be used to have two versions of LIT textures (or even remove LIT textures) when global lighting is turned on and off.
Poor Tom…he sends me his work in progress (at my demand) so I can more easily investigate sim bugs and I turn around and post it to the developer blog.
Tom is working on the new airport scenery library. This is something that Sergio had started to work toward with version 9 (you’ll note that in version 9, a lot of the custom elements from LOWI are actually in the library), but with version 10, the goal is to have a complete set of library art assets. This will facilitate:
Casual authors creating detail at local airports without having to create their own 3-d models.
The X-Plane community to share default airport structures in an open source database, the way we already do for taxiway layouts.
The spill lighting in these pictures comes from version 10’s global illumination – there is a light source at the top of each light pole, and it casts light down onto whatever happens to be below. There are a few reasons why we think this is going to be a great feature for scenery creation:
It’s really easy to use. A light source is part of an OBJ (like light billboards now – in fact, the light source is added to an OBJ using LIGHT_PARAM or LIGHT_NAME) so adding lights is as simple as placing objects in OE or WED.
Since the lights simply throw spill, you don’t have to worry about whether the light is aimed at an object that you can then “draw” lighting onto.
The lights are fully dynamic – if yo animate the object, the light moves. If you drive your airplane under the light, the airplane is lit up.
With X-Plane 9 (or any rendering engine that can’t do global lighting) you have to “bake” lighting in order to create night effects. In other words, you have to draw the light effect onto the textures the light shines onto. With real lights, you don’t have to set up any baking or complex texturing layout, you just place the light and you’re done.
Not having to bake is good for plausibility. In real life, light shines all over the place – in the case of the fuel depot picture, the light illuminates not only the asphalt road, but also the grass nearby. When creating LIT textures, the author is forced to constrain light effects to parts of the scenery that actually have LIT textures. (We had to do this for X-Plane 9 – the lights on the highway don’t ever illuminate the ground nearby, because we can only light the LIT texture.) Global lights give you spill onto all sorts of nearby surfaces for free, without setting up a ton of complex baked textures.
(The global lights do not cast shadows – only the sun does that. The shadow below the airplane at night is a bug – more on that tomorrow.)
The billboarding scheme for cloud puffs has been rewritten for X-Plane 10; for the most part you should not see puffs spinning or reorienting themselves as you move the camera. However, while poking at the cloud puff shader, I managed to induce this picture on the left. The weather system makes some of the best bug screenshots.
-tw
t
