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.
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.
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:
- 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.
- 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.)
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.
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 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.
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!
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.)
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.
Yesterday I blogged about Order Independent Transparency (OIT). That robot is very shiny, but what does this fix in X-Plane itself? Here are two pictures that show the problem in an X-Plane context.
This is the Cirrus jet in X-Plane 9.22.
Pretty, eh? But…look through the right two windows – look at the passenger door on the other side. Note that through the middle window the passenger door is visible. Through the right window, the entire passenger door is gone!
This is the same shot from X-Plane 940, where the problem has been corrected.
The bug you see here is incorrect draw order. In X-Plane 922, the right door (which contains the right-most near window) is drawn before the left door – hence its translucent part destroys the door.
Max fixed this by changing the draw order of the model – the new cirrus draws the inside view of both doors before the outside view of either doors; because the geometry is one-sided he can draw the ‘inside’ first and outside ‘second’.
These two
blog posts explain translucency in a lot more detail.
What X-Plane has now is “order dependent” transparency – if translucent surfaces are not drawn from far to near, you get artifacts like the missing door.
What OIT promises (and that robot demonstrates) is the ability to have translucent geometry and not have the objects behind the translucent parts disappear.
