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 .
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.
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?
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?
X-Plane 9 has a number of recent features to let you customize the exterior lighting of your aircraft; see the wiki for notes and a sample plane.
X-Plane 940 introduced the concept of parameterized lights to support these features. Here’s the basic idea:
Named lights (available for quite a while now) let you add a light billboard to your model that we define. The idea is that since the lights are specified against a real world model (this light billboard should look roughly like a landing light) it lets us upgrade art assets and back the light with the fastest path on the graphics card.
The problem with landing lights is that they are one-size-fits all, and this is particularly problematic for airplanes, where the lights can look quite different in size and angle based on the size of the airplane. Parameterized lights fix this by letting you specify a limited number of parameters in your OBJ. By limiting the parameters that you can set, it means that we can still optimize the light when possible.
I took a few minutes today to round out the list of parameterized lights, and I think there will be 9.46 patch in which we can release them*. When we put 9.46 in beta I’ll update the example plane; the new set of lights will give you parameterized control over the navigation and taxi lights, as well as the generics, beacons, strobes and landing lights.
* We have a few small bug fixes we’ll roll out in 9.46.
X-Plane doesn’t natively and directly support popup panels, but that doesn’t mean you can’t pop them up. Generic instruments have a dataref-driven set of show-hide fields. (The “filters”.)
Now what you might not have realized is: groups have filters too! So you can hide an entire group with one filter, and you can put premade instruments in the group.
So…even though the FMS is a premade instrument with no filter fields, by grouping it you can show and hide it.
Important: the backgrounds of instruments are not shown or hidden. So if you want to do this, customize the FMS to have a transparent background, and use a generic rotary to put a real background behind it. The rotary goes in the group, and thus it can show and hide.
One more tip: clicking in 2-d goes through one instrument to another, for historical reasons. So if you pop up an instrument, you might want to hide the instruments it popped up over so clicks don’t affect them.
I am trying to be disciplined and put documentation on the X-Plane wiki, and limit the blog to announcements, rants, and explanations of what’s going on inside X-Plane.
You can read about custom lights here. The short of it is that a custom light is a billboard on an object where you (the author) texture the billboard (with part of the object texture), pick the texture coordinates and color, and optionally run all of these parameters through a dataref* that can modify them.
For named lights, the light texture comes from a texture atlas that Sergio made a few years ago – it’s a nice grid 8×8 pretty lights.
So…why can’t you use it with custom lights? Why do custom lights use the object texture?
The answer is: future compatibility. Sergio and I are actually already working on a new texture atlas for the sim’s built-in lights. (This has been a back-burner project for a while … I have no idea when we’ll actually productize this currently experimental work.) What happens when we create a new texture atlas with all of the lights moved around and scrambled? If your object referenced that texture, the texture coordinates would be incorrect.
Thus, for the lights where you specify texture coordinates (custom lights) you use your own texture. For named lights (where the texture coordinate is generated by X-Plane) it’s safe to use ours.
A Dangerous Bug
I found a bug in 940 that’s been in the sim for a while now: given the right strange combination of named and custom lights in a row, the sim would accidentally use Sergio’s texture atlas rather than the object’s texture for custom lights.
This is a mistake, a bug, and it will be fixed in the next 941 release candidate. I certainly hope there aren’t any objects out there relying on this erroneous behavior, which violates the OBJ spec and is pretty dangerous from a future compatibility standpoint.
* Dataresfs are normally thought of as data we read, so the idea of using them to “process” data is a bit of a bastardization of the original abstraction. You can read about the dataref scheme in detail here.
X-Plane 940 has these generic light things…what the heck are they? Here’s the story:
X-Plane has been growing a larger number of independently simulated landing lights with each patch. We started with one, then four, now we’re up to sixteen. Basically each landing light is a set of datarefs that the systems code monitors.
- You use a generic instrument to hook a panel switch up to a landing light dataref.
- The sim takes care of matching the landing light brightness with the switch depending on the electrical system status.
- Named lights can be used to visualize the landing lights.
See here for more info.
But what else lights up on an airplane? Sergio sent me the exterior lighting diagram for an MD-82, and it would make a Christmas tree blush. There are lights for the staircases, for the inlets, on the wings, pointing at the wings, the logo lights, the list goes on.
We have sixteen landing lights, so we could probably “borrow” a few to make inlet lights, logo lights, etc. But if we do that, the landing light will light up the runway when we turn on any of those other random lights.
Thus, generic lights were born. A generic light is a light on the plane that can be used for any purpose you want. They aren’t destined for a specific function like the strobes and nav lights. There are 64 of them, so divide them up and use them how you want. Just like landing lights, you use a generic light by:
- Using a generic instrument to control its “switch” from the panel.
- Using a named light to visualize it somewhere on the OBJs attached to your airplane.
Generic lights don’t cast any light on any other part of the plane – sorry. You can use ATTR_lit_level to light up part of your mesh dynamically when the generic light comes on though – the effect can be convincing if carefully authored.
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.
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.
