Where Did All of Those Lights Come From?

Javier posted a video of his CRJ on the dev list today. I have not tried the plane, but there is no question from the video that it looks really good. What makes the video look so nice is the careful management of light. Part of this comes from careful modeling in 3-d, and part of it comes from maxing out all of X-Plane's options for light.

But...what are the options for light on an airplane? I don't know what Javier has done in this case, but I can give you a laundry list of ways to get lighting effects into X-Plane.

Model In 3-D

To really have convincing light, the first thing you have to do is model in 3-d. There is no substitute - for lighting to look convincing, X-Plane needs to know the true shape of the exterior and interior of the plane, so that all light sources are directionally correct. X-Plane has a very large capacity for OBJ triangles, so when working in a tight space like the cockpit, use them wisely and the cockpit will look good under a range of conditions.

You can augment this with normal maps in 940. Normal maps may or may not be useful for bumpiness, but they also allow you to control the shininess on a per-pixel basis. By carefully controlling the shininess of various surfaces in synchronization with the base texture, you can get specular hilights where they are expected.

The 2-D Panel

First, if you want good lighting, you need to use panel regions. When you use a panel texture in a 3-d cockpit with ATTR_cockpit, X-Plane simply provides a texture that exactly matches the 2-d cockpit. Since the lighting on the 2-d cockpit is not directional, this is going to look wrong.

When you use ATTR_cockpit_region, X-Plane uses new next-gen lighting calculations, and builds a daytime panel texture and a separate emissive panel texture. These are combined taking into account all 3-d lighting (the sun and cockpit interior lights - see below). The result will be correct lighting in all cases.

Even if you don't need more than one region and havea simple 1024x1024 or 2048x1024 3-d panel, use ATTR_cockpit_region - you'll need it for high quality lighting.

The 2-d panel provides a shadow map and gray-scale illumination masks. Don't use them for 3-d work! The 2-d "global lighting" masks are designed for the 2-d case only. They are optimized to run on minimal hardware. They don't provide the fidelity for high quality 3-d lighting - they can have artifacts with overlays, there is latency in applying them, and they eat VRAM like you wouldn't believe. I strongly recommend against using them as a source of lighting for a 3-d cockpit.

To put this another way, you really want to have all global illumination effects be applied "in 3-d", so that the relative position of 3-d surfaces is taken into account. You can't do this with the 2d masks.

The 2-d panel lets you specify a lighting model for every overlay of every instrument - either:

• "Mechanical" or "Swapped" - this basically means the instrument provides no light of its own - it just reflects light from external sources.
• "Back-Lit" or "Additive" - this means the instrument has two textures. The non-lit texture reflects external light, and the lit texture glows on its own.
  
• "Glass" - the instrument is strictly emissive.

You can use 2-d overlays not only for instruments but also to create the lighting effect within instruments, e.g. the back-lighting on a steam gauge's markings, or the back-lighting on traced labels for an overhead panel.

2-d overlays take their lighting levels from one of sixteen "instrument brightness" rheostats. You can carefully allocate these 16 rheostats to provide independent lighting for various parts of the panel.

The 3-d Cockpit

The 3-d cockpit allows you to specify 3 omni or directional lights. These can be placed anywhere in the plane, affect all interior objects, and can be tinted and controlled by any dataref. Use them carefully - what they give you is a real sense of "depth". In particular, the 3-d lights are applied after animation. If a part of the cockpit moves from outside the light to into the light, the moving mesh will correctly change illumination. This is something you cannot do with pre-baked lighting (e.g. a _LIT texture).

Finally, ATTR_light_level is the secret weapon of lighting. ATTR_light_level lets you manually control the brightness of _LIT texture for a given submesh within an OBJ. There are a lot of tricks you can do with this:

• If you know how to pre-render lighting, you can pre-render the glow from a light onto your object into your _LIT texture, and then tie the brightness of the _LIT texture to a dataref. The result will be the appearance of a glow on your 3-d mesh as the light brightens. Because the lighting effect is pre-calculated, you can render an effect that is very high quality.
• You can create back-lit instruments in 3-d and link the _LIT texture to an instrument brightness knob.
• You can create illumination effects on the aircraft fuselage and tie them to the brightness of a beacon or strobe.

There are two limitations of ATTR_light_level to be aware of:

1. Any given triangle in your mesh can only be part of a single ATTR_light_level group. So you can't have multiple lighting effects on the same part of a mesh. Plan your mesh carefully to avoid conflicts. (Example: you can't have a glow on the tail that is white for strobes and red for beacons - you can only bake one glow into your _LIT texture.)
2. ATTR_light_level is not available on the panel texture. For the panel texture, use instrument brightness to control the brightness of the various instruments.

I have a sample plane that demonstrate a few of these tricks; I will try to post it on the wiki over the next few days.

A Rant On Control Panels

NVidia and ATI provide control panels for Windows and Linux. These control panels let users configure aspects of 3-d acceleration, often in ways that bypass an application's request. This post is a rant about such control panels, but in order to understand the rant, you must understand how X-Plane communicates with a video card.

Stranger In A Strange Land

X-Plane is an OpenGL application. OpenGL (the "open graphics language") is a "language" by which X-Plane can tell any OpenGL graphics card that it wants to draw some triangles.

Think of X-Plane as an American tourist in a far away land. X-Plane doesn't speak the native language of ATI-land or NVidia-Land. But if the hotel says "we speak OpenGL", then we can come visit and ask for a nice room and a good meal.

Of course, if you have ever been an American tourist (or live in a country that is sometimes infested with American tourists :-) you know that sometimes American tourists who speak only English do not get to see the very best a country has to offer. Without local knowledge, the tourist can only make generic requests and hope the results turn out okay.

An example of where this becomes a problem is full-screen anti-aliasing (FSAA). OpenGL allows an application to ask for anti-aliasing. The only parameter an OpenGL application can ask for is: how much? 2x, 4x, 8x, 16x. But as it turns out FSAA is a lot more complicated. Do we want super sampling or multisampling? Coversage Sample Anti-Aliasing? Do we want a 2-tap or 5-tap filter? Do we want temporal anti-aliasing?

As it turns out, NVidia-land is a very strange country, with many flavors of FSAA. Some are very fast and some are quite slow. And when X-Plane comes in and says "we would like 16x" FSAA, there is really no guarantee that we will get fast FSAA (for example, 16x CSAA) or something much slower (like 16x super-sampling). X-Plane is not native to NVidia-land and cannot ask the right questions.

Control Panels

So where do the control panels come in? Well, if X-Plane can only ask for "16x FSAA", how can NVidia give users control of the many options the card can do? The answer is: control panels. The NVidia control panel is made by NVidia - it is native to NVidia-land and knows all of the local tricks: this card has high-speed 5-tap filtering, this card does CSAA, etc.

At this point I will pass on a tip from an X-Plane user: you may be able to get significantly faster FSAA performance with an NVidia card on Windows by picking FSAA in the control panel rather than using X-Plane's settings. This is because (for some reason) X-Plane's generic OpenGL request is translated into about the slowest FSAA you can find. With the control panel you can pick something faster.

Bear in mind that only some users report this phenomenon. My NVidia card works fine even with X-Plane setting FSAA. So you may have to experiment a bit.

It Gets Weirder

When it comes to full-screen anti-aliasing, I can see why NVidia wants to expose all of their options, rather than have X-Plane simply pick one. Still, which do you think is best for X-Plane:

• Multisampling
• Supersampling
• Coverage Sample Anti-Aliasing
• Some Mix of the Above?

Antialiasing has become very complex, and some of these modes will absolutely wreck your framerates.

And FSAA is one of the better understood options. How about these:

• Adjust LOD Bias
• Anisotropic Filtering
• Anisotropic Filtering Optimization

(I know what these do, and you shouldn't be messing with them.)

How about these?

• CPU Multi Core Support
• Multi-Display/Mixed GPU Acceleration

I haven't found any description of what those do, but I have reports from users that setting them to the "wrong" value (whatever that is) absolutely destroys framerates.

Suffice it to say, as an applications developer, the situation is a support nightmare. Users can modify a series of settings at home that we cannot easily see, that are poorly documented, that cause performance to be very different from what we see in our labs, sometimes for the worse, sometimes for the better.

Cake and Pie

On this week's FSBreak, Holger Sandmann described MSFS's scenery system as a "pie" made of layers. This made me think: well, in that case X-Plane must be a cake. It turns out X-Plane has been a cake for a while.

If this discussion seems tasty but confusing, let me clarify. The issue is: which parts of a scenery system are combined when the simulator runs, and which parts must be combined ("baked") in advance.

With MSFS, you can separately install a new mesh, new land class data, new coastlines, and new orthophotos. In X-Plane, all four of those elements must be pre-combined into a single "base mesh". In X-Plane, you have to bake those elements.

This means that you can't make "just" an add-on mesh for X-Plane. You have to create an add-on that addresses elevation and land class and orthophotos and water. Third party authors are quite often not very happy about this - I don't know how many times I've seen "can I replace just the elevation and not the water" posted in forums.

But the Orbx team brings up the exact reason why I thought (five years ago when designing DSF) that requiring all of the elements would be okay: often if you replace one part of the scenery and not another, the results are inconsistent. If you move a coastline but don't adjust the mesh, you may have water climbing up a mountain. If you move a mountain but don't adjust the landuse, you may have a farm at a 45 degree angle.

Cake and Pie

Not everything in X-Plane is pre-baked. As of X-Plane 940, you must pre-bake:

• Land class
• Wide-scale orthophotos
• Terrain Mesh
• Coastlines

You can separately replace:

• All art assets (E.g. change or add types of buildings, replace the look of a given land class for an area).
• All 3-d (forests, buildings, airports, roads*).
• Small area orthophotos
  

Orthophotos are on the list twice. This is because X-Plane has two orthophoto technologies. Draped polygons (.pol files) can be overlaid anywhere, but they degrade performance if used over too large of an area. They are really meant for airport surface areas and other "detail" work. Orthophotos terrain (.ter files) can be used over huge areas with no performance problem, but must be baked.

* Roads are sort of a special case in X-Plane 9: you can replace them with an overlay, but the replacement roads must be "shaped" to the underlying terrain mesh, which means they won't work well if a custom mesh is installed. This limitation in the road code dates back to X-Plane 8, when most of us had only one CPU - pre-conforming the road mesh to the terrain shape saved load time.

The Legacy of the R300

You know it as the Radeon 9700 (and its later cheaper 9600XT, as well as the X300, X500 and X600). The R300 was a definite victory for ATI - when it came out it was vastly superior to the NVidia GeForce FX series, and for a video card it held up pretty well.

From my perspective as an application's developer, however, the R300 has some fine print that makes it difficult to deal with:

• It features only 24-bit floating point precision (as opposed to 32-bit precision in all other shader-enabled hardware from ATI or NV). This is why the reflective water looks square and pixelated up close on these cards.
• It has a 96 instruction limit per shader (as opposed to the 1024 instruction or larger limit in all other shader-enabled hardware from ATI or NV.) X-Plane 9's current water shader is right on the bleeding edge of exceeding this limit. In fact, the water pattern is simplified for this set of GPUs to stay within the 96 instruction limit.
• Since the cards were really quite decent for their time, they are still in field and in use.

(This is a different problem from the Geforce FX/5 series...those GPUs were fully capable of running advanced shaders, they just couldn't do it quickly. In practice this is better for an application's developer, because users are more likely to replace a slow GeForce FX than a capable but internally limited 9700.)

This shows up in X-Plane as a pile of special cases...X-Plane 9 productizes 2.5 renderers:

• A no shader renderer for old GPUs and buggy drivers.
• A shader-based renderer for modern hardware.
• A special-case on the shader based GPU to meet the limits of the R300.

I'm not sure what we will do about this in the future. But as I go through the shader code, this special casing sticks out. We don't usually special case X-Plane for a particular set of hardware, but in the case of the R300, it was for a while so widespread that it made sense to special-case for its limitations.

You Do Not Need to Resave Airplanes - Really!

Let me set the record straight on this: you should not need to re-save an airplane to have it work in a newer version of X-Plane. If you have to do this, X-Plane is broken ... please report a bug!

(In the case of 940 - there is a big fat bug - see the end of the post.)

Here's a little bit more about what's going on under the hood.

When Austin creates a new revision of the acf format (which happens in virtually every major patch), he handles backward compatibility with old aircrafts in one of two ways:

1. He sets the default value of a setting to match the "unused" value in the old ACF file and sets this default value to match the legacy behavior. This naturally initializes all newly introduced functionality to its "backward compatible default" for old airplanes.
2. Where this is not possible, he writes some conversion code that maps old ACF values to new ACF values. This mapping tries to re-create the old systems functionality as closely as possible.

This forward conversion code runs in two cases:

• When you open the airplane in Plane-Maker.
• When you open the airplane in X-Plane.

Plane-Maker will resave the plane in the newest format, with the automatic system updates in place. But this should not be necessary because X-Plane applies the same automatic process on airplane load. This is why you should not need to resave - X-Plane will do the upgrade "on the fly".

Now about that bug...it turns out that 940 incorrectly updates 930 airplanes - the generator amperage is not correctly initialized. This is why 930 planes will run their batteries down in 940. (This bug was fixed in 941 beta 2, btw.)

What was strange was that, because of the way Plane-Maker's code was structured, this code was failing in X-Plane but succeeding in Plane-Maker. This doesn't happen very often (usually the code fails everywhere) but the result was authors noticing that their planes would start working if resaved in PM.

And that brings me back to the beginning of the post. If Plane-Maker can update the airplane but X-Plane cannot, that's a bug! Please report it as such.

I want to make sure people realize that auto-update should work, and that resaving in Plane-Maker should not be necessary. Otherwise authors will start silently resaving their airplane instead of reporting the bugs, and we'll never find them.

(Systems bugs sometimes only show up with a particular combination of systems settings. So while I do hope that we can catch all such bugs in beta, it is always possible that one peculiar model will induce a bug once the sim is released.)

Scenery Compatibility

I had a conversation with a third party developer the other day - he offered to sign a non-disclosure-agreement (NDA) and wanted to know: would custom scenery he made for X-Plane now keep working with the next major version?

Well, no NDA is necessary for that. The simple answer is: yes! (A more complete answer is: if you use the current file formats and not legacy formats from 9 years ago, then yes.) Here's a quick review of how long the various scenery and modeling file formats have been supported:

• DSF: 5 years
• OBJ8: 5 years
• OBJ7: 7 years
• ENV: 9 years
• OBJ2: 9 years

With X-Plane 8 we rewrote a lot of the rendering engine - since then, rendering engine enhancements have been incremental, building on what we have. The next major version will be like that too: the new version will do more than X-Plane 9, but it's not going to drop existing capabilities.

So if you model a building with an OBJ or model a terrain area with a DSF, I expect that it will work unmodified with the next major version.

Modeling Formats in Detail

X-Plane 9 supports 3 revisions of the OBJ file format (X-Plane's modeling format):

• Version 800, which is the current version. Introduced with version 8, the OBJ800 format has been extended heavily, but the format was never changed, so original version 800 objects are not incompatible.
  
• Version 700, which was used with version 7.
• Version 2, whic hwas used for most of the X-Plane 6 run.

The next major version will clearly support version 800, and will probably support version 700 as well.

Do not make new objects in the version 700 format! This format is obsolete, supported only for legacy purposes, and is an inferior format.

We may drop support for version 2 objects - I haven't seen user content with a version 2 object in a very long time. Version 2 objects date back to a time when every polygon was expensive, so content authored in version 2 is likely to look, well, ten years old.

If you do have version 2 content, you can use ObjConverter to convert it to version 800 format. (ObjConverter will also convert version 700 OBJs to version 800.)

Scenery Formats

DSF has been our scenery format for five years now, and will continue to be so. DSF has not had any format revisions - new features are supported by allowing DSF data to be tied to new art asset formats.

I do not know if we will support ENV in the next major version. Supporting ENV is relatively trivial in the code, but whenever there is a bug, we have to fix it in the legacy ENV code as well. ENV supports a 500m terrain mesh, which is completely obsolete by today's standard.

Do not make new content in the ENV format! Like OBJ 2 and 700, it is a legacy format for backward compatibility.

DirectX, OpenGL and X-Plane

I commented about this once a long time ago, but with DirectX 11 cards coming to market, I think some clarification may be in order. What exactly is the relationship between DirectX, OpenGL, your graphics card, and X-Plane?

OpenGL and DirectX

OpenGL and DirectX (well, technically the Direct3D part of DirectX) are both:

• Specifications for how an application requests that graphics be drawn.
• Specification for what will be drawn by a library or video card when those requests are made.

(Okay that's a gross simplification, but it will work for now.)

But DirectX is also something else: it specifies what the hardware must do. That's different from OpenGL. You can have an OpenGL compliant renderer that uses the CPU for everything difficult. It will be slow, but correct.

Extensions and Versions

Both DirectX and OpenGL have version increases, and the new version increase specifies new functionality. But OpenGL also has extensions. While normally new features come in a new spec verison, OpenGL's extensions allow OpenGL implementations to pick up new functionality "a la carte". OpenGL implementers can pick and choose what they add.

When Features Show Up

The trend in game GPUs has been for new features to show up in the DirectX spec first, then become available in OpenGL via an extension, and then make it into a future core OpenGL version. For example, most DirectX 10 features were available once DX10 hardware was released, in the form of extensions.

Sometimes the features flow in the opposite direction. For example, ATI's tessellation technology may make it into the DirectX 11 spec, but is already available as an OpenGL extension.

How This Affects X-Plane

To be blunt, X-Plane is not an early adopter of GPU tech. We are a small company so we have to prioritize our feature work carefully, and there's strong motivation to prioritize a feature that helps all users over a feature that helps only users with certain hardware.

So by the time we code a hardware dependent feature, the feature is usually available in OpenGL...I can't think of any cases where not using DirectX has held us up.

For performance, DirectX vs. OpenGL doesn't really matter - both provide access to the "fast path" of the harware - this is the code path where the GPU runs its fastest. At that point, it's a question of hardware, not OpenGL vs. DirectX.

So X-Plane uses OpenGL, but both are fine for rendering engine development (unless you need to be cross-platform), and both provide reasonable access to video card features for X-Plane.

I Hear You 5-by-5

I don't usually link to non-X-Plane blogs, but I really liked this pair of posts:

http://distractible.org/2009/11/05/top-10-ways-to-annoy-your-doctor/
http://distractible.org/2009/11/08/top-10-ways-doctors-can-annoy-patients/

If you live in the US, you'll definitely appreciate it...the lists are funny and yet have a seed of painful truth in them.

So I decided to try to create my own lists.

I am only tangentially related in tech support - Randy takes on most of the work with some help from Jack. Sometimes very weird reports get escalated to me. (And most of the "let the report sit for a week" comes from me not having time to dig in.)

Anyway, please take these with a grain of salt - they're meant to be funny and exagerated. Most of our users are very, very helpful in tech support calls, despite the fact that, if you are talking to tech support X-Plane is already hosed. And Randy puts forth some amazing acts of patience in the face of some of the requests he gets. My hope here is only to show that there are two sides to the frustration in a tech support incident, and we'll all be happier if we can see the whole picture.

Five Things You Can Do To Annoy Tech Support

1. Be As Angry as Possible

Threaten to switch to Microsoft Flight Simulator. Drop the F word a few times. KEEP CAPS LOCK DOWN FOR THE ENTIRE EMAIL. Tech support definitely responds better to users who are angrier - you don't want to get sub-standard service because you were too nice, right?

2. Omit Information

If you have a second graphics card made in Kazakhstan, over-clocked and running hacked drivers you got off of the pirate bay, don't tell us. If your computer regularly catches on fire, be sure not to mention that. Did you recompile the Linux Kernel yourself after letting your pet monkey edit the thread scheduler? It's best we not know.

Extra credit: report a truly bizarre problem, provide no details on your customized configuration, wait a week and tell us how you fixed it by removing a third party program that "enhances" sound or graphics. Priceless!

3. Don't Include Past Emails In a Thread

Be sure to delete any past information from your email. Change the subject of the email so we can't tell what the original issue was. If you have more than one email, send replies from different addresses. A perfect reply would be "That didn't work" sent from an email address that you haven't used before, without your name included.

4. Email the Last Person You Talked To.

If you just finished up sorting out a shipping problem with the shipping guy, ask him how to create a plugin. If you just got info from the developers about UDP, ask them why your credit card was charged the amount it was charged.

5. Bring Up New Issues In the Middle of Old Ones.

To do this just right, wait until the thread between you and tech support is pretty deep into the meat of a complex issue. Then throw in another paragraph about something else that's gone wrong. To perfect this technique, try to pick a new problem that the person who you are emailing with isn't equipped to handle (see point 4) and keep the report vague (see point 2). You can repeat this technique to stretch out a tech support incident indefinitely.

Five Ways Tech Support Can Annoy You

1. Make the User Reinstall the OS

Reinstalling the operating system fixes approximately 0% of user problems, but it takes a really long time, and is almost guaranteed to screw something else up, usually something that wasn't broken and isn't related to X-Plane. If a user is a little bit annoyed, this is a great way to pour gasoline on the flames.

This is really a special case of the general strategy "ask the use to do something time consuming, annoying, and unlikely to help."

2. Forward the User a Huge FAQ, None of Which is Relevant to the Problem

Everyone likes form letters and impersonal service. The FAQ should be badly written, badly formatted, confusing to read, and preferably not accidentally contain the real solution to the problem. If the solution to the problem is in the FAQ, don't tell the user where in the FAQ to look.

3. Wait a Long Time Between Replies

Tech support incidents are like fine wines - they get better with age. To allow the user's annoyance to bloom into a finely honed rage, be sure to let each email 'sit' for a week before replying. This works especially well if your response is just to ask another question, setting the user up for another week's delay.

4. Blame Some Other Component

The modern PC is built by approximately 600 different vendors. Blame one of them. The beauty of this strategy is that it is one that can be used by every vendor who provided software or hardware for the PC. Also, because quite often the problem really is with another component, you can claim this with a straight face.

Tip: blame the graphics card maker - ATI and NVidia do not have the resources to pursue every complaint that an over-clocked graphics card running the latest patch to some simulator written by two guys in their bedrooms crashed with the drivers visible somewhere in the callstack. Put the blame on the GPU makers - they don't have the resources to refute you, no matter how bogus your claim.

5. Forward the User's Issue Around the Company Until It Gets Lost and Dropped

Everyone in the company has to be in on this strategy for it to work - if one of your idiot coworkers actually solves the user's problem, well that defeats the purpose. This strategy can be combined with (3) and is sort of a riff on (4) - once the user complains that they got dropped, blame everyone else in the company for the mis-communication.

XSquawkBox 1.3

This will be a little bit "off topic", and I am normally pretty adamant about not blogging (or even talking) about XSquawkBox. This is because XSB is not something I do as part of my job for Laminar Research, and it is also something that I no longer have time for. Thus my normal highest priority is to make sure that no XSquawkBox users expect timely support or expect this from Laminar Research.

So as I am about to blog about all of the new and cool things coming in XSquawkBox 1.3, let me first make this painfully clear:

XSquawkBox is a piece of code that Wade and I write in our spare time. After finishing our regular job of coding, rather than sit back and read a book or take a walk in the park, we go back to our computers and write yet more code. We don't make any money off of XSB, and no one pays any money for XSB.

This type of freeware development has certain constraints: there is no time table, XSB will be on the back burner when real work comes up or when real life comes up. There is no support. There are no guarantees of features or functionality. If you don't like those terms, I will issuse you a full refund and you can use a different piece of freeware.

Okay - that was a little bit over the top. We want people to enjoy XSB - otherwise we wouldn't have published it. And 99.999% of XSB users are very understanding and appreciative of the development situation.

With that in mind, I can't resist posting some of what is coming in XSB 1.3 - I think it's going to be a really strong release. 1.3 will have the bug fixes people are waiting for, including a fix for the dreaded noise on push-to-talk on Windows. Also coming:

• Wade programmed the server list to auto-populate off the net. How did we live without that?
• COM2 can tune into voice channels too. COM2 has its own hardware selection for those with multiple sound cards or USB headsets.
• You can turn on "labels" for traffic. I actually hate this feature, but I programmed it anyway - it's optional. I'll post why I did it some other time.
• XSB can connect to itself for users with multiple X-Plane visuals. Simply run XSB on every computer, log in from one (the "master") and then connect to the master from each visual (the "slave"). You'll have traffic visible across monitors.

And of course the best feature of all (for me): Wade is doing builds. :-) People owe him a big thank-you..without him there would simply be no 1.3. I definitely don't have time for it...I maxed out my XSB time for a while contributing some of the features.

When will 1.3 go beta? I don't know...ask Wade. Wait - don't ask Wade. He'll get to it when he is able!

Why Not Ignore Problems?

Tom had a good question that others have asked me too: why not ignore missing scenery resources? Why does X-Plane act so cranky?

Ignorance Is Bliss

We have tried the other approach: ignore missing art assets. ENV based scenery in version 7 did not require custom objects to actually be available - missing objects were ignored.

When I was working on the ENV reader for version 8 (the ENV code needed to be retrofit into the new rendering engine) I found to my surprise that virtually every ENV-based custom scenery pack I looked at was missing at least a few of the OBJs that the ENV referenced! I don't know how this happened - it seems that in the process of working on scenery, authors started to "lose" objects and simply never noticed.

Quality Control

When we developed DSF we had a chance at a clean slate: there were no DSFs in existence so we could set the rules for art assets any way we wanted. So we picked the harshest rule possible: any missing art asset was illegal and would cause X-Plane to refuse to load the scenery package, with no way to ignore the error. Why be this rude?

• Missing artwork failures are 100% reproducible - you don't have to try your package more than once to see the problem. If you are missing an art asset, you will have the failure every single time you run.
• The error is found on load - you don't have to fly over the art asset to discover that it is missing.
  
• Therefore if an author tests a scenery package even once, even in the most trivial way, he or she will discover the missing art asset.
• Once the error is fixed, it is fixed forever, so a scenery pack that passes this quality control measure in development will be just fine "in the wild".
• This rule has been in place since 8.0 beta 1 for DSFs, so there are no legacy DSF files that would have this problem.
  

Libraries

There is one special case worth mentioning: a scenery pack might reference an art asset in another scenery pack, and that other scenery pack might not be installed. This is why the library file format allows for "export_backup". (Read more here and here.) Export_backup is your scenery pack's way of sayingg "only use this art asset if you can't find it somewhere else. It lets you provide emergency art-work in the event the other library is not installed.

What should you use as an emergency backup art asset? It could be anything - a big floating question mark, an empty object, a poor approximation of the desired art asset. But my main point is that responsibility for location of art assets lies with the author of a pack - so if you make a scenery pack, be sure to provide backups for any libraries you use.

(If you use OpenSceneryX, the library comes with a "developer pack" - read more here. Basically they already built a "backup" library that you can put in your scenery pack to avoid nasty messages from X-plane when OSX isn't installed.)

Deep In the Goo

No posts for two weeks...sorry, I've been head's down with next-gen tech. It's a little bit too early to blog about this stuff.

I was able to fix a few MeshTool bugs, but I have more problem reports, so I might be able to do a MeshTool beta 3 in a few days if things go smoothly.

940 is final - there might be a 941 maintenance release - we'll know in a few weeks.