MeshTool 2.0 is still a very new tool, so it shouldn’t be surprising that it has grown quite a few features during beta. I am putting three new features in for beta 4 that should help round out the kinds of things an author can put into a mesh.
Land Class Terrain
The next beta will allow authors to specify built-in land-class terrains by shapefile. Landclass isn’t quite as easy to work with as you might think – I’m working on a Wiki page describing how land class works with the mesh.
You can’t invent your own land classes directly in MeshTool, but there are two work-arounds:
- Once you build your DSF, use DSF2Text to edit the header, changing one of our land classes to the one you want. We have 500 + land classes, so you can probably find one to cannibalize.
- Or you can just use the library system to replace the art assets for the land class within the area covered by your mesh. (You can tweak as little as one full tile.)
Water Handling and Masking
Water handling and masking go together to allow you to create an accurate physical coastline. The problem is that X-Plane doesn’t let you specify whether a tile is land or water using a texture/image file. Physics are always determined on a per-triangle basis.
MeshTool 2.0 beta 4 will let you specify whether the physics of an orthophoto that has water “under” its transparent areas will take on its own physics, or the physics of the underlying water. (It can act “solid” or “wet”.) This lets you use orthophotos to model shallow areas and reefs.
The mask feature lets you do both. The mask feature lets you limit MeshTool to working on a single area vector area, defined by a ShapeFile. So to make a single orthophoto have wet and solid parts you:
- Issue the orthophoto command in solid mode.
- Establish a shapefile mask for areas of your DSF.
- Re-issue the orthophoto in “wet” mode.
The second orthophoto command will replace the first only in the wet areas, giving you regions with both types of physics. The README for MeshTool will cover this in more detail.
No Z Yet
Some developers have requested that MeshTool use the Z coordinate in a Shapefile to define the elevation of water boundaries. That’s a good idea, but I can’t code it any time soon. The polygon processing in MeshTool is fundamentally 2-d and has no way to retain the Z information during processing. I will try to get to this feature some day, but for now it’s going to have to wait.
The new beta should be available some time early next week, or now if you build from source.
Normally I try to make the X-Plane scenery and modeling system as opaque as possible — I want to make sure that nobody ever actually uses the rendering features that I spend weeks and weeks developing.
But the other night I had a little bit too much to drink, got distracted, and posted these:
In all seriousness, I have been trying to find time to put more documentation up on the Wiki. For these features, you will find an explanation of how the planes work, as well as a link to the planes (with plugins) to download, and a link to the plugin source code (on the SDK site, with sample makefiles for 3 operating systems).
Plugins? Do not panic! While plugins are necessary for some of the features demonstrated here, others can be created without additional programming.
BTW, if the existing documentation uses a concept that is not explained anywhere, please email me. I sometimes leave holes in the documentation by accident.
In my contact with users, on X-Plane forums, in discussions of computer graphics, video drivers are an easy punching bad. When an app doesn’t work, blame the video driver. The guys at NV and ATI don’t have time to respond to every ridiculous allegation that is posted. Sometimes drivers are borked, but when it turns out to be X-Plane I try to set the record straight.
Driver writers have what might be the hardest combination of programming circumstances:
- Their code cannot crash or barf. X-Plane crashes, you send me some hate email. Your video driver crashes, you can’t see to send me that email.
- The driver has to be fast . The whole point of buyng that new GeForce 600000 GTX TurboPower with HyperCache was faster framerates. If the driver isn’t absolutely optimized for speed, that hardware can’t do its thing.
- The driver writers don’t have a lot of time to be fast and correct – the GeForce 700000 GTX TurboPower II will HyperCache Pro will be out 18 months from now, and they’ll have to start all over again.
That’s not an easy set of goals to meet. Today’s video cards are basically computers on a PCIe board, and they do amazing things, but they do it thanks to a fairly complex piece of software.
Applications writers like myself get to outsource the lower level aspects of our rendering engine to driver writers. When a driver doesn’t work right, it’s frustrating, but when a driver does work right, it’s doing some amazing things.
Well, I won’t stop you from lying to X-Plane, but if you do, your add-on may have problems in the future.
Basically: some parts of X-Plane take measurements of real world information and attempt to simulate them. I have previously referred to this as “reality-based” simulation (e.g. the goal is to match real world quantities).
In those situations, if you intentionally fudge the values to get a particular behavior on this particular current version of X-Plane, it’s quite possible that the fudge will make things worse, not better in the future.
This came up on the dev list with the discussion of inside vs. outside lighting. X-Plane 9 gives you 3 global lights for objects in the aircraft marked “interior”, but none for the exterior.
Now there is a simple trick if you want global lights on the exterior: mark your exterior fuselage as “interior” and use the lights.
The problem is: you’ve misled X-Plane. The sim now thinks your fuselage is part of the inside of the plane.
This might seem okay now, but in the future X-Plane’s way of drawing the interior and exterior of the plane might change. If it does, the mislabeled parts could create artifacts.
So as a developer you have a trade-off:
- Tweak the sim to maximize the quality of your add-on now, but risk having to update it later.
- Use only the official capabilities of the sim now, and have your add-on work without modification later.
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 1024×1024 or 2048×1024 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:
- 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.)
- 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.
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.
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.
