Textures
Textures play a huge role in determining X-Plane frame rate. The harsh decision to use only one or two textures per airplane and only one texture per object was based on the enormous performance benefits to restricting objects and planes to one texture each.
(Think of each texture X-Plane uses as a crayon you use to color your scenery. But the box of crayons is in the other room, so each time you have to change crayons, it takes a long time. The one-texture-per object rule guarantees that X-Plane won’t be “changing crayons” all the time.)
Pack Textures
Video card memory is at a premium in X-Plane; this is obvious, but don’t waste space in your textures. If you can resize your image to be smaller in Photoshop without losing (much) quality, consider making the texture smaller. If you look at some of the textures Sergio Santagada has done for X-Plane, you will see that every pixel is utilized, and every image is reduced until each detail is one pixel. This helps maximize video card memory.
Use Fewer Large Textures
Use fewer large textures rather than lots of small ones. For example, use one large texture for many objects, allocating the texture space as needed. This both improves frame rate and gives you the flexibility to use non-power-of-2 rectangles within the one larger texture.
Use Textures for Nearby Objects
If you have so many textures that you will need multiple large bitmap files, combine objects that are nearby in your scenery onto one texture. This way if only some of your objects are visible, they will be more likely to all come from the same texture.
Use Alpha Only When Needed
If your texture does not have any transparent parts, make sure to save it without an alpha channel as a PNG file. X-Plane will enable alpha processing if the alpha channel is detected, even if the entire texture is opaque.
Make sure pixels that are supposed to be transparent are 100% transparent. It is faster on older video cards to render pixels that are totally transparent than to render pixels that are, say, 90% transparent. Also, translucent pixels may cause Z-buffer problems.
Terrain
The rule to use fewer larger textures applies doubly to terrain. In the old scenery system, it was best to use a 1024×1024 bitmap and apply the texture over multiple quads. Similar optimizations will help newer versions of X-Plane.
Objects
The overall rules for textures apply to objects as well, especially regarding sharing of textures. Here are some additional things that will help object performance.
Optimal Size for Objects
Probably the biggest factor in object performance is the number of objects vs. the number of polygons in the objects. Here you face a trade-off. There is a certain overhead for drawing an object at all, so making 1000 objects, each with one quad, will be a lot slower than making 1 object with 1000 quads. On the other hand, X-Plane chooses to draw or not draw an object based on whether any of the object is visible. So if your object is very very large, the whole object will be drawn even if only a tiny portion of it is on screen.
Please remember, these are only guidelines – use these guidelines when you have
flexibility as to how you build your objects, but do not bend over backward to hit these numbers. They are meant only to give you a sense of X-Plane’s ideal performance range.
The ideal object dimensions are no larger than 1000 meters on a side – 500 meters on a side is good. Larger than 1000 meters and you will be drawing the object even when it is almost entirely not on screen. 500 meters is the granularity of X-Plane’s rough culling pass.
Ideally an object should have as many polygons as possible – there is no upper limit to the number of polygons; better to have all of your polygons in one object than split between multiple objects. But it can be a problem to have an object with too few polygons. Objects with less than 24 vertices are not efficient in X-Plane. Do not add polygons just to get above this minimum, but if you have objects with a very small number of polygons, consider merging a few objects together.
- If an object models one entity, do not break it up for the sake of frame rate; it is very difficult to place multiple objects near each other and get precise alignment. For example, if you have a suspension bridge, use one object rather than three. (If you use three objects, getting the sections to line up will be impossible.
- If you have a number of objects near each other that always use the same texture and are not repeated, consider merging them into one bigger object, to get closer to the optimal size. For example, a series of trees or taxiway lines in an airport could be merged into larger chunks to hit optimal object size.
- By the same logic as above, consider breaking up collections of objects if they are too big (e.g. too large on screen.)
- If you are going to employ level of detail (explained in detail below), make sure you use separate objects, as level of detail decisions are done per object.
One other warning: If an object is heavily repeated, you may not want to merge it because this effectively means more memory usage. X-Plane’s object memory usage is primarily a function of the number of commands in the total set of OBJ files you use. The individual placements of an object are very cheap, but the OBJs themselves can be expensive. If you have 1000 house OBJs, each different, each used once, this is a lot more memory than 1000 placements of a single house object. So you may not want to make a single object with 100 houses if you were using one house object over and over…you will effectively be increasing memory usage.
For New Objects
Definitely take a look at the OBJ Overview document; it contains a ton of OBJ8 specific advice. One note in particular: if you view the bottom of your OBJ8 file (skip all of the IDX entries) to the commands section, the number of TRI commands is a good indication of how well optimized your object is. If you have a ton of commands after the IDX section, your object is probably not optimized.
Object Command Ordering
X-Plane does some minimal reordering of the commands in your object, but for the most part the commands in your object are executed in order. You will get best performance if:
- all of the commands of the same type are together when possible. (E.g. all of the TRI commands are back to back.
- all of the polygon commands (triangles, quads, etc.) are together. Keep the lines together. Keep the light commands together.
This may be impractical for authors and is mentioned primarily for programmers who develop software that creates OBJ files.
Note: the motivation for not optimizing polygons in OBJ files is partially to keep load times down (by having this done at scenery creation time) and partially to give authors total control over render order within an object. This allows an author to create an object with translucency without Z-buffer problems.
Level of Detail
Level of detail control is one of your most powerful tools to optimize object performance. The level of detail OBJ command lets you specify more than one version of your object for different distances, and also puts a hard limit on how far away your object will be drawn. LOD improves frame rate by reducing the amount of work X-Plane has to do in rendering objects.
If your object does not contain LOD commands, X-Plane will pick a maximum distance for your object based on its dimensions. X-Plane’s guess is just a guess and will either be too low (causing your object to disappear) or too high (causing your object to be drawn needlessly), so consider putting LOD commands on all objects, even if they only have one version.
Multiple representations of your object take time to create, so do an estimate of which objects are worth creating multiple versions of. Some examples:
- A skyscraper that is placed in the scenery once that contains 50 polygons. 50 polygons x 1 object is not a lot of polygons – creating a second version of the skyscraper is probably not worth it.
- The statue of liberty, as the centerpiece of a scenery package, modeled with 30,000 polygons. In this case, the one object does cost a lot, and may be visible from a long way away due to its large size. This is a case where a second LOD (with, say, 1000 or less polygons) could be worth it.
- A house used everywhere with 10 polygons. This is a dubious case – even though the house is used a lot, at best you will only save a few polygons, and the reduced LOD object will be below X-Plane’s efficient sizes. Experimentation will show whether this is a win, but it wouldn’t be the first object to optimize.
- A jetway, used 100 times on an airport, with 350 polygons. This is a huge win. This one object causes 35,000 polygons to be drawn, and all 100 objects are probably visible on final approach. Creating a reduced LOD version to be used 500 meters away with only 50 polygons will cut almost 30,000 polygons off of X-Plane’s load without much noticeable degradation.
Even with single representations, good LOD choices are important for frame rate. Taxiway signs, for example, should have low LOD levels because many of them are visible when overflying an airport, but they are very small and disappear from view rapidly.
Avoid hard quads
The hard quad command is more expensive than the regular quad command. Avoid using it unless the polygon absolutely has to be hard.
Facades
Unlike objects, each individual placement of a facade takes up additional memory. In other words, using 2 facade definitions once each takes only a tiny bit more memory than using one facade definition twice. Polygon memory for objects is saved once for the .OBJ file. Polygon memory for facades has to be created once for each instance of the facade because each facade is slightly different in shape. X-Plane has no mechanism for recognizing and pooling same-sized facades.
Avoid excess stretching
The biggest danger to performance from facades is to extrude a facade into a footprint that is much larger than the facade’s ideal size, or to add more floors than the facade’s ideal height.
When X-Plane “extrudes” a facade to make a building in your scenery, it looks at your panel and floor split points and takes as many or as few panels and floors as is needed to meet the height and wall length requirements specified by the DSF file. X-Plane combines adjacent panels, and only adds more polygons to cut out parts of the texture or to duplicate parts of the facade.
In the above picture, a facade is shown in its original form with cutlines and then in three instantiations. The quads X-Plane creates are shown by separating the facade into its component quads. In the first case, the facade is smaller than its ideal size, so four quads are produced. In the second case, the facade is the exact size of the texture, so only one quad is produced. In the third case, the quad has been stretched. Two quad are needed vertically, but many facades are needed horizontally because the facade is so much wider than the texture. This facade is horizontally overextended.
Avoid overextending facades either horizontally or vertically; at most a facade
instantiation should be no larger than twice its ideal size either horizontally or vertically. Make sure your facade definitions match the way they are used in the DSF. For example, if you have a facade that is used 100 times and is overextended to form 10 polygons horizontally and 10 polygons vertically, you will have 40000 polygons where you should have had 1600 polygons.