Normal maps are expensive. A 2048 x 2048 normal map takes 22 MB of VRAM! So make sure you get every bit of image quality you can out of it. Two things to consider:
- Normal maps are uncompressed (because texture compression really screws up the normal map). So per-pixel detail will be preserved. Use it!
- VRAM is allocated for an alpha channel whether you use one or not. This is because the cards need 32-bit pixels for performance. So include an alpha channel in your normal maps and use it to modulate shininess; this can help create the illusion of different materials.
For scenery objects, do not include an alpha channel if you don’t need it. When textures are compressed, the alpha channel does take more VRAM, and X-Plane will hit a faster rendering path for textures with no alpha channel.
For quite a while now, I have been advocating in favor of DDS compression. I am pretty damned obstinate, but eventually if enough people yell at me, I get a clue. I have come to appreciate that there are some cases where DDS compression is not a net win; this blog post explains when it happens and what we might do in X-Plane 10 to work around this.
DDS – The Good, The Bad, the Ugly
DDS is a file format that contains image data pre-mipmapped (that is, the smaller versions of the image that the video driver needs are included) in a format that may or may not be compressed. DDS is virtually always used with a compressed image format (like DXT1 or DXT5). This has three positive effects for X-Plane:
- Because the image is already compressed, we save CPU time when loading the texture that would be spent compressing while X-Plane is running.
- Because small versions of the image (the “mipmap pyramid”) is already in the file, we save time down-sizing the image with the CPU, another win for load time.
- Because the image is compressed ahead of time, it can be compressed with a slow high quality compressor rather than a fast low quality compressor, so relative to other compressed images we get an image quality improvement.
The bad is that the DDS file does not contain the original uncompressed file. If the user unchecks “compress textures to save VRAM”, DDS files remain compressed. If the image file contains details that don’t compress well, they’re going to get splatted and stay splatted.
What If VRAM Grew On Trees?
My original heavy arguments for DDS were based on the idea that VRAM is a limited commodity; if we don’t compress textures, the user runs out of VRAM faster and has to go down a level of resolution…and once that happens, everything starts to look ugly.
But what if the user has 1 GB of VRAM? At this point, we’ve limited the maximum quality the user can see because we don’t have the original uncompressed image anymore, only the DDS/DXT version. This can be frustrating to authors who spent a lot of time on their textures.
If you ship PNGs with your airplane or scenery, turning off texture compression will reveal this beautiful, uncompressed image, but now when texture compression is on, the compression will be done by the video driver, and that will look extra ugly.
The Best Of Both Worlds
This is my thinking for version 10. (These are just musings, we haven’t coded this yet.) Currently DDS are preferred to PNG files. We could relax the load rules in version 10 to prefer PNG over DDS when texture compression is off and DDS over PNG when it is on. This would allow authors to ship both PNGs and DDS files and have the right one be picked for the scenario: the pre-compressed one when texture compression is on and the uncompressed one when compression is off.
Quick airplane links:
- Carenado’s Mooney M20 J is out, available on the X-Plane.org store.
- Javier’s T34c Mentor is out, available at X-Aviation.com.
Pictures available in both links.
X-Aviation has released the Duchess, pics here.
Carenado is coming to X-Plane, initial pics here.
I realized I have slightly better test shots of global illumination than the ones that got out a week ago. These are from only a day or two after the last shots.
This is the Cirrus again, with landing lights and strobes; you can see that all of the airplane’s lights contribute dynamically to the lighting on the fuselage and doors as they move. (Yes, that is heat blur on the engine; the heat blur still needs a lot of tuning.)
This shows airplane-mounted lights interacting with custom scenery. In this case the standard Cirrus (with global lights attached) casts both strobe and multiple landing light spill on LOWI. One of the powerful results of global illumination is that we get correct lighting interaction between diverse content, including third party content.
Finally, this shows an airport beacon lighting a plane and vice versa. The global lights on the airport beacon are inside an animation group, making them “sweep” the airplane, which can in turn animate the airport beacon. With global illumination, there are no rules about who lights who.
Thanks to my foolish use of unprotected directories, we have basically announced that X-Plane 10 will feature global illumination. Here is some basic information on global illumination.
What Is Global Illumination?
Global illumination is the ability of any part of an airplane or scenery system to cast light on any other part of the scenery system or airplane. In X-Plane 9, the only lights in the sim that ever actually cast cast light anywhere else are:
- The sun.
- The airplane’s landing light. (Even if your plane has many landing light billboards, there is only one spill effect.)
- Three 3-d lights in the 3-d cockpit.
This list was kept short due to the high cost per pixel of each light on all rendering.
When X-Plane 10’s global illumination is enabled, a “spill” light attached to any OBJ can shine light on anything near it. Since any OBJ can have a spill light, this means we can have light sources on airplanes, scenery, cars, whatever you want. The spill effects any 3-d scenery nearby, even from another scenery pack.
This kind of still effect can be simulated in X-Plane 9 by careful use of LIT textures. However, real global illumination works between art assets created by separate authors. You can drive your custom airplane up to a custom airport and the landing and logo lights on the airplane will cast light on the terminal; the apron lights from the terminal will cast light on the airplane.
Furthermore, global illumination is fully dynamic – as objects animate or move, the lighting effects are correctly applied in 3-d. This makes effects possible that cannot easily be created using LIT textures.
Requirements for Global Illumination
Like most new rendering tricks in version 10, global illumination will be a rendering option that can be optionally enabled by users who have a video card meeting hardware requirements. In the case of global illumination, that requirement is a DirectX-10 generation video card, e.g. any Radeon HD , nVidia GeForce 8000 or 9000 series, and “100” series (100,200,300,400 series).
For authors: global illumination is applied using named and parametrized lights on your OBJ. Anywhere you can attach a light billboard, you can attach a spill effect as well, with some tuning constants for how wide you want the light, etc.
It will be possible to create two versions of your LIT textures, one to be used when global illumination is enabled, and one when it is disabled. Thus if you are baking lighting into your textures with a 3-d modeling program, you can simply re-bake the lit texture with some lights disabled and add 3-d lights to your model. The result is an airplane with real 3-d lighting where possible, and a close approximation via baking otherwise.
Global illumination can be added to a model incrementally; existing art content will work normally with global illumination enabled or disabled, so authors can choose to add a few light spill effects or add a large number, as time permits.
The Cost of Global Illumination
Global illumination isn’t going to be free. The main cost is an increase in VRAM use and fill-rate. The cost of global illumination is mostly a one-time cost to put X-Plane into a new rendering mode. (Graphics nerds: global illumination is implemented via deferred rendering.) The incremental cost of lights isn’t that high, although a scene with a lot of lights will have impact.
My expectation is that users with new, highly capable high-end graphics cards will be able to run global illumination easily, but will lose some of the other benefits of fill rate. (For example, running at 2560 x 1024 + 4x FSAA is a lot more painful with global illumination than without.)
Global illumination also introduces two artifacts, both of which I am trying to minimize as best as I can. These artifacts are a function of deferred rendering – all games that use deferred rendering have to address these problems:
- The lighting calculations are shared between multiple translucent surfaces, which can create some strange effects. For example, if a translucent window is in shadow, the scenery behind the window will appear to be in shadow too.
- Traditional full-screen anti-aliasing is not available with deferred rendering. We should be able to offer a simulation of 4x FSAA as well as some kind of cheaper FSAA-approximation, but the cost will be quite a bit higher in fill rate than the 16x-style CSAA available now.
(Hardware-based FSAA can make a number of optimizations like CSAA to optimize throughput; this is how such high multiples as 16x are possible. Since our implementation is similar to “super sampling” and costs a real 4x in performance, 4x will be the highest setting.)
Why Global Illumination
Of the new X-Plane 10 rendering engine features (and there are a fair number of them), global illumination is certainly the one that has the most impact on the structure of the rendering engine. With global illumination, X-Plane effectively has two separate modes (“forward” rendering, which is the only mode X-Plane 9 has, and “deferred” rendering, which produces global illumination).
One of the reasons to get global illumination done earlier than other features was that implementing global illumination required rewriting or modifying nearly every piece of low level rendering code. Now that the work is in place, we can safely add new features and test them in both modes.
Global illumination also meets two requirements:
-
Sergio has long observed the central importance of lighting and shadows in the look of X-Plane; at some point more polygons and better textures still look synthetic without a realistic illumination model. Global illumination makes a more realistic lighting model possible at night. Airports represent an environment that can hopefully take advantage of such capabilities in a big way.
-
As hardware becomes more powerful, authors have to do more work to create content that takes full advantage of the rendering engine. We are reaching a point where artist’s time is going to be a limiting factor as well as hardware and engine capabilities. Global illumination thus kills two birds with one stone: it makes the rendering engine’s output look better, but it also makes the whole scene look better with less work by the artist.
(For example, when baking lighting into a model, the author must plan the model’s texture UV map to guarantee unique texture space for all spill effects. When lighting effects are dynamic, the author can simply texture so the model looks good without worrying about baking requirements.)
A month ago the blog was quiet because there was a lot I couldn’t talk about; now it’s quiet because I am up to my eyeballs in X-Plane 10. I’ll try to get out a few posts I’ve been meaning to write, but it’s definitely crunch time.
I have received a number of emails from plugin developers who wanted to know if they could modify some of the sim/aircraft datarefs, or why modifying them had no effect/an unintended effect.
The short answer is this: in some cases X-Plane will pre-process and cache data that comes from the .acf file. In this case, a sim/aircraft dataref (most of these come from the .acf file) can be read, but writing it will have no effect because the sim has already had its one look at the dataref.
This is a design limitation; it was never the intention of the SDK to allow complete Plane-Maker-level editing of the aircraft on the fly in the sim.
This is a feature I looked at putting into X-Plane 9, but it turned out that it affects so many different parts of the sim (and has to be done all-or-nothing) that it got kicked to v10. Consider these two pictures of the default B777 (the lighting was not adjusted, only the time of day):
The night image looks pretty, but what’s wrong with the day image? The answer is: the small panel post lights in the night image are still casting a fair amount of light in the day image. And the result looks silly. But why?
The answer is: in real life your pupils would contract in the sun, letting in less light. The sun is really rather bright, so the daytime panel would still look normal, but the apparent power of those posts lights would be a lot less, because your eyes are less sensitive. In other words, the relative strength of the sun and post lights is wrong in the second image.
Computer monitors don’t have a huge dynamic range for how much brightness they can put out. So we can’t hope to display the absolute brightness of the scene correctly. Instead we need to make everything brighter at night (to simulate your night vision) and dimmer during the day, like this:
In this set of images, the night image is matched precisely to the previous one, but as the sun comes out, the apparent brightness of all lit textures has been scaled down to simulate the effect of your eye becoming less sensitive due to the flood of sunlight.
What’s good about the compensated image is that the weird artifacts from the post lights are gone; the relative strength of the post lights is really low in relative terms.
What happened to the EFIS and moving map? The answer is that they too are not as apparently bright relative to the sun as they would be at night.
There is one hitch here: plenty of real airplanes have light sensors for various avionics; the avionics will automatically turn up their brightness during the day. So it is possible (I am no expert on the 777) that in the real plane, as the sun rises, you might not have to adjust your instrument brightness; the sensor would do it for you. The pictures above illustrate what you would see if no automatic adjustment is made.
Auto-adjustment presents a challenge: currently two wrongs make a right. We don’t auto-adjust the brightness of instruments, but we don’t simulate the apparent visual brightness relative to the sun, and the result are instruments that look adequately bright at all times of day without user adjustment.
I think in the productized version of this feature, authors will have two options for anything lit:
- Tie the lit instrument/texture to an auto-adjusting rheostat (e.g. brightness 1 + auto adjustment) or
- Tie the lit instrument to the “raw” rheostat (e.g. brightness 1).
The tricky part will be finding the right mapping for legacy airplanes into the new system.
I sometimes get questions from authors considering how much to rely on a 2-d panel mapped to 3-d via the panel texture vs. a true 3-d panel. I can’t comment on what will look best, but I can comment on the relative performance characteristics of both techniques, and the answer might surprise you: in some cases you’ll get better performance by modeling directly in 3-d.
The 2-D Way
When you use the panel texture to make an object, X-Plane goes through a lot of steps to create the final result:
- Your panel has to be rendered in 2-d. We atlas your panel textures, but we don’t necessarily order them optimally – we don’t know the optimal order. Each generic instrument is at least one batch, perhaps even two. Those batches have very low vertex count, and the vertices are stored non-optimally on the CPU. There may be a fair number of texture changes between instruments.
- If you use ATTR_cockpit_region, we then go back and do the same thing…again! Why? Well, we need your panel’s raw color (“albedo” to graphics nerds) and the emissive light given off by anything self-lit separately, so that we can do correct 3-d lighting.
- Both of these are rendered to an off-screen texture that the video driver will feeel obligated to preserve at all costs, putting pressure on VRAM.
- Only when all that is done do we begin drawing your object, with the usual batches to change to panel texture and change back, perform animations, etc.
If this seems expensive, that’s because it is. Periodically users send me airplanes to look at their performance, and lately I’ve been seeing a lot more problems with 2-d panels (that fuel 3-d cockpits) being the performance bottleneck, not the 3-d modeling itself.
The 3-d Way
What if we want to go 3-d? Well, we’re going to “eat” a lot more of what your 3-d pit already has:
- You’ll need a lot more animations to move all of those parts.
- You’ll need new batches with ATTR_lit_level to dial up and down various lighting levels.
But you do get some advantages:
- Geometry in objects is processed about as optimally as we possibly can. All of that work we’ve done on the rendering engine to make OBJs fast is available in your cockpit. So you can increase 3-d detail ‘for free’.
- Your lit geometry can be drawn in a single pass (we don’t need to prepare two separate lit textures). So for example a needle would take three batches via the panel-texture route (a batch to rotate the needle for albedo, a second batch to draw the rotated night needle, and a third batch to draw the resulting texture in 3-d) but only one if you use the OBJ directly.
- Since you organize your textures for OBJs, you can guarantee that all of the cockpit stuff is together, saving texture thrash.
- You can use normal maps to add per pixel detail to your cockpit; panel textured geometry cannot be normal mapped.
A Balancing Act
Given the high cost of panel texture relative to native OBJ drawing, you’d think going native OBJ would be a no-brainer, right? Well, not quite.
A needle is an easy case: you can model a needle using a rotation animation, so your implementation in an OBJ and our generic instrument are quite similar. Same with the throttle lever generic instrument.
But what about a “glass pie indicator”? What about a moving map? What about a rotary?
There are some generic instruments that have “movement” for which there is no equivalent OBJ technique. With these generics, the generic instrument/panel code may be able to render the generic quite a bit more directly than your OBJ can simulate the same effect.
This is my suggestion on a cut-off: if you can directly model a generic instrument with an OBJ (needles, throttles, and other “simple moving things”), consider 3-d. If you would have to use a lot of extra texture space, copies of your mesh, or a lot of show-hides, use the panel texture.
Your goal should not be to eliminate the use of panel texture. But if you can cut panel texture down to a single 1024 x 1024 region from a larger area, you’ll probably see a performance win or a reduction in your airplane’s system requirements.
Performance Test First
Final thought: before you invest months in a complex cockpit design, mock up the “work-load” X-Plane must do and performance test it! For an OBJ, simply make one moving instrument and duplicate the mesh to get the number of expected animations. For the panel, drag out a bunch of instruments, make custom textures and just paint junk into them with photoshop. The goal is to make X-Plane do the same amount of work as it will in the final version. Then fly your test panel on target computers and observe performance.
A few years ago I blogged about gamma correction for png files. Here’s the very, very short version:
- PC and Mac monitors are calibrated differently. Dark tones on a PC appear darker than on a Mac. The curve of how colors are mapped to the monitor is the gamma correction curve, typically expressed as a number like 1.8 for Mac and 2.2 for PC. The higher the number, the more Gothic your dark tones.
- A png file can have a gamma value written into the file, which tells X-Plane (and anyone else) what kind of monitor the png was drawn on. This lets X-Plane brighten a png from a Mac when you are on a PC, and darken a png from a PC when you are on a Mac.
- If you leave off the gamma value on your png, we assume 1.8 (Mac) which can be bad if you’re a PC author.
While this is confusing, it was an improvement over the BMP situation (where everything was set up for a Mac and PC users had to simply crank their monitor brightness).
In version 9 we added a gamma correction setting to X-Plane. The setting you enter in the rendering settings is how “dark” your monitor is (bigger number = darker). We then attempt to compensate by lightening the textures more; thus a bigger number results in a lighter looking X-Plane (because you told us your monitor was dark and we tried to “fix it”).
There are two other developments since the original png situation which have unfortunately been a step backward in terms of X-Plane color correction.
DDS and Gamma
The handling of DDS and gamma is, to put it mildly, quite problematic. The problem is two-fold:
- DDS doesn’t actually have gamma information, so we can’t tag DDSes as having originated on Macs and PCs. So we assume a DDS is authored at a gamma of 1.8 (Mac). I think DDSTool correctly does a gamma correction when grinding files at other gammas.
- (If you are a real graphics programmer, please do not read this next sentence.) X-Plane attempts to adjust the color of the DDS in its compressed form. This is a big hack designed to keep framerate high, but it’s really not a very good idea. The result can be color distortion when a DDS is viewed at 2.2 gamma.
So that’s not good, but what happened next made things a lot worse.
Apple Goes Gothic
Apple adopted the sRGB color profile for OS X 10.6, which has a gamma curve of about 2.2. So now the situation with DDS is particularly ugly:
- All DDS are authored at a gamma of 1.8.
- All users are moving toward a display gamma of 2.2.
- X-Plane thus has to always color correct, but its color correction is low quality for performance reasons.
This is…very sad.
There are two things we can do about this:
- In the short term, we can provide post-decompression color correction. This will cost a (hopefully) small amount of framerate and improve color fidelity for users with 2.2 gamma. This is the kind of thing that any user with a modern card would want, but that we might make optional for users with very old hardware.
- In the long term, we can provide a gamma calibration in the text files that wrap DDS files so that authors can mark their DDS as already being 2.2. This will mean that for most users X-Plane won’t have to do any color correction at all.
