Category: Aircraft

More Global Illumination Video

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.

Posted in Aircraft, Development, Modeling, News, Scenery by | 17 Comments

X-Plane 10 and Global Illumination

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.)

Posted in Aircraft, Development, File Formats, Modeling, News, Scenery by | 5 Comments

Sometimes You Can’t Change Aircraft-Based Datarefs

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.

Posted in Aircraft, Development by | 1 Comment

Lighting Rheostats in X-Plane 9

There were a few threads regarding lighting rheostats in X-Plane 9. Here’s a short version of the issue and why we’re not changing X-Plane 9’s behavior.

X-Plane 9’s policy toward lighting rheostats is a little bit arbitrary. The sim will pre-position every lighting rheostat in the cockpit to 75% intensity on sim startup, and from that point on, we never touch them. We do not reset them when you load a new plane or reset your flight.

The result of this is that when you load a new airplane, it “inherits” the rheostat positions of the last airplane loaded. This can cause a problem if the newly loaded plane doesn’t have controls to adjust the lights (e.g. it has no instruments on the 2-d panel or manipulators on the 3-d panel, and there is no keyboard shortcut defined). A plane can be “stuck dark”.

It would be nice if X-Plane would pre-initialize the lighting rheostats on startup, but X-Plane deos not have enough information to do this. For example, on plane load, the instrument brightness should be set fairly high (so a glass cockpit can be read during the day) but the flood lights should be fairly low (to prevent loss of night vision). But X-Plane has no idea which rheostats control instruments and which control floods. So if we wanted to correctly initialize the cockpit, we wouldn’t have enough information.

To make it more complicated, some airplane authors have taken it upon themselves to initialize the cockpit via plugin code. If X-Plane were to start changing the rheostats at startup, it might undo some of what these plugins have done.

Given the difficulty of maintaining compatibility and the lack of a “correct” set of values, we decided not to change the behavior in 9.50 or 9.55.

If there’s any take-away point for airplane authors, I think it is this: provide controls for the lighting rheostats that you use in your airplane. Otherwise the user can’t turn the lights on if they are off for any reason. You can control the lighting rheostats with a generic instrument, manipulator, or the built-in instruments.

Ugly Glow

There is a separate issue that sometimes comes up: X-Plane panels can look bad when the flood lights are turned all the way up during the day. A panel can look very red and washed out, for example.

This problem comes from a mismatch of real-world lighting levels. In the real world, the sun is approximately four gajillion times more powerful than the little dome lights in an airplane. So when the sun is out, the dome light isn’t visible even if it’s turned all the way up. The dome light only looks bright when your eyes have adjusted to a no-sun condition.

What X-Plane should do (and may do in the future) is scale all cockpit lights relative to the overall daytime brightness, which would effectively dim the effect of flood lights during the day. Simply turning down flood lights when a flight is started during the day is not a full solution, as the user can simply turn them right back up again and end up with an unrealistic scene.

Suffice it to say, I think we will address these things in a v10 time frame, not a v9 time frame; in the short term it’s better to have airplanes continue to function as the author intended.

Posted in Aircraft, Cockpits, Development by | 3 Comments

Plugin-Based Prop Discs

I was discussing plugin-controlled prop discs with a third party developer. The developer wanted to know if custom prop disc control would end up inside Plane-Maker. It may end up doing so, but I don’t think this would be nearly as useful as it would seem. What follows is my explanation to him of why this is.

Let me draw an analogy: when it comes to systems modeling, using a plugin is to Plane-Maker as using Blender is to using Plane-Maker.

Users who cannot use Blender are frustrated because they cannot make something as nice as those who are building planes out of OBJs. Sometimes they ask for more features in Plane-Maker, like: more stations! This new editing mode! Make the UI better!

But…you tell me: will Plane-Maker’s UI ever be as flexible and powerful as Blender? And if it ever did get to be that good, would that have turned out to be a good use of LR’s time, when Blender is already available?

The motivation for OBJ-based airplane geometry via third party tools is that what users want to do cannot be easily generalized into a few simple cases. Every plane is different, so a truly flexible platform is needed.

The prop disc (and other systems modeling problems) are the same way. In developing the prop disc graphics, I spoke with a number of third party developers who had already tried to push prop discs as far as they could go, were using plugins, were drawing themselves, as well as 25 other crazy hacks. I also spoke to our internal art team. And what I found was: no one had any consensus on how the prop disc system should work. Everyone wanted to tune a very specific set of behaviors to their peculiar art assets.

That’s what drove me to put it into a plugin. When we need an equation or a strategy we reach the point where we need more flexibility than Plane-Maker can exhibit. A plugin can encapsulate a strategy or technique in a way that Plane-Maker radio buttons cannot.

Consider what would happen if custom prop disc parameters were built into Plane-Maker. Everyone would have to wait until Austin implemented the prop disc algorithm they wanted. How would this be bad? Let me count the ways?

  1. How many algorithms do you think Austin has time to code? Not more than he has fingers on his right hand. Only the five lucky third party developers who get their algorithm coded will be happy with this.
  2. Austin code exactly what you want? Don’t get your hopes up.
  3. , what you asked for wasn’t what you wanted? We can’t change the behavior now, that would break compatibility!
  4. oh…your email got eaten by a spam filter? Too bad…no custom prop disc for you!
  5. Sorry, we don’t have a release vehicle lined up for the next 3 months. You’ll have to wait.

This problem is already happening across pretty much every aspect of systems modeling: airplane have unique, quirky systems which are usually useful for exactly one plane. It is not even remotely sustainable for X-Plane to code these things one at a time with a set of check-boxes. We might as well have a pop-up menu for every airplane ever invented, and simulate every single airplane inside the sim itself. Imagine the development costs…if a single high quality MSFS add-on sells for $30-$50…

Think of the prop disc via plugins situation (and the strobe lights are the same way) as an experiment in generic instruments for systems. By transitioning to a generic abstaction for instruments we’ve let a lot more users do exactly what they want with a small, high performance piece of code. The original instrument strategy (one of everything) reached a point where we simply couldn’t meet user needs in a cost-effective manner.

Posted in Aircraft, Aircraft & Modeling, Development, Modeling by | 7 Comments

Where Has All My VRAM Gone?

In the past I have suggested that there is a limit to the value of additional VRAM when buying a graphics card. When I posted this, Nicholas from the org emailed me to point out that with third party add-ons VRAM was a lot more important.

At the time I wasn’t really convinced, but I’ve finally come around; it takes a while for the trend to get back to me. (I just don’t have time to look at everyone’s add-ons the way I used to 4 or 5 years ago.) It seems clear that airplane authors (and to some extent scenery authors) are using VRAM pretty aggressively. If you want to use third party add-ons and you care about texture res and texture sharpness, spring for some VRAM. It doesn’t cost as much as it used to, and authors are starting to use it.

What Lives in VRAM

Bear in mind that in any discussion of how your video card operates, anything I post is informed speculation. The driver provides an abstraction (OpenGL) of what the hardware does, and a lot of the bookkeeping isn’t visible to X-Plane at all. So what I am describing is typical of past video drivers that we have had insight to in the past, but it’s not universal, and it’s not at all guaranteed. (X-plane can’t demand any of this behavior of the video driver.)

In order of how “stuck” in VRAM things are we have:

  • Video memory used for on-screen rendering. Depending on rendering settings you can lose anywhere from 12 to 24 MB of VRAM per million pixels on screen. So if you’re running at 1920 x 1200, you might be using 50 MB of VRAM just for the screen. If you use FSAA, you’re going to chew up VRAM even more aggressively. (Costs vary depending on the scheme; you might lose 4-16 MB x the FSAA level per million pixels on screen, depending on your GPU and driver.)
  • Off-screen rendering for things like the water reflections, the panels, the cloud shadows, the airplane shadow, etc. These don’t have to be in VRAM all of the time, but they have to be in VRAM almost all of the time. Because they are created by the GPU, the driver tries hard not to move these out of VRAM. You might lose 6 to 16 MB of VRAM for these, depending on the airplane you use and settings. (Given 4 1024×1024 panel regions, the panel will chew up 32 MB!)
  • Textures end up in VRAM, but only when they are used. The key here is “working set“. Only texures that are drawn need to be in VRAM, so over time stuff that isn’t on screen will be removed from VRAM. This is why when you see “600 MB of texture memory” in the rendering settings, there is no need to panic. The working set is usually much smaller.
  • OBJ geometry actually lives in VRAM too, sometimes. Again this is a working set issue; objects that aren’t drawn don’t get cached there.
  • Textures from airplanes and scenery packages that are not loaded don’t ever end up VRAM or even system memory; we only load what we need. Paged orthophotos have their resolution reduced while you fly, which makes their VRAM footprint quite small, even when drawn.

There are a few things authors and users are doing now that use up a lot of VRAM.

  • Monitors have gotten bigger; the VRAM used for the screen itself can never be swapped out, so the advent of the 1920×1200 LCD has taken its toll.

  • Since the panel texture is drawn off-screen, the panel texture is in an expensive category of VRAM use. Authors can limit the cost of this by using a single 1024×1024 panel region texture, if possible.

  • There is a hidden cost here: we pack together instrument textures into “atlases” to help with performance. The problem is that we pack for fit. Some of your instruments may be hidden but loaded into VRAM anyway because they sit in the same atlas texture as other instruments that are drawn. Thus you may be paying for the VRAM used by your entire panel even if a lot of it is hidden.

  • Because a lot of this VRAM is going to airplanes, reducing texture resolution doesn’t have as much impact as it used to; X-Plane tries to keep the user’s plane’s resolution as high as possible since it is viewed up close. The panel cannot have its resolution reduced at all.

But It Works Sometimes

I think what drives users crazy about VRAM exhaustion is that X-Plane will sometimes run smoothly, and then fail later. And sometimes really strange things, like moving X-Plane to the background, then the foreground, or changing liveries or rendering settings in a trivial way, will change performance.

I have discussed this a bit in past posts. But the key here is “working set”:

  • In any one frame, we can access everything that is permanently in VRAM, plus as much data as we can put through the PCIe bus from the CPU to the GPU.
  • We only need to access data in the working set (what is on screen).
  • Some of VRAM is permanently used (e.g. memory for the screen itself).
  • We lose PCIe bandwidth to both drawing from main memory (terrain is in your system memory and must go over the PCIe bus per frame) and from bandwidth spent juggling textures.

So the actual maximum throughput will have a lot to do with whether the video driver makes good decision about what lives in VRAM and what does not.

But how does the video card know what should be in VRAM? The answer is that it has to guess. It looks at frames going by and tries to use heuristics (that is computer-science geek speak for “carefully formulated wild guesses”) to decide what goes in VRAM and what does not. When the heuristics happen to make good decision, your video card kicks ass. And when it does not, your framerate tanks.

The only way to guarantee good framerate is to use so little VRAM that everything that needs to be in VRAM can be in VRAM, without depending on the video driver to make lucky guesses with its juggling.

And this helps us understand why strange things like livery reloads and backgrounding the sim can affect framerate (for better or worse). These operations seriously reshuffle VRAM – either by deleting textures and loading new ones, or by forcing everything out of VRAM so the video driver must try to repack video RAM all over again.

Unfortunately as a user this means that there’s not much you can do about this as a user. The main things would be: reduce screen size or FSAA or texture resolution, use fewer add-ons, or get more VRAM. Those peak bursts of framerate you see, they’re not going to be sustainable .

Posted in Aircraft, Development by | 3 Comments

Why Is My Airplane Slow?

Sometimes I get reports of a slow airplane, and I do a quick audit for performance problems. The trick to spotting performance problems is to divide and conquer: turn off various aspects of the airplane to see which aspect is really causing performance problems, then optimize that aspect.

Here are some of the specific tricks I do:

  • Change views; the panel will be drawn differently in the 2-d view, 3-d cockpit view, external view (when close or far – zoom out and the panel won’t be updated) vs. 2-d no HUD.

    If the 2-d view is slow but forward-no-HUD is not, your panel is expensive. If the 3-d view is slow but 2-d is not, one of your panels may be more expensive than the other (copy them in Plane-Maker from one to the other to see) or it could be that the preparation of the cockpit texture is slow.

  • Remove 3-d objects from your plane to test the cost of OBJs. Turn down X-Plane’s texture res or shrink your textures to see if texture memory is at issue. (Some airplane textures are not affected by the texture res settings, so you may have to manually shrink them.)

  • Be sure to play with X-Plane’s rendering settings; the GPU-specific options don’t always cost “the same”. For example, per pixel lighting is more expensive when there is more translucency on screen. If your airplane has a lot of overlapping surfaces or translucency this otherwise manageable setting might become too slow.

  • If you use panel regions, try switching to regular ATTR_cockpit. Panel regions provide superior lighting effects but can take more CPU time when you have a lot of instruments.

The key is to divide the many possible causes of performance problems to isolate one thing that can be optimized.

Posted in Aircraft, Development, Modeling by | Comments Off on Why Is My Airplane Slow?

Mirrored Normal Maps

Normal maps in X-Plane 940 have a funny property: if you flip the normal map horizontally or vertically, the bumps change direction. Things that “stuck out” now “stick in” and vice versa. (If you flip the normal map horizontally and vertically, the two cancel out and the normal map is not reversed.)

You can understand this by thinking of your normal map as a physical piece of metal with bumps punched in it. Flipping it horizontally really means rotating it horizontally to see the other side – now you see the back side of the bumps. Same with the vertical flip. Flip both and you have flipped it twice and it’s front-side forward again.

In a move that is either just in the nick of time or dangerously reckless, I have tweaked the normal map shader for 950 RC1 (coming out “real soon”) to detect and “fix” a flipped normal. In 950 rc1 the bumps in your normal map will always point in the same direction as the normal of your mesh, even if your UV map is flipped horizontally or vertically.

What does this mean to you, the modeler? It means that you can now mirror your normal map from the left to the right side of the airplane and the normal map will still have the bumps “sticking out” like you want.

I crammed this into 950 RC 1 because it looks like it’s a useful change that will restore flexibility to authors making highly detailed airplanes. Mirroring a symmetric airplane (which results in a horizontally mirrored normal map) is a pretty common thing to do, and if the text is applied as decals, this can be a big win in texture space savings.

I figured best to get the tweak in here now so people could take advantage of it. Plus, what’s an RC1 without an RC2?

Posted in Aircraft, Development, File Formats, Modeling by | 1 Comment

Musings on CSLs

Now that Wade has XSquawkBox 1.0.3 out, I’ve been thinking about CSLs – that is, the collections of simplified airplanes that XSquawkBox uses to draw the other users. The CSL system was invented back in the days of X-Plane 6, and it’s getting a bit long in the tooth. You can’t use OBJ8 files, and it doesn’t understand a lot of the modern rendering tricks that authors use with the standard tool chain.

Plane-Maker has advanced quite a bit since then too – to make the original CSL, I had to create a special one-off hacked build of Plane-Maker to export aircraft as OBJs. This capability is now built into Plane-Maker, works a lot better, and even supports animation.

X-Plane now exports a native OBJ drawing interface to plugins. Besides giving plugins access to the fully optimized native OBJ draw code, this also means that plugins can draw objects with per-pixel lighting.

One more piece of the puzzle: in France Austin announced that we were working on a new ATC engine. One goal of this new engine is to provide ATC to the AI planes, as well as your plane, so that the other aircraft interact seamlessly in one simulated environment. (In X-Plane 9, ATC only directs you, and the AI are rogue planes that try not to buzz you when you’re on the runway.)

This makes me wonder: should there be a next-gen CSL format that is shared between X-Plane and third parties, based on X-Plane doing the rendering work?

Posted in Aircraft, Development by | 4 Comments