X-Plane 10 will have rendering options for global illumination and global shadows. This leaves one question: what if the user has these features disabled?
The plan for version 10 is this: the OBJ file format will have some extensions to allow conditional commands based on rendering settings. A few notes on these conditional commands:
- They will only be based on rendering settings.
- They will be evaluated once when the object is loaded. (If rendering settings change, the object will be reloaded.)
The idea is to be able to change which lit texture you use or remove a set of shadow polygons depending on rendering settings.
The conditionals are evaluated once at load time so that the object can be fully optimized based on the particular set of conditionals used. For example, if your drop shadow (with ATTR_poly_os) is fully removed at load time (because global shadows are on) your object now has fewer attributes, which is good for frame-rate.
This is very different from ANIM_hide. The hide animation may or may not hide depending on datarefs; to keep this fast, you cannot “hide” an attribute, only triangles. This means you “pay” for your atttributes no matter what.
The motivation for both designs is this: if the set of attributes in a file never changes (e.g. they are either conditionally removed at file load once, or they are always present regardless of animation) then we can optimize the attributes of an object once knowing how they relate to each other, to create the leanest, meanest OBJ.
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.
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.)
I have updated some of the facade documentation on the wiki with new performance tips for using facades.
A few quick notes:
- Your facades must be counter-clockwise (when viewed from above). Do not repeat the first point; X-Plane will “close” your building for you. (A four sided building should have four points, not five.)
- If you turn off two-sided facade drawing and your walls look wrong (and your roof disappears) your facade is wound in the wrong direction.
The performance tips go into a fair amount of detail about saving memory. Most of X-Plane’s rendering fall into two categories:
- Shared meshes (objects), where the geometry of the object is saved once and used lots of times. Objects usually hurt frame-rate by consuming CPU time, because for each drawing of the object, we have to do some setup to draw that shared geometry in a different location. (Version ten should feature some major improvements in object efficiency.)
- Non-shared meshes (everything else), where every single “instance” of a tree, facade, forest, etc. is uniquely constructed in memory. Non-shared messages are very fast (because we can submit a huge pile of non-shared messages to the video card in one shot) but they consume a lot of memory (because we pay for RAM per building/tree, not just once). Typically non-shared meshes are limited by virtual address space, not by framerate.
Facades are non-shared meshes, so the performance tips focus on how to limit the amount of RAM needed to represent your facade.
We have Tyler working for us again for the summer (last summer he did a very nice and much needed rework of the X-Plane manual), and among his projects is cleaning up the mess that is scenery documentation.
We are moving the scenery documentation from their own dedicated site to the X-Plane wiki. As of this writing, as you can tell, it’s a work in progress. There are a few reasons why we decided to consolidate to the wiki:
- The scenery website is the very best of 1995 technology – unmanaged php in a big mess of files. We wanted to get the site under some kind of content management system, and MediaWiki is already working well for us for other docs.
- There is a lot of overlap between modeling techniques for scenery and modeling techniques for airplanes, so having all of the third party authoring docs in one place makes sense.
It’ll be a few more weeks before everything is organized.
Tyler is also reviewing all of the documentation. I have had a lot of trouble trying to document the scenery system, partly because I have been working on it for years, and thus I have no sense of what people don’t know. Since Tyler hadn’t done any scenery work before, he was able to read the documents and go “hey Ben, you keep talking about X but you never defined what it is.” The resulting edits should make the docs a lot clearer.
In order to understand the difference between hiding geometry and disabling drawing, you need to understand that an OBJ triangle can serve many purposes. Broadly, those purposes are:
- Drawing (the most basic use).
- Collision detection, of which we have three flavors: collision of the plane with the object (“hard surfaces”, or “physics”), collision of the mouse with the panel (manipulators, or clickable triangles) and collisions of the camera with the airplane (“solid camera”, which constrains the camera).
Any given triangle can be drawn and/or used to check for any of these collisions*; attributes change what the triangle is used for.
By default, all triangles are drawn; ATTR_draw_disable marks future triangles as not being drawn. This allows you to make a triangle that is used only for collisions. Examples might include a “hot spot” in front of a region on the panel (the hot spot might be easier to click than a small switch) and an invisible simple mesh to constrain the camera.
By comparison, ANIM_hide effectively removes some triangles from your model (temporarily) for all uses – drawing and collision detection of any kind. If a door is hidden, it’s not only not drawn, but it’s not going to stop the camera moving through it either.
Some key points to these distinctions:
- Categorizing what a triangle is used for (drawing, various flavors of collisions) is static – that is, it is always the same for the object and never changes with datarefs or animation. This is intentional for performance reasons!
- Animation to hide triangles affects the triangle in every way consistently – drawing and collisions.
Generally, you will get better performance improvements by removing categories from a triangle than by hiding it. (That is, it is better to not have manipulators on your cockpit, so it isn’t mouse-click collision-checked, than to hide it.) But the purpose of ATTR_draw_disable and ANIM_hide are different enough that which you use will be determined by the effect you are trying to create.
Finally, note that hiding an object completely (that is, the object does no drawing) does not provide the maximum performance benefit of not having an object at all. ANIM_hide was created to allow authors to create clever effects, not as a performance enhancer!
* This is not quite accurate: airplane-object collision checks are only available in scenery objects, and camera/airplane or mouse/panel collision checks are only available in the cockpit object.
In X-Plane there are two fundamental ways that a texture can be painted “over” a background image:
- Blending, whereby the alpha channel of the new top layer decides how much we see the top layer vs. the background.
- Additive Lighting, whereby the new texture makes the background lighter.
Blending is more common. For example, if you build an OBJ, the object appears “in front of” the terrain via blending. With blending, you put the color of your new layer in the RGB channels and use the alpha channel to indicate opacity. 1.0 alpha = 100% opaque, 0.0 alpha = 0% opaque, and alpha in between will create a blend. If you omit an alpha channel, X-Plane will treat the entire layer as 100% opaque.
When a layer is applied using additive lighting, the resulting color is the sum of the background plus the new color, clamped to the maximum brightness we can show on screen. Additive lighting is good for simulating effects that really “add light”. Some examples of additive lighting in X-Plane:
- All lighting billboards are drawn additively.
- Instrument overlays are additive if you pick the appropriate mode in Plane-Maker. (The option is labeled “glass” for generics, since most glass instruments work by adding light to a nearly black screen.)
- The emissive (_lit) texture of an object is added to the albedo (daytime) texture using additive lighting.
Now just a little bit of math. In RGB color terms, black = 0,0,0 and white = 1,1,1. So if we add a pure black texture to a background additively we get:
new_r = old_r + overlay = old_r + 0 = old_r
new_g = old_g + overlay = old_g + 0 = old_g
new_b = old_b + overlay = old_b + 0 = old_b
In other words,when using additive light, adding “black” does nothing, preserving the background.
And this brings me to my main point: any time you have additive lighting you don’t need an alpha channel. You can simply make your additive lighting texture black for the parts you want to be “transparent”.
This is why I generally recommend that emissive _LIT textures for objects not have an alpha channel. In fact, for “back-lit” and “additive” instruments (these are instruments that use a second emissive _LIT texture) Plane-Maker will indicate a warning if the texture has an alpha channel. If you have a texture that is applied additively, you don’t need alpha.
At this point you might be wondering: Ben, if additive lighting doesn’t require alpha, and all lighting billboards are drawn additively, why the heck is there an alpha channel for custom lights?
The short answer is: there probably doesn’t need to be one; the original setup for lighting billboards inherited a number of idioms from older versions of X-Plane, going back to versions where lighting billboards were not additive* (and thus alpha was necessary).
The long answer is: the alpha channel is often as a general “intensity” control to turn the light up and down in amplitude, while the RGB channels are often re-interpreted in strange ways. So while RGBA color is not necessary from a graphics standpoint, it is handy that there are four color channels in the custom lights because that gives us one more parameter to play with when designing really compicated lights (like VASIs).
* Note that lighting billboards that aren’t additive don’t look very good…hence Austin switched to additive billboards.
Back in olden times (read: X-Plane 6) X-Plane would look for file names with special extensions to enable special features. For example, in many cases appending the suffix _LIT to your texture name specified that you wanted a second emissive texture attached to your scenery.*
Then I showed up and started replacing the “find by extension” scheme with specific commands in configuration files to induce special behavior. On pretty much all of the modern text file formats, you need to use TEXTURE_LIT to specify your emissive texture, and once you use this command, you can use any suffix you want.
Why the change? I had three reasons:
Features by file naming convention is ugly. That’s just an aesthetic decision by me, and most users find file extensions simpler, so if this was the only reason, I’d be a bit of a jerk.
File naming conventions don’t grow over time. With file naming conventions, additional features would mean truly crazy conventions. Consider terrain files, where any terrain can be loaded with wrapped or clamped edges. (Wrapped edges are appropriate for repeating tiles of “land class” and clamped edges are appropriate for orthophotos.) We would end up with my_texture, my_texture_LIT, my_texture_wrapped, my_texture_wrapped_LIT, etc. What about the scale of the texture? What if we implement seasons? my_texture_2000_2000_wrapped_summer_LIT.png it is.*
By putting features in text files, we leave room for future expansion, and we have a lot more room to attach data to an image or control shading.
Probably most important: going to disk and loading lots of images is slow, so X-Plane loads images in the background while you fly. But checking the disk to see if my_texture_LIT exists is a disk operation too, and it is potentially one that we have to do immediately to understand our art assets. By having information about art assets in the text files and not file naming conventions, we can read one text file, rather than searching for all possible combinations of file extensions.
With X-Plane 9 we’re starting to see enough complexity in shading configurations and options that file names would be a non-starter. Consider some of the new features in version 9: normal maps and paged orthophotos. X-Plane 10 will introduce even more rendering and shading capabilities. These configuration options are better kept in a text file than a file name.
* Actually, Sergio and Austin were heading in that direction. Note that the names of the old ENV land classes were in the form CropCool0_000.dds. What are all the numbers? I don’t know, but Sergio had a plan to use them to select lots of different textures. This scheme was never implemented.
Austin attended the French X-Plane Congress last weekend; in response to some questions I have received, I want to clarify what is planned for DSF and X-Plane 10.
X-Plane 10 will extend DSF scenery capabilities by providing a number of new art asset types, as well as extensions to existing art asset file formats. We will not be changing the DSF file format or breaking compatibility with existing DSF scenery. If your DSF scenery works with version 9, I expect that it will work with version 10 as is.
(In fact, it looks like we do not even need to add new DSF extensions; DSF was designed to be a generic container for geometry data and properties, so we can usually extend X-Plane’s scenery system by simply defining new art asset classes and properties.)
An example will illustrate what I mean by extending the art assets, not DSF.
In X-Plane 9, you create a forest (whether in a base mesh or overlay DSF) by creating a DSF polygon referencing a .for (forest) art asset. X-Plane will render this by filling the area inside the polygon with lots of trees.
In X-Plane 10, you will be able to optionally tell X-Plane to put the trees only on the edge of the polygon, rather than filling the entire inside. (This feature will be controlled by using values on the polygon parameter that are larger than 255, at least I think.) This will mean that you can use .for files and DSF polygon not only to create forest areas, but also to create rows of trees along the edges of roads or fields. A row of trees made by a .for file and DSF polygon will render much faster than a large number of individual OBJ-based trees.
This kind of art asset extension is similar to what we have already seen; X-Plane 850 introduced three new art asset types (.str object strings, .lin line paint, and .pol draped polygons) that all produced new rendering tricks using DSF polygons. These art assets were added to provide high performance rendering of airport surface areas. The new art assets didn’t require any change to DSF because the representation of the position of these art assets is something DSF has always done: simple polygons.
DSF won’t last forever, but at least for X-Plane 10 it looks like we can do a third full cycle of the sim using DSF as our base container format for scenery position data.
In my previous post I tried to break an OBJ down into a few basic sections:
- Global properties of the OBJ.
- Raw Mesh Data
- Commands, which in turn set per-batch state and then draw the batches.
The performance cost of an OBJ feature often has a lot to do with where in the OBJ the command shows up, e.g. is it global or per batch.
Global properties tend to affect OBJ performance on a one-time basis. For example, if you use cockpit regions, you pay a fairly large penalty for having the panel texture be set up even if you only apply that panel texture to a single texture. Sure enough, COCKPIT_REGION is in the global properties section of an OBJ.
Per-batch properties affect the OBJ in two ways:
- Every command you see in the commands section is going to involve some CPU intervention. A very long commands section is more work for an OBJ.
- Every time there are attributes between TRIS commands, it defines a new “batch” – that is, a separate instruction to the graphics card to draw a new and distinct setup. Think of this as shutting down the factory to reconfigure the assembly line.
Generally batch count is more important than total commands. In other words, in evaluating this:
TRIS 0 300
ATTR_light_level 0 1 some_dataref
TRIS 300 12
the fact that there are two attributes is less interesting than the fact that there are two batches (the two TRIS commands run with different state). Even if you got rid of the no-blend attribute, you’d still have two batches because of the light-level change.
The most powerful aspect of the OBJ format is bulk data handling – that is, you have to add a huge number of triangles before the number of triangles becomes a performance problem.
For this reason, you should never use an attribute to reduce geometry count. A few examples:
- Don’t use ATTR_no_cull to reduce triangle count – simply issue the indices of the triangle twice.
- Don’t use ATTR_flat_shade to reduce vertex count – simply use more vertices with correct per-vertex normals to simulate flat shading.
- Prefer texturing to materials whenever possible.
Finally a note on weighting: for airplanes, where the total number of objects is low (a few dozen) global object properties often matter most. For example, on an airplane, choosing to use huge panel regions, or huge textures can make a big difference in performance. By comparison, batches aren’t that expensive unless you do something really crazy.
By comparison, for scenery, batches matter more; X-Plane will share the global properties of objects across hundreds or thousands of objects, but each batch hurts framerate. So when making autogen-style scenery, batches are most important.