If you have a DirectX 10 or 11 class video card (that is, a GeForce 8nnn or newer or a Radeon HD card) and you’re on a Mac, consider updating to OS X 10.6.x if you’re still on OS X 10.5.8.
10.6 has performance enhancements in the video drivers that I suspect will benefit X-Plane 9 users, but it will really matter for X-Plane 10. We need OS X 10.6 to expose some of the OpenGL extensions that these cards have. Thus 10.6 will get you faster frame-rate, more realistic lighting, and more efficient VRAM use.
(If you have an older card, I don’t know if you’ll get any benefit, although I doubt you’ll see a performance loss.)
X-Plane 9 allows you to categorize objects as being on the plane’s outside, inside, or glass. X-Plane depends on these flags being right for a few things:
- The draw order of the airplane is determined by the object types – glass is drawn last to avoid translucency artifacts.
- Interior light from the plane is only spilled on the “inside” objects.
- Glass objects are excluded from shadow calculations to avoid having opaque windows in the airplane shadow.
It is important that you use these flags as intended; X-Plane 10 depends on this information as well, and X-Plane 10’s global spill and global shadowing algorithms are more sensitive to incorrect categorization of objects than X-Plane 9’s forward renderer.
In particular, you should have glass for the airplane windows in an attached object tagged as type ‘glass’; do not attach your glass to the cockpit object, which cannot be categorized as glass. If you have an old plane with glass in the cockpit, consider cutting the object in half in a 3-d editor and attaching the glass separately.
(You should also use our prop disc animation, rather than use an OBJ for prop discs; the OBJ format doesn’t contain the z-buffer tricks necessary to make the prop look right.)
Sometimes these posts get off topic, sometimes in the direction of the art of computer programming, sometimes in the nature of the industry, and sometimes with pictures of the pets. This post is going to go off a bit into the subject of project management.
Randy and Tyler posted what was becoming clear (by the lack of an already existing beta): our estimated release date for X-Plane 10 was incorrect. Software project delays are pretty common, and often when a third party add-on is delayed, the community jumps to speculate about “what’s going on” inside the project and tries to infer whether the delay is an indication of serious problems.
I’d like to try to reframe the issue of delays in terms of an analogy. You ask me: how fast can you run a mile? I tell you “4 minutes and 15 seconds”. I then run a mile and you time me. My time: 6 minutes, 10 seconds.* What can we learn from this episode? I think we can learn two things:
- For a computer programmer, I am surprisingly fast – a six minute mile isn’t to be sneezed at when you spend your days sitting on your ass in front of a monitor drinking coffee.
- My ability to predict my own speed is not very good. I was pretty naive to think I could run a 4 minute mile – that’s what world class athletes run. My estimate was off by a fairly big error margin.
One thing we should not conclude is that because my mile time was 2 minutes slower than estimated, that I am a slow runner. The estimate sets up an expectation, but if the estimate is wrong, it’s not a useful metric of efficiency.
The same applies to X-Plane; we missed our original projected ship date because the estimation of when we would be done was not a very good estimate. This isn’t good for a few reasons:
- It creates uncertainty for third parties as to when a platform will change.
- It makes it difficult for marketing to properly plan a roll-out.
- It makes it difficult to balance the value of more features vs. an earlier release date (since we don’t know how much “time” we are trading for “features” if the time estimates are wrong).
But the delay is not at all a black mark for our team – on the contrary, they’re working their asses off and creating some really great work.
When looking at a project that will be delayed (because the original schedule was wrong) there’s a few things you can do:
- Add more people. This is quite often the wrong thing to do – please read the Mythical Man Month to understand why. Once your team is the right size, adding more warm bodies usually makes schedule delays worse and hurts efficiency.
- Remove features. This is the only real way to bring in a ship date.
- Move the date back.
When Austin and I were working on X-Plane 8, we hit a similar scheduling problem – what we had set out to do was going to take a lot longer than we thought. (Like X-Plane 10, we had just doubled the team size and begun a project that involved massive rewrites, which made it hard to ship until the work was fully complete. Sound familiar?) The difference? With X-Plane 8 we had contracted to ship with an external distributor for Thanksgiving, so we had to go for item 2 – we cut scope. What we cut was the world – that is, we shipped new global scenery only for the US, and the existing ENVs for the rest of the world. We also had to ship the artwork we had on hand, despite being unhappy with its quality. We didn’t finish the rest of the world and graphics we were happy with for another 11 months.
Option 2, cutting scope is painful and hard. Sometimes it is the right thing to do. In the case of X-Plane, however, we have the luxury to move the date back. With that in mind, we’re trying as hard as we can to keep feature-creep minimal and finish what we’ve already bit off, so we can get the release done and out the door.
* My mile time is not 6 minutes, 10 seconds…I would be astounded, and quite possibly in the ER if I could run that fast for any sustained amount of time.
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.
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.
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:
- Will X-Plane 10.0 have feature X immediately ‘on the DVD’?
- 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.
Just a quick note re: comments. Recently this blog has been attacked by spammers who copy existing legitimate comments and re-post then; their user name is a link to a click-harvesting web-site. I am doing my best to mark these comments as spam and not allow them.
Besides that, I am likely to nuke any comments that contain profanity, spam, repeated requests for tech support via the blog, and off-topic comments particularly on posts that have are meant for a narrow discussion (e.g. global scenery defects).
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.
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.
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.
