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.
This post is a bit of an experiment…we’ll see how it goes. When we cut the global scenery, we do a number of validations: we manually inspect some of the DSF tiles, we examine the Earth orbit textures (which are derived from the DSFs) as a quick way to look roughly at all of the tiles, we have a number of internal consistency checks in the generator, and we can compare our output to some of the input data (e.g. did we lose all of our water) to look for gross bugs. But we don’t have enough resources to manually examine all 18,000+ tiles in detail inside X-Plane.
So: if you have found a defect in a global scenery tile in version 9, please list the tile in the comments section of this post. I will try to give these “previously broken” tiles priority in manual inspection.
Note that the bugs we can expect in version 10 will be very different than in version 9 because we’ve really changed the global scenery generation process in nearly every important way. The underlying algorithms are heavily rewritten and data sources are very different. The goal here is to simply find areas that might have a higher probability of weirdness.
Let me try to be clear about what constitutes a broken tile and what does not. Please read this definition six or seven times before you post a comment.
- Do not report bugs of inaccurate data. If your favorite road is missing, or the coastline is in the wrong place, don’t report that here. That is not a defect in the rendering process; rather it is a limitation in the source data. I am not trying to collect a list of data inadequacies. We have already selected the new data for the new render. “Stuff is in the wrong place” is not a bug for this list!
- Really weird patterns are of interest. For example: I have seen some reports of very long thin bars of land going perfectly north along the edge of the tile, or a comb of mountain and valley, again perfectly vertical. These are bugs in the production process and I do want to know about them!
- Do not report errors in the placement of the 3-d layers (trees, roads, etc.). Since the 3-d layer is being completely rebuilt for version 10, none of these defects will be present in version 10. (They’ll be replaced with a totally new set of weird behaviors!)
- If an airport is too bumpy to use (with “flatten ” turned off in the sim), report this only if the terrain around the airport is grass. Basically the grass means that we tried to “fix” the airport in the v9 render and failed. If there is no grass (the airport is over forest or city) and it is bumpy, do not report it – that means it was added to apt.dat later.
- Do not report mismatches between the airport shape and the grassy patch; this is just the apt.dat file being updated.
If you have something to report (basically incorrect flattening of grassy airport areas and really weird coastline/terrain bugs that are clearly programming errors) please include three pieces of information:
- The DSF tile, e.g. +42-072
- The nearest ICAO of an airport near the bug (e.g. KBED)
- A very short description of what went wrong (e.g. “tall thin vertical lakes running through the entire DSF”).
Please only post defects of the above nature in the comments section of this blog post; to keep things clean I am going to nuke any off-topic comments on this post.
EDIT: see the first Squawk, Arista’s report on LOWS. This is a perfect report: it includes the DSF tile, the ICAOs, a brief but clear description, and it is a bug in how we process the data, not the data itself.
If you are planning on submitting an airport layout to Robin so that it is used to flatten terrain in the X-Plane 10 global scenery, please submit the layout to Robin no later than October 10th, 2010 (that is, 10/10/10).
If you have an incomplete but useful layout (e.g. the airport border is in place but not the taxiway signs, you can still submit it; we only consider border outlines and the pavement itself when flattening, not markings.
You do need both the border outline and all existing pavement. The reason for this is that the airport border is used to change the land class to grass, but water is only converted to land (if we have a coastline error) base on real pavement.
More info on airport layouts and how to submit data to Robin can be found here.
I posted a quick tip on how to create fence-like facades in WED. Basically WED doesn’t handle fences and other non-closed polygons very well, but you can work-around this. A future version will address this more completely.
This is my thinking on the WED roadmap:
-
WED 1.1 will relatively ship soon, without cosmetic and usability improvements. At this point the basic bugs (import/export) are fixed, so best to get out a finished, stable build so that people can at least edit overlays.
-
A future version will provide editing ATC layout information for X-Plane 10. This shouldn’t be too hard to get working, as we already have this in WED now so that we can develop test data for the new ATC system.
-
A future version will provide usability enhancements (e.g. previews of facades, etc.). I don’t have a ton of code done for this yet, but it’s important for everyone using WED for pretty much any purpose.
-
A future version will provide road editing since X-Plane 10 can drape roads.
I don’t know what order those 3 feature will come in, but they will all happen relatively soon after version 10 ships I think.
There’s a real difference between a useless beta (e.g. what we have with WED now) and a useful one. While the purpose of a beta program is to fix bugs, a beta can be useful if the features users must have work. I don’t think I will have time to finalize WED 2.0 this year, but I do think I will be able to fix the really nasty bugs, the ones that make it useless.
To that end I have fixed a number of crash-on-export bugs. To the users who filed complete crash-on-export bug reports: thank you! It was quite an education to see what was in some of these projects polygon-structure-wise.
If you filed a WED export bug, I may have requested feedback if you didn’t include the WED file. Basically I would like the minimal materials to fully reproduce the bug by opening the package and picking “Export to DSF”. For many packs this is just the Earth.wed file, although sometimes textures or text files may be necessary.
A number of the crash bugs are caused by degenerate polygons. For example, if your polygon crosses itself in an X shape, not only is this illegal in X-Plane, but it also drives the exporter crazy. With the next beta, WED will select polygons that failed to export to help you locate such problems.
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.)
There have been a few posts about X-Plane 10 in a few random places; here is a summary of all of the version 10 material that’s been previewed so far, and some notes on what is actually being shown.
First we had Paul’s Oshkosh 2010 video:
//www.youtube.com/watch?v=yCoDPNvOMP0?fs=1
I think this has been made clear already, but:
- The base simulator shown here is not X-Plane 10, it is X-Plane 9.
- Many of the airplanes shown here will be released for X-Plane 10.
- This is not showing the new X-Plane weather system or global lighting.
- Some of the content shown here are third party add-ons, available today for X-Plane 9.
The main purpose of this video was to show X-Plane off at Oshkosh; at the time we didn’t have X-Plane 10 in a state where we could do an exclusive version 10 preview.
Then I accidentally leaked two test videos of global illumination. This was strictly accidental: I was looking for a cheap way to post a large video for Austin and Propsman late at night and didn’t think anyone would sift through 191 zip files to find two obscurely named videos. I was wrong, and someone found them on the org. I appreciate that participants in the ensuing discussion withheld judgment; these were early test videos and don’t represent the final feature in any useful way. They do, however show off some of what global lighting will mean.
- This is the Cirrus Jet with landing lights implemented via global illumination. We get two distinct landing lights that cast specular hilights on the fuselage. As the door animates, it opens “into the light”.
- This is the Avanti Piaggio with strobes and beacons implemented via global illumination. The strobes cast light both on the fuselage and on the runway below the plane.
This second movie is typical of the kinds of tests I do: the beacon lighting is just awful – a gross huge red light splatted on the plane for test purposes. When I get the rendering engine code working I usually hand the feature off to Propsman or Sergio to tune the textures and art constants. In this case, the videos are pre-tuning.
Austin has posted three screen-shots of X-Plane 10-related content:
-
This is Javier’s new shuttle, which I believe will ship in version 10. I believe this shot may have been taken in X-Plane 9. So this is not the new weather system.
Some of these screenshots and Paul’s video were shot in X-Plane 9. By the time the new airplanes are finished, they will not be usable in version 9 – they will be version 10 only.
-
Propsman has done work on the lighting system. It can be subtle to see what’s going on here because the old runway lights looked pretty good too, but most of these billboard lights are actually rebuilt.
-
This night shot shows global illumination in the scenery system. The glow on the highway pavement is not rendered; it comes from the 3-d lamps along the side of the road. Similarly, the car headlights spill light on the pavement and each other as they drive. (Note how the highway lines are visible in the headlight spill even when there is no streetlight.)
One difficult problem with rendering a lit highway at night is that the lighting from street lamps on a highway tend to spill light on the surrounding terrain, an effect that is impossible to create with a LIT texture. If you look at the right side of the main highway at the bottom of the picture, you’ll see that the street light is casting light on the grass to the right of the highway too.
I think that that’s all we have posted. At least, it’s all I am aware of. I will go into some of the details of global illumination in another post.
A quick thought on procedural vs. algorithmic scenery: there was some discussion on the X-Plane dev list about procedural terrain; the Outerra screen shots have stirred up interest.
There is a fundamental difference between what you see with Outerra and what we do with our global scenery:
- Typically procedural scenery is based on the idea of ‘amplifying data’ – that is, making a little bit of data look more interesting by applying a recursive algorithm to “generate” detail.
- Algorithmic scenery involves taking a large amount of unique input data and translating it; the detail comes from not losing information in the source data.
The key difference is whether the resulting scenery comes from a process that “creates” information through a ‘procedure’ or “translates” information.
Our scenery process does a bit of both, but we are more in the algorithmic camp than procedural camp; the global scenery is produced from hundreds of GB of input data, and we are constantly looking for better input data to create more interesting and accurate output scenery.
In fact, I would say that we are becoming more algorithmic and less procedural. In version 9, the urban roads in non-US cities are “procedural” – an algorithm generates them from the terrain data, an algorithm, and some random noise. For version 10, we are importing OSM.
One thing I have noticed in the work on version 10 global scenery is that we’ve finally crossed a line. With version 9, the question was ‘what is the best data we can get’. With version 9, the question is ‘how much information can we keep’; we’ve reached a point where the resolution of our input data is so much higher than what can go on DVD, that it’s a question of filtering down, not synthesizing up the resolution.
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.
