At this point the only thing holding up a public beta of 10.10 is, well, me. I am currently working on a set of related aircraft rendering bugs, and as soon as I can get the car off of jacks, we can go beta.
One of my goals or 10.10 is to close out the issues that stop payware authors from releasing final conversions of their aircraft to 10.10. By final, I mean conversions that won’t need any additional future editing. Right now X-Plane 10.05r1 has a few bugs that cause v10 to look different from v9, different depending on rendering settings, or just wrong. I want to fix those problems in a permanent manner so that authors can release aircraft and not worry about having to update.
Here are my goals for 10.10, roughly in priority order:
- Rendering should be consistent from X-Plane 10.10 onward through the rest of the v10 version run.
- Rendering should be consistent between HDR and non-HDR mode. Authors should not have to create two versions of textures where the HDR and non-HDRs offer the same capabilities. (In other words, while you might have to make two textures to bake lights when in non-HDR mode, you shouldn’t have to make two textures to correct for differences in color-correction between the two renderers.)
- Where possible, non-HDR mode should match X-Plane 9.
The switch of priority between item 2 and 3 is a fundamental change in priority from what I originally intended for X-Plane 10.
Originally I thought that the best thing to do would be to keep non-HDR rendering as close to v9 as possible, so that at least content would look correct with HDR off.
My new thinking for 10.10 is that we should aim for consistency between HDR and non-HDR modes. Realistically, an author is going to have to make at least a few adjustments in moving v9 content to v10; better to have the cost of rendering engine changes be borne out in a v9->v10 upgrade than to have every v10 airplane require double authoring to cope with HDR vs. non-HDR differences. In the long term, it’s best to not have v9 haunt v10 like a ghost years after authors are making exclusive v10 content.
Why is HDR Mode So Weird
This begs the question: why is HDR rendering so weird? Why does it look different from non-HDR rendering, and why doesn’t it look the same as v9? What did you guys do?
There are a number of changes to how we render in X-Plane 10, some specific to HDR rendering, and some sim-wide.
- The entire sim now works with a linear lighting equation. Basically when the sim performs lighting calculations on the GPU, it thinks in terms of photons and not colors, which produces more realistic results in most cases. With lots of light sources, linear lighting is absolutely necessary for combining those lights.
- The order of rendering operations is very different between HDR and non-HDR mode, and the formats that they render into (24-bit RGB vs. floating point, etc.) are very different. HDR is fundamentally a two-pass format.
X-Plane maintains two separate rendering paths for HDR vs. non-HDR and they are quite different in both what happens at each stage and when the stages occur.
Fixing some of the authoring bugs has required further changing the HDR pipeline to allow for correct rendering. The up-side of this change in pipeline is that the new one supports better HDR tone mapping and possibly even better fill rate performance. The down-side is that it’s a lot of complex code to touch and it may take a few betas to work out the bugs.
One complaint we hear a lot from tech support is that the 747 knobs are hard to control in the 3-d cockpit. Javier and I did some investigation into this; this post describes what we found, what we are changing, and what why I don’t think the scroll wheel probably shouldn’t be used to affect the 3-d cockpit.
Hard To Drag
The fundamental problem is that it’s hard to control the autopilot knobs in the 747 by dragging with the mouse. Large drags make only a small change in the knob, so it takes forever to dial in an autopilot altitude. You’d think the solution is simple: change the scale for dragging on the knobs, right? Well, not quite.
It turns out that the “sensitivity” of the knobs to dragging is a function of the way you turn your head in the cockpit. Sit in the default 3-d position, turn your head 30 degrees to the right and drag and the knobs turn quickly. But look straight ahead, slide to your right, and drag and they are very slow.
The problem is one of perspective, and this is where it gets interesting for authors. The drag axis manipulator (which lets you make the 3-d cockpit respond to dragging the mouse) measures its drag in meters. But the distance on the screen that the drag distance takes up (in meters) depends on where the camera is placed and at what angle it is turned. This can lead to some very strange effects: in some views, a 500 pixel drag moves the altimeter only a few hundred feet, while in other views, 500 pixels moves tens of thousands of feet.
Screen Space Dragging
For real physical parts like a lever (a part that moves as you drag it), dragging in meters makes perfect sense; it lets authors match their animations to their manipulations.
But for a drag that doesn’t have a real-world correlation (e.g. you drag on the knob and the knob spins but it doesn’t move) having the camera angle affect the drag distance results in panels that can be used only from certain viewpoints.
To fix this, we are introducing a new “pixel” drag axis – unlike the current drag axis, the distance over which the user can drag is specified in pixels, so that the “sensitivity” to the mouse is the same no matter what view angle the user has. I will post details on this when we go beta.
The Mouse Wheel
While I was working on pixel drag axis, I looked at using the mouse wheel to turn knobs, something our users asked for. And while the prototype seemed ‘clever’, after some arguments with Chris I came to a bit of an inescapable conclusion: the mouse wheel for changing parts of the panel is the wrong tool for the job.
The problem with the wheel is that in the rest of the universe it is use to manipulate view information. This is true in X-Plane 10.05 as well (and it works well), but things get quite tricky once the mouse wheel is added in. Some of the problems:
- Making the mouse wheel zoom and manipulate (e.g. if you are over a knob it manipulates the knob, otherwise it zooms) risks surprising results. A user who wants to zoom might accidentally “bump” a cockpit knob, something that’s pretty frightening to a real pilot.
- We looked at requiring once of the buttons to be held down while mouse-wheeling, but that’s not a gesture you see anywhere else in the universe – effectively one of the two uses of the wheel is “buried” and we might as well only use the other. Furthermore, if we are going to require a click, the user might as well just drag on the knob itself.
- If we have to pick one or the other (zoom or manipulate), zoom is by far the most consistent thing, the thing that fits with the host OS.
- If we make the option a preference (e.g optional mouse-wheel on knobs) so few users will enable it that authors won’t be consistent in adding support to their cockpits, and the system will never get momentum. (We can’t just add “mouse wheel automatically” because the sim doesn’t know how much one click of the wheel should change a given dataref.)
We tossed the mouse wheel idea around, but in the end we concluded that the wheel should be a view/zoom/scroll function, not a data change function – we couldn’t find any example apps that used the wheel to change the contents of the screen. In the end, authors need to make clicking work well, and we need to provide manipulators (like the screen-space drag manipulator) to make that possible.
Here are three obscure Plane-Maker/X-Plane features that can save you time if you developer complex aircraft.
Plane-Maker Will Copy Your Instruments
You may know that in Plane-Maker, you make your own copies of X-Plane’s PNG files to customize the look of the instruments. But did you know that Plane-Maker will copy the images for you?
Select an instrument and type Control-P (which is the default for the command binding “pln/panel/copy_instrument_png”). Plane-Maker will copy all PNGs for that instrument into your aircraft’s cockpit or cockpit_3d folder. This can save you the time spent wading through X-Plane’s cockpit folder to find the right PNG files.
X-Plane Can Make a Panel Image for UV-Mapping
When you are making a 3-d cockpit, you use the 3-d panel as a texture. But how do you know how to UV-map this texture in your cockpit? Often the panel background (panel.png) is blank.
X-Plane can make a snapshot of your panel for you, in the exact size you need to UV map. Use Control-Alt-Shift-Space (Command-Option-Shift-Space for Mac nerds) to run the “sim/operation/make_panel_previews” command in X-Plane. It will make a PNG file in your aircraft called Panel_preview.png – it’s just like Panel.png but with the instruments drawn in – perfect for UV mapping.
Plane-Maker Will Tell You What’s Wrong
That sad face icon in top bar of the Plane-Maker panel editor enables “warning” mode. In warning mode, every instrument that has a potential problem gets a red outline. Select one instrument with a red outline and in the upper left corner of the panel you’ll see a description of what’s wrong.
This picture on the left is from Plane-Maker editing a 3-d panel. (That’s why it is just a “packed” set of instruments with no background; this panel is used as a texture for a 3-d cockpit – each instrument is UV-mapped into the right location.)
The air-speed indicator has been flagged as having a problem, and the text shows it. In this case, the lit texture has an alpha channel, which causes the lit texture to draw incorrectly. Fix the texture and the warning will go away.
I strongly recommend checking all Plane-Maker “red boxes” on your plane – most of the warnings will tell you about problems that would otherwise be very hard to detect.
I finally finished up an update to the OBJ8 specification, as well as the forest specification – see here for the documents. These specifications are mostly of interest only to developers who are working on scenery exporters.
The OBJ specification is very thick – here are some of the hilights of what’s new.
In X-Plane 10, you create global spill lights by attaching a light to an object. (Thus, spill can come from any object-bearing part of the sim – an airplane, custom scenery, etc.)
One way to do this is with the existing named and parameterized lights – these features existed in version 9, but in version 10 there are some spill lights added to the light list.
What may be of more interest to custom authors is the new LIGHT_SPILL_CUSTOM command. This lets you build a completely customized spill light. You control its size, color, shape and direction. You can even optionally run the light through a dataref, giving a plugin custom control of the light.
In X-Plane 10, an object can contain geometry that is “draped” on the ground – that is, X-plane will subdivide, bend and modify part of your object mesh so it sits perfectly on the ground even if the ground is sloped. ATTR_draped makes this happen.
This feature is a much better alternative to using ATTR_poly_os to make marks on the ground. Draping produces objects with better performance, and the geometry always sits on the ground with no artifacts.
As an added bonus, you can optionally use a second, different texture for the draped part of your object from your regular object. (Internally the draped geometry actually becomes something like a .pol file – this is why it can have its own texture.)
Draped geometry makes it much easier to make airport markings. If you want a parking spot, simply draw it on a quad, make it draped, and drop it into place with WED. Tom uses this heavily in our airport library.
Draped geometry also makes it easier to have ground markings that match the object they come with. For example, if you want a house and the house comes with a driveway texture, you can make the driveway texture a draped quad and when you place the object, the draped driveway is always in the right place.
Global Attributes and Instancing
In X-Plane 10, it is possible to set a few key attributes (blending and shininess, among others) globally for the entire OBJ, rather than using an ATTR_ to change part of the object.
These global attributes make hardware instancing possible. In hardware instancing, X-Plane draws many objects with a single instruction to the CPU. In order for this to happen, X-Plane must be able to draw the entire object without needing CPU intervention mid-object. This means an instanced object has to be free of animation, attributes, and a few other features.
The global attributes let you set things like shininess and still have a single-call draw object, ready for instancing. Alex uses these heavily in the urban autogen, and it really helps performance.
My fear is that global attributes are going to be a source of confusion for authors. When should you use them? How do you add them? This is my thinking:
- Modeling program exporters should allow an author to identify an object as “for instancing” or not.
- Authors should check “for instancing” for any object that is heavily repeated. (A car or a single tree or a static airplane, for example.)
- The modeling program can then try to prefer global attributes for instancing objects but not for regular ones, which should come very close to optimal behavior.
Conditionals are simple logic statements that include or ignore parts of an art file based on the rendering settings. In particular, they let you change an OBJ based on whether HDR is on or shadows are on. For example:
In this example, which LIT texture the OBJ uses will depend on HDR.
Because the conditionals can be used anywhere in the OBJ, you can change any aspect of the OBJ to customize for HDR. You can replace a texture, remove lights, add more geometry, etc.
I don’t know how heavily people will use conditionals, but they give authors the option to make one file tuned for both HDR and non-HDR, shadows and non-shadows.
I think the two most common uses of conditionals will be:
- Providing alternative LIT textures when HDR is on or off. Note that only one texture is ever loaded (when the HDR rendering setting is changed, X-Plane unloads one and reloads the other) so this does not increase VRAM.
- Removing drop shadows that are baked into a model when shadows are on.
That second case would look like:
IF NOT GLOBAL_SHADOWS
# This is the shadow geometry
TRIS 300 6
When global shadowing is turned on, the entire set of draped geometry disappears, removing baked vs. real shaodw conflicts.
A quick OpenGL note for plugin authors: if your plugin uses OpenGL to draw (e.g. for a plugin in an airplane that draws a custom glass display) you should:
- In debug mode: always check the OpenGL error state (using glGetError) at the end of each draw callback that you handle. X-Plane will not leave OpenGL errors around, so any error is yours. (To verify that it’s not another plugin, just add a glGetError at the beginning of the callback.)
- In release mode: never check the OpenGL error state, as it can slow down the driver.
An OpenGL error often implies that an OpenGL command did not complete as expected (because a param is bad, etc.) and this can mean that you are not cleaning up OpenGL state for X-Plane!
(And of course you should always use XPLMSetErrorCallback in debug mode to catch plugin errors. Set a break point in your callback to see exactly where the error occurred.)
Captain Peter Hager for sending me his A340 as a nice test case for texture compression. Peter (like many aircraft authors) has never been very happy with the artifacts introduced by DXT compression.
First the basics: DXT1-5 are a series of texture compression formats. They store the same number of pixels in a smaller number of bytes via clever encodings of the pixels.
When your image has no alpha channel, the savings from DXT1 compression are 8:1. (Modern graphics cards store RGB images in 32 bits for alignment, so the 4-bits-per-pixel DXT encoding is an 8:1 savings, not the 6:1 you’d expect on paper.) RGBA images take 8 bits per pixel, for a 4:1 savings. That’s as much as reducing the image size by a factor of 2 in each dimension.
DDS is an image format that contains a compressed image. DDS files load faster (because the image is already compressed), look better (because the image is compressed using a slower, higher quality process before sim load) and let you pick the DXT algorithm choice. (In some cases, the choice between DXT3 or DXT5 matters!) However, once an image is compressed into a DDS file, the pixels lost in compression never come back – DXT is a lossy compression format! (This is just like saving a JPG as a PNG – if the JPG quality was too low, the PNG will contain the same blocky artifacts that the JPG had.)
Compression is useful for more than just saving VRAM – because the amount of data needed to texture a given pixel is smaller (4 bits per pixel instead of 32) compressed textures can speed up framerate if the memory bus between the GPU and its own VRAM is congested.
Now let’s look at some pictures.
This is the Swiss Air livery at extreme res, uncompressed, sourced from a PNG. This is our reference image for how good the original image can look before we start trading off quality for VRAM.
This is the same image, extreme res, texture compression on, sourced from a PNG. It just looks awful. The graphics card has done the compression, and it has done a fast job, not a high quality job. (In the driver’s defense, X-Plane asks for a fast compression rather than a high quality one to avoid slowing the sim down.)
This is also compressed!!! But in this case the livery was pre-compressed using XGrinder/DDSTool (which in turn uses libSquish). DDSTool sets libsquish for maximum quality and then takes quite a while to grind each texture, but the results are better use of those compressed bits. (DXT is a lossy compression, so more compute time can find a better use of the finite quality available in the compressed texture.)
Finally, this is the uncompressed texture at “very high” res – that is, taken down one resolution level. Compare this image to the compressed one above. For an alpha-blended texture, the trade-off is one “size” increment (2x smaller on both sides for 4x VRAM savings) vs. compression. I submit that the compressed version is a better way to save VRAM than down-sizing.
Have Your Cake and Eat It in X-Plane 10
In X-Plane 9 you had to make a trade-off: ship a compressed image in a DDS file and have the very best look be extreme res compressed or ship a PNG file, and have the texture look terrible when texture compression is on. You can see from the above images what the options looked like.
In X-Plane 10 you can do both. If you ship a DDS and a PNG file, X-Plane will load the PNG file when texture compression is off and the DDS file when it is on. The result is a pre-compressed texture for users who need texture compression and an uncompressed texture for those who can afford the VRAM.
VRAM and Memory
One last note on texture resolution for users: most drivers use virtual address space to load textures, and thus texture memory eats into X-Plane’s 2/3/4 GB address space limit. Therefore with high VRAM cards (e.g. a 3 GB card) it probably isn’t possible to absolutely max out texture res until we go 64 bit. For example, on the Mac (where the driver uses a lot of address space and we only get 3.5 GB) running the sim on extreme + uncompressed texture res will almost always run you out of memory.
One thing I have noticed from looking at user’s settings and our own machines is that the textures resolution selector goes in pretty big jumps. Each resolution change cuts VRAM by 75%, so if you are over VRAM (and having performance problems because of that), the next setting down will probably leave VRAM unused.
So I have a todo item to look at putting incremental texture resolutions in that derez the scenery but not the airplane, for example, to hit some in-between points. In that context, we may be able to support mixed compression, where some airplane elements remain uncompressed, but the scenery is compressed.
The recommended practice for developers remains the same:
- If your textures look better without compression, ship DDS and PNG files, and pre-compress using XGrinder/DDSTool.
- If your textures don’t improve much by running uncompressed, ship only DDS files, pre-compressed with XGrinder/DDSTool.
One Exception: Orthophotos
There is one exception to the X-Plane 10 practice of shipping both DDS and PNGs: if you are using orthophotos via either a .pol or .ter with the LOAD_CENTER directive, use DDS and only DDS.
LOAD_CENTER causes your images to be reloaded at high or low res depending on the distance from the user’s aircraft to the image; this can save a lot of VRAM by reducing resolution where the user cannot see the detail. Because DDS contains pre-resized images, it is much more efficient than PNG for load center; I therefore recommend DDS-only for orthophotos.
I’ve been meaning to write a post about the difference between general purpose flight simulators and AAA first person shooters for a while; a particular feature in X-Plane 10.04 brings some of these differences to light.
A typical high-end first person shooter is a closed game; the art content and the rendering engine ship together, and the art content is authored specifically for (or repurposed for) that particular rendering engine. The content is also completely available ahead of time; it can be authored without worrying about rendering engine changes or the addition of third party add-ons. Similarly if a rendering engine change requires revising all art content, this is at least possible, since all art assets live in house.
Compare this to a general purpose flight simulator. The rendering engine and art content may be revised on different schedules. The artists building third party content have limited access to the developers writing the rendering engine, and the rendering engine acts like more of a platform than a closed product.
Because X-Plane’s rendering engine is a platform, rather than part of a closed product, we try to keep optimization and performance work generic. When possible, we put in optimizations that act automatically without author participation. When we do have optimization advice, it tends to be generic advice that applies over a wide range of rendering engine revisions. (For example, using less OBJ ATTributes and atlasing many small textures into one big texture have been good advice for at least the last seven years.)
Sometimes, however, it becomes necessary to put in authoring features that are somewhat specific to the rendering engine and optimization. This is what has happened with cockpit pre-filling.
Before we go any further, you may want to read about pre-filling here. (One thing I am trying to do is to put the specific tutorials and documentation into permanent articles and not blog posts that are lost in the archives after a few months.) Basically when we pre-fill, we draw part of the airplane early on to mask out clouds, saving fill rate on the GPU, improving framerate.*
For the 2-d panel, we put in pre-fill in X-Plane; no artist intervention is needed. But for the 3-d cockpit, we can’t easily pre-fill without you setting some check-boxes on your airplanes.
The problem with the 3-d cockpit is that it is, in its entirety, rather expensive to draw. So we can’t just draw the entire 3-d airplane (for the purpose of masking clouds) or we’d be burning a possibly large amount of CPU to save a possibly large amount of fillrate. The right trade-off depends on the actual plane, and X-Plane can’t figure out automatically what the right thing to do is.
Hence the pre-fill check-box in X-Plane 10.04. With the pre-fill check box, you (the author) mark your content for optimization to hit the right balance of CPU and fill rate savings. (See the articles linked above for guidelines on how to set the flags sanely.)
Fortunately if the check boxes are set wrong, the worst thing you get is poor frame-rate (not crashing). But this is a rare case where third party authors can (and have to) input tuning data directly into X-Plane.
(And for concerned users: if an airplane doesn’t have the pre-fill check-boxes set up, the performance is the same as 10.03 – there’s no loss, this is just an opt-in optimization.)
* If you are asking at this point “why didn’t you guys do this years ago, you idiots?!?” the answer is: because it never mattered before. X-Plane 9 simply doesn’t use much fill rate, so it never made sense to spend CPU time to save fill rate.
A number of third party authors (bravely) promised X-Plane 10 updates to their airplanes. And I believe that a tune-up to be X-Plane 10 compatible isn’t going to represent a lot of man hours.
That is, unless you try to do this job now.
I have a number of open bugs where version 9 airplanes don’t load quite right in X-Plane 10. If you have an X-Plane 9 airplane and you try to work around these bugs, a few things will happen:
- You will only be able to work around some of the bugs, as others are pretty hard-baked into the sim.
- When I actually fix the bugs (in the next weeks) your airplane will be “broken” yet again, since “fixing” the bugs now means trying to make a right with two wrongs.
So third party authors: please do file bugs if you haven’t already, and give us a little time to work through them. Please do not try to work around these bugs, only to have your airplane become “re-broken” when we get the sim corrected.
And users: please be patient with your third party airplane authors. They can’t make their plane v10 compatible until we fix some bugs, and if they try they’re just going to get thrashed.
There are some things that do need to be reworked for version 10, particularly for HDR mode. But a lot of the reports I get are just things that are funky in the sim.
How to File an Airplane Bug
Since I am getting deluged with bug reports, support requests, questions, etc. I want to describe the best way to get an airplane compatibility bug to us. By following these guidelines, you’ll make it easier for us to kill off compatibility bugs fast.
- Please file the bug only once. If you have filed the bug and haven’t heard that it’s fixed, you do not need to tell us in every new beta that it is still broken.
- File bugs via http://dev.x-plane.com/support/bugreport.html. We can route this form to whomever we think is best suited to handle the bugs. Please do not just email the last person you conversed with directly.
- Please only file bugs if an airplane looks different in the latest X-Plane 10 build and X-Plane version 9.70. X-Plane 9.70 is the version 9 release that we are targeting – no older version!
- Please get us reproduction materials – preferably a complete ACF pack, and preferably a cut down one if it can be simplified.
- Send us the v9 .acf file, before any modifications. We want to see what your customers would have seen if they just tried to use the plane. If you send us a version resaved in X-Plane 10, we don’t know what happened.
- Please provide illustrations of how the plane should look in version 9 vs how it does look in version 10. We need a reference point.
- Please try to keep reproduction steps as short as possible. If we have to make a 2 hours flight with 400 waypoints to see a bug, that’s a time sink for us.
A number of you have already sent us good bug reports – we will get to them as quick as I can. If all goes well tonight my fires will be out and I’ll be able to jump into this shortly.
This is a screenshot of Javier’s new version of the X-15 for X-Plane 10. In this case I have hacked the rendering engine to show the specular channel* (the alpha channel) of Javier’s normal map as the texture of the airplane. In other words, that is the per pixel shininess that Javier “drew into” the normal map. there isn’t any lighting on the airplane; the bright edges are simply parts of the plane that are completely glossy.
Just look at how gnarly and detailed and full of goo it is! When you look at the plane under normal lighting conditions you simply see the regular texture. But when the sun reflects off of the plane, the reflection is messed up by this complex specularity pattern. The fact that the sun reflections change unpredictably and dynamically is what sells the illusion.
I mention this because normal maps are expensive – they aren’t compressed and can chew up 4 or 16 MB of VRAM easily – they have to be at high resolution to get the subtle bump details. As long as you’re going to have the resolution, make use of it by putting “texture” into the specular channel – it’ll make your materials seem a lot more complex.
X-Plane 10: X-Plane 10 will allow you to use a gray-scale PNG as a specular-only image, for this kind of “texture” at 1/4 of the VRAM cost, in case you don’t need the actual bump mapping.
* 3-d nerd: X-Plane’s terminology is different from what you’d see in a typical 3-d modeler materials editor. What we call “shininess” is the specular level – that is, how bright specular hilights appear to be. In a 3-d editor this is usually an RGB color, but X-Plane only gives you a single level control; the specular hilights take on the tint of the sun instead.
The “shininess ratio” or “specular exponent” you’d see in a 3-d editor isn’t available in X-Plane – it is set to a fixed exponent by the sim. The unconventional names is a historical artifact.
Simon and Chip have a whole series of posts reviewing the plane, with lots of nice pictures.