Tag: X-Plane 10

Curved Roads

At this point I can say with 99% confidence that X-Plane 10 will feature bezier curved roads. In X-Plane 9, a road is a line segment; you can simulate curved roads by using a lot of line segments, but the global scenery roads are pretty chunky.

X-Plane 10 allows for a road to be a bezier curve, allowing the specification of smooth curves with a small amount of data. This sets us up to trade off visual quality and performance using a rendering setting.

A few notes for authors:

  • Like all of the new v10 road features (and pretty much all of the new v10 scenery features), you don’t have to use bezier curves in your roads. They are there as an option if you want them.
  • X-Plane 10 will not make curves for you; road data that is defined as line segments in the DSF will be rendered as line segments. (This follows the principle that DSFs contain pre-processed scenery data, and the sim shows DSFs exactly as they are written.)

Pay No Attention to the Documentation

The DSF specification alludes to bezier curved roads; this “old way” of encoding curves was never supported in the sim – all versions of X-Plane ignore this data. The “old way” was how we thought we might do curves some day.

The version 10 curve encoding is different; the “old way” will continue to be ignored in version 10. So: do not use the DSF spec to try to make curved roads now. I will post detailed documentation on curved roads once version 10 is available to authors.

Posted in Development, File Formats, News, Scenery by | 14 Comments

A Cliff Shader

I have been stingy with pictures of next-gen global scenery for one reason: it’s really hard to get a nice shot of the global scenery that doesn’t show unfinished features. With something like global lighting I can zoom in and show just the new trick, but with global scenery, I can’t take a picture of a new house without showing a city block that looks funky due to a bug and a road that isn’t finished. Posting a working shot of the global scenery where some sub-systems have bugs and artifacts would just freak everyone out.

I figure if it’s obvious that the shot isn’t a production shot, I can get away with posting it though.

A lot of the times when I work on the rendering engine, it is with test textures like this. Our art team does their best to hide the seams between different art assets, so that the scenery looks like one continuous world. The problem for me is that the better they do, the harder it is for me to tell if the underlying shaders are doing what they should do.

So alpilotx sent this test: it’s all of the Innsbruck area painted with a test texture. What’s new and interesting here is that the flat, hill, and cliff areas are all shaded by a single shader that selects between multiple textures (and rotates the textures) based on the underlying mesh.

We are adding the cliff shader to version 10 for a few reasons:

  • Often we can get better cliff and hill definition by processing in the shader than by painting different triangles with different textures; our ability to control the transitions using different .ter files is limited.
  • Using one slope-sensitive shader saves over-draw and triangle count, which makes the DSFs faster and smaller.
  • Some day we may have the GPU distorting mountains on the fly to make them more mountainous. If we do, we need the GPU to also apply the correct textures; if the cliff areas are precomputed then they won’t respond to GPU distortion.
Posted in Development, News, Scenery by | 14 Comments

Will X-Plane 10 Have X?

If I could have a dime for every email I have received that asks some form of “will X-Plane 10 have X” (where X is a feature or enhancement), I wouldn’t need to actually work on X-Plane anymore. (If you think your email triggered this post, well, there are approximately 100 other users who have asked the same thing.)

Simply put: I have no idea and I’m not going to try to answer these questions any more. Here’s why:

For as long as I have been involved with X-Plane, Laminar Research has provided free patches to the simulator throughout a major version run, and those patches have included not only performance enhancements and bug fixes, but also major new features.

So the question “will X-Plane 10 have X” can really mean one of two things:

  1. Will X-Plane 10.0 have feature X immediately ‘on the DVD’?
  2. Will X-Plane 10.x ever have feature X in a free patch before the major version run is over.

I can answer the first question, because we are relatively locked down on what features are still on the table for 10.0 vs. what must wait, but I think it’s at best confusing to do so. If a feature isn’t on the DVD, it might be in a free patch within weeks; it might be available by the time you get your DVD. Whether a feature is on the DVD is of interest to us as we plan our release, but I don’t think it actually makes a huge difference to users with internet connections.

Consider 64-bit – it’s something we want to look at during the version 10 run but we’re not going dig into it until after we get 10.0 out. So will 10.0 be 64-bit? No. But there will probably be a 64-bit patch available for free. I think you can see why I don’t want to post “X-Plane 10 will not be 64 bit.”

I cannot possibly answer the second question, because versions run over several years, and what we code for the end of the version run will depend on market conditions and technology that don’t exist now. One of the nice things about patching X-Plane frequently is that we can revise our plans as conditions change.

Consider the question “how many cores will X-Plane 8 utilize” had you asked the question during X-Plane 8.0. When X-Plane 8.0 came out, the answer was “only one” and we had no road-map to change that. For that matter, multi-core machines were rare and exotic beasts at the time, so multi-core wasn’t a priority.

Within the three years of X-Plane 8’s major version run, we ended up supporting multi-core for scenery mesh loading, something that couldn’t have been easily predicted at the beginning of the version run.

Finally, a note on release planning: now is absolutely not a good time to ask for features. The features that will ship in X-Plane 10.0 have already been determined, and since we’d like to ship X-Plane 10 sooner rather than later, I don’t think there’s anything you can say that would make us add a feature to 10.0.

All future features are going into a 10.x “bucket” for planning purposes. Since Austin, Chris and I are up to our eyeballs in code and the art team is red-lined too, we’re not spending any time sifting through 10.x buckets right now. If you send us a feature request, the very best case is that we dump it in a holding list for later; the worse case is that we lose track of the request in the chaos.

That doesn’t mean that we don’t care about 10.x. It’s just that we are very much heads down in the 10.0 release now and won’t look up until it’s done.

Posted in Development, News, Scenery by | 28 Comments

Draped Object Geometry in X-Plane 10

I have mentioned a few of the scenery engine features coming in X-Plane 10 that will be of interest to authors: global illumination, conditional parts of OBJs (to cope with variable rendering settings). There is another general feature coming that will make authoring scenery a lot easier, I hope.

X-Plane 9’s rendering engine has the ability to drape geometry. Draped geometry are meshes that are ‘dropped’ onto the terrain and hug the underlying base mesh perfectly. The most common example of this is the runways: because the runways ‘drape’ the ground, the runway shows any curvature and bumps from the underlying base mesh. This is who we create sloping and non-flat runways.

Authors can drape geometry as well, using a draped polygon (.pol) primitive in an overlay. Such draped geometry is useful any time you want to add more “paint” to the ground, e.g. to put down a taxiway, parking markings, dirt, grass, a driveway for a house, you name it.

There is one case in X-Plane 9 where you cannot drape geometry: in an object. In an object, all geometry is aligned to the object, and will only interact nicely with the ground if you get lucky. For example, if you model a house with a sidewalk, the sidewalk won’t “sit” on the ground if the ground turns out to be sloped. You can use ATTR_poly_os to hide the artifacts, but ATTR_poly_os really can’t cope with mismatches between the OBJ and the terrain under it.

X-Plane 10 will introduce a new object attribute: ATTR_draped. Draped geometry in an object is actually draped down onto the terrain when the object is placed in the scenery. This means that the draped part of the object will hug the ground perfectly with no interference or Z thrash. You get all of the quality of a draped polygon with the convenience of an OBJ.

There are a few possible uses for ATTR_draped:

  • Any time a 3-d model needs some ground details attached to it, e.g. the driveway near a house, draped geometry provides a good fit with the ground and good alignment with the object.
  • Any time you want to include a pre-made ground decal (E.g. a painted parking spot on a taxiway), the ground detail can be modeled as an object using draped geometry.

ATTR_draped will facilitate creating and sharing custom details for airports and streamline the authoring process.

Posted in Development, File Formats, News, Scenery by | 8 Comments

Scenery Compatibility and Version 10

This is my expectation for scenery compatibility in X-Plane 10:

Scenery based on DSFs, OBJs, and other version 8/9 file formats should work with X-Plane 10 unmodified.

This includes orthophoto scenery based on DSFs – we’re not throwing that code out.

The new rendering engine features for version 10 (and there are a lot of them) are extensions – new ways to render things, new types of art assets.

I do believe that we may drop support for ENV scenery files in version 10. We’ve had DSF for six years now, and ENV’s capabilities (a 500m mesh, very limited orthophoto resolution) aren’t useful to today’s users. You can use DSF2Text/XGrinder to extract custom object placements from an ENV for use in a new overlay.

We may also drop support for OBJ version 2. (Yes, we still load OBJs version 2.) OBJ version 2 is the OBJ file format from X-Plane 6, the one before OBJ 7. If you have any old OBJs (version 2 or 700) you can use XGrinder to automatically batch convert them to OBJ8.

Posted in Development, File Formats, News, Scenery by | 1 Comment

Coping With Variable Rendering Options In X-Plane 10

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.

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

No One Has All of X-Plane 10

I commented on this before, but, like the Funniest Joke in the World, no one team member has all of X-Plane 10. We’re all working away madly at our own parts, separately. This means that if one of us has code or art that isn’t quite ready for prime-time, it hopefully doesn’t slow anyone else down too much.

I mention this because I see a lot of commentary on the X-Plane 10 preview pictures where the comment is analyzing a part of the picture that actually isn’t X-Plane 10 at all! Those pictures are coming right off of developer machines, and that developer probably has some new stuff and some old stuff. Not only does the developer probably not have everyone else’s parts of X-Plane, but that developer probably has everything except his own work turned off or way down to keep sim load time down. I don’t fly with 20 AI planes when I work on scenery, and Austin doesn’t load full scenery at max res when he works on the flight model.

So when you look at the screenshots, just bear in mind that they are showing one new piece of technology pretty well, and pretty much everything else on screen is going to be hit or miss.

Posted in Development, News by | 4 Comments

Orthophotos Are Not Going Away

I mean to blog this a while ago, and Austin has moved on to new missives about the future of X-Plane, but:

A while ago Austin posted to the news list describing our approach to global scenery (that is, the scenery that ships with the sim), and he said some, well, rather disrespectful things toward orthophotos:

Orthophotos are garbage. I see this all the time. I am zooming along in an airplane looking that rooftops of WalMarts painted flat onto the ground. And the rooftops are blurry. And pixelated. And with a magenta or purple tint. And with big blurry shears right through the middle of them when they fall between offset satellite passes. It looks just terrible.

So first let me point out a few obvious things:

  1. There was never any chance that the global scenery would be based on orthophotos – not in v8, not in v9, not in v10. Simply put, we can’t ship you 900 DVDs in a dump-truck. Orthophotos of any reasonable quality are too large for covering the entire world in the base X-Plane product. This is not a change or new to v10.

  2. X-Plane is very capable of handling third party orthophoto scenery. We invested a bunch of engineering in this in the v9 run, and that code is not going away in v10. X-Plane will page orthophotos on multiple cores so that you get smooth flight and crisp images. If you want to see some orthophoto that don’t look blurry or pixelated, look here.

  3. DSF-based scenery that works in X-Plane 9 will work in X-Plane 10, unmodified. We are not getting rid of any modern scenery file formats.

Beating Ourselves Up

Austin continues in his rant^H^H^H^Hdiscussion, with this:

Then, to make the 2-dimensional, blurry, pixellated, mis-colored, distorted roof of a WalMart painted on the ground look even worse, if you throw in some REAL roads or auto-generated buildings, they invariably fall ACROSS the roof of the WalMart painted on the ground, compounding the wretched orthophoto with an Escher-like rendering-error. This looks terrible, and is not even plausible.

This is a critique of the version 8 and 9 global scenery. In fact, it is an observation of the fundamental problem with the urban global scenery: we never found a way to synchronize the real-world-driven and real-world derived 3-d scenery (real roads with plausible buildings and forests in between) with the photo-based land-class textures running underneath.

Ironically, this is not a problem with orthophotos (that is, specific photos placed in the world where they belong) per se. It’s really a problem with how to combine 3-d with land class textures. I don’t believe anyone has solved this problem yet for global scenery; if you look at FSX, there isn’t a lot of real world vector data to interfere with the land classes and their autogen.

In fact, orthophotos can look very good when they are combined with 3-d in a correlated way. For example, take a look at this screenshot of FlyTampa’s KBUF . They are using an orthophoto but they are putting matching 3-d on top of it, which makes things look good close up.

The Global Scenery Problem

I’ll leave you with this thought: the problem for the version 10 global scenery is to combine:

  1. the plausibility that you get from having synchronized 3-d and ground textures.
  2. the detail we’ve come to expect in photo-based scenery textures.
  3. the realism you get from using real vector data for the real world.

The current global scenery manages points 2 and 3 but fails pretty badly on point 1. That is what we are trying to address in X-Plane 10.

Posted in Development, News by | 2 Comments

Airport Layouts: Your Cutoff is 10/10/10

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.

Posted in Development, News, Scenery by | 5 Comments

Revisiting Texture Compression

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:

  1. Because the image is already compressed, we save CPU time when loading the texture that would be spent compressing while X-Plane is running.
  2. 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.
  3. 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.

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