Just an FYI: when it rains it pours. Normally betas increase load on our set of update servers. To compound this, one of them is suffering a midlife crisis^H^H^H^H^H^H^H^Hhard drive failure.* We’re working on it now; hopefully it will be resolved in the next 24 hours.
EDIT: the update server is back up – our host not only swapped out the drive, but the whole box. We’ll have to take it down one more time in the future, but for the most part I think we’re out of the woods.
Another note on servers: Chris has restructured X-Plane for Android to separately download the art assets from our servers, rather than contain all art assets in the actual download. What he found after several painful weeks was that the Android store is not yet reliable for large apps. While the official app size limit is 50 MB, many phones have problems with their configuration that cause downloads to fail. When the user buys our app and the download fails, they get angry at us. (X-Plane may have been, until it was restructured, one of the largest Android game APKs. The other games with large amounts of 3-d content were already doing separate downloads.)
We originally wanted to build a monolithic app (everything in the APK) because we thought that this would provide the simplest, easiest configuration to maintain, and thus hassle-free installation for our users. You get the APK, you install it, you fly! Unfortunately, the Android Market isn’t reliable for such a large download, so we had to re-evaluate.
The new system downloads only the core app from the Android Market and then pulls the art assets from one of our servers. So far this appears to be an improvement. If/when Google provides an integrated solution, we will probably switch back to it to simplify the process again (right now we have two points of failure: the Android Market and our server farm, which, per the above notes, sometimes does fail). But for now, we’ll host the apps and try to give people the best download experience we can.
Finally, I will try to roll out at least a beta of new installers some time this week. The new installer simultaneously downloads from multiple servers, with a more efficient HTTP implementation; this should hopefully result in better download times and also lower server load per demo.
* Chris pointed out: most normal humans don’t know what this ^H^H^H^H is about…it’s nerd-speak for the delete key, e.g. to undo a text. ^H is control-H, which you may find works just like the delete key. Yes, I’m a huge nerd.
First, Happy New Year! As is typical, I’ve been quiet on the blog because things have been insanely busy here at work. Just to give you an idea of the insanity:
- There will be a 9.63 relatively soon – the bug driving this is some Linux distros not finding the DVD. But we’ll get a few new datarefs in there too.
- We have new updaters and installers to get tested, again addressing Linux DVD issues, but also with updated web download code that should give a nice speed boost.
- Chris has been working hard on Android. X-Plane for Android is pretty much the biggest APK anyone has tried to ship, and as a result we’ve hit a number of problems with the market that we are going to work around.
- All that’s just the side show; X-Plane 10 development is of course the meat and potatoes.
Now, about visibility. X-Plane 9 restricts ground visibility to 25 nm (about 46 km) in an attempt to prevent you from seeing off the edge of scenery tiles. Many users have expressed (some more persistently than I would have liked) an interest in longer range visibility. Austin recently posted a note to X-Plane.org discussing level of detail and distance management in the new weather system, and users immediately picked up on his mention of 100 nm visibility. Here’s what we’re thinking; all of this is subject to change as we keep working on the product.
First, visibility: you can come up with a formula for the distance to the horizon based on height above a sphere: d = sqrt((r+h)^2 – r^2) where r is the radius of the planet and h is the height above the planet. Since the Earth is roughly 6 million meters in radius, we get a visibility to the horizon of:
100 meters: 34.6 km
500 meters: 77.4 km
1000 meters: 109.5 km
10000 meters: 346.5 km
Clearly a little bit of altitude lets you see a long way.
But there’s more to it than that: X-Plane has always changed the visible distance with altitude. The 25 nm limit applies to surface observations (which is what you get from a METAR). As you move up into orbit, that distance is scaled out to the horizon distance, so that you can see the whole planet from orbit. That scaling can reveal the edge of DSFs, which are blended into the planet when volumetric fog is enabled.
So here is what I think we really need to do:
-
We do need a larger ‘surface level’ maximum visibility, so that distant features are visible from the ground.
-
We need a scaling from ground to upper atmospheric visibility that gives us more visibility sooner; one of the problems with version 9 is that the increase of visibility is slow, which gives mid-elevations a hazy look.
-
In the long term, we need to load more DSFs, probably twelve instead of six. X-Plane 10 already has some improvements in how scenery shift is done, but my guess is that we can’t productize this until we have a 64-bit build (since more DSFs chew more memory), so I expect this to happen in a patch.
-
We need to add elevation displacement to the whole-Earth planet render, so that the blend between DSFs and the planet don’t have huge height gaps at high-elevation locations. I am hoping we’ll have this in 10.0, but it is not coded yet. (Usually we recut the planet textures last, since they are cut off of the DSFs.)
-
We need to improve the quality of haze, fog and atmospherics. In real life, atmospheric scattering reduces the contrast of far away terrain. I believe that correct scattering could make a huge difference in the quality of the transition from DSF to planet, the required tex res (we need less if we scatter more), and generally it would be a big contribution to the realism of the image.
I’m not sure how much of this we’ll get into 10.0; I have a prototype of Sean O’Neil’s atmospheric scattering shader from GPU Gems 2 running in the sim, but I don’t think it’s shippable. I do hope we’ll get at least some scattering in place, with improvements in patches.
That’s a road map, at least. If there’s a take-away point, it’s this: increasing visibility is complex and involves a lot of parts of the sim and there are still significant parts that need work. So I really don’t know if we’ll hit some kind of hitch or problem that requires us to back off visibility.
Austin’s comments about 100 nm visibility reflect what the slider in the sim happens to be set to now. It’s also a design goal of the new weather system – that is, we want the new weather system to handle significantly larger distances (and have better scalability) than the old one did.
It shipped! X-Plane Mobile is now available for Android phones – look in the Android market under “X-Plane 9”.
Edit: Chris sent me this QR Code – scan it to go to the store listing.
Edit: if you either cannot see X-Plane in the Android market or you cannot download it, please first look here for trouble-shooting tips, then contact customer support (info at x-plane dot com). Please do not use the comments section of this blog for customer support; if you need help we will need to contact you one-to-one.
As some have noticed on the org and on FaceBook, Randy mentioned that we may be able to ship X-Plane Mobile for Android. Some users were quite befuddled to learn that we were aiming to ship X-Plane Mobile for Android so soon when X-Plane 10 is delayed. Here’s the full story.
Chris, the third and most recent addition to the X-Plane programming team, began a port of X-Plane Mobile to Android a while ago; this was the second port of X-Plane Mobile after our port to Palm WebOS. He was able to accomplish most of the port fairly quickly; hence the video floating around the web of X-Plane on a Nexus One back in May.
Unfortunately we ran into some issues that stopped ship; it looks like Google may have them fixed shortly, hence our hope of finally shipping the app. So while Chris has spent a little bit of time recently working on the last few Android issues, our hope is to release a product that we already put development time into a while ago.
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.
