Category: Development

Why not GPGPU?

A commenter asked if we were planning to use a GPGPU API in X-Plane 10 or beyond.  I really can’t answer for the far future, but I can say that we aren’t planning to use GPGPU for X-Plane 10.  This post will explain a little bit about what GPGPU is and why we haven’t jumped on it yet.

Every new technology adoption has an adoption cost.  So the question of GPGPU isn’t just “will it help” but “is it better than the alternative uses of our time”.  For example, do we spend time coding GPGPU, or do we spend time optimizing the existing code to run faster on all hardware?  But this post is about GPGPU itself.

GPGPU stands for General Purpose programming on Graphics Processing Units – the Wiki article is a bit technical, but the short of it is: graphics cards have become more and more programmable, and they are highly powerful.  GPGPU technologies allow you to write programs that run on the GPU other than graphics.

There are two major APIs for writing GPGPU programs: OpenCL and CUDA.  OpenCL is designed to be an open standard and is heavily backed by Apple and ATI; CUDA is NVidia specific.  (At least, I don’t think you can can get CUDA to run on other GPUs.)  I believe that NVidia does support OpenCL with their hardware.  (There is a third compute option, DirectCompute, that is part of DX11, but that is moot for X-Plane because we don’t use Windows only technologies.

If that seemed confusing as hell, well, it is.  The key to understanding the alphabet soup is that there are API standards (which essentially define a language for how a program talks to hardware) and then there are actual pieces of hardware that make applications that use that language fast.  For drawing, there are two APIs (OpenGL and Direct3D) and there are GPUs from 2+ companies (ATI, NVidia, and those other companies whose GPUs we make fun of) that implement the APIs with their drivers.

The situation is the same for GPGPU as for graphics: there are two APIs (CUDA and OpenCL) and there is a bunch of hardware (from ATI and NVidia) that can run some of those APIs.*

So the question then is: why don’t we use a GPGPU API like OpenCL to speed up X-Plane’s physics model?  If we used OpenCL, then the physics model could run on the GPU instead of on the CPU.

There are two reasons why we don’t use OpenCL for the physics engine:

  1. OpenCL and CUDA programs aren’t like “normal” programs.  We can’t just pick up and move the flight model to OpenCL.  In fact, most of what goes on in the flight model is not code that OpenCL would be particularly good at running.
  2. For a GPGPU program to be fast, it has to be running on the GPU.  That’s where the win would be: moving work from the poor CPU to the nice fast GPU.  But…we’re already using the GPU – for drawing!

And this gets to the heart of the problem.  The vast majority of the cost of the flight model comes from interaction with the scenery – a data structure that isn’t particularly GPU-friendly at this point.  Those interactions are also not very expensive in the bigger picture of X-Plane, particularly when the AI aircraft are threaded.

The biggest chunk of CPU time is being spent drawing the scenery.  So to make X-Plane faster, what we really need to do is move the graphics from the CPU to the GPU – more time spent on the GPU on less time on the CPU for each frame of drawing we run through.

And the answer for why we don’t use OpenCL or CUDA for that should be obvious: we already have OpenGL!

So to summarize: CUDA and OpenCL let you run certain kinds of mathematically intense programs on the GPU instead of the CPU.  But X-Plane’s flight model isn’t that expensive for today’s computers.  X-Plane spends its time drawing, so we need to move more of the rendering engine to the GPU, and we can do that using OpenGL.

* Technically, your CPU can run OpenGL via software rendering.  The results look nice, but aren’t fast enough to run a program like X-Plane.  Similarly, OpenCL programs can be run on the CPU too.

Posted in Development by | 3 Comments

Real Physics on an Airplane

A while ago I wrote two posts trying to explain why we would use real physics for the AI planes.  Looking back over the comments, I think my message missed the mark for a number of readers.  The basic idea was this:

  • It’s quicker to get the new ATC system done by using the existing physics model than by inventing a brand new, parallel “fake physics” model for AI planes.  So using real physics lets us focus on other features.
  • The physics model is not more expensive than a fake physics model would; the few things that actually take CPU time on the real physics model are things the fake model must do: check for ground collisions, etc.

In other words, using real physics doesn’t hurt the schedule and it doesn’t hurt fps.  I followed that up with a bunch of talk about how you incrementally build a complex piece of software, and off we went.

What I didn’t do is make the argument for why real physics might be better than fake physics.  So: I made a video of the 777 taxiing and taking off.

Some disclaimers: this isn’t a marketing video, it’s what was on my machine at this instant.  This is an older v9 plane with v9 scenery*.  Version 10 is in development and has plenty of weird stuff going on, and the AI still needs a lot of tuning. Anyway:

With the video compression, calm conditions, v9 airplane, etc. it’s a bit tough to see what’s going on here, but I’ve seen a few AI takeoffs as I run X-Plane in development and it seems to me that the real physics model provides a nuance and depth to how the planes move that would be impossible to duplicate with a “fake” AI (e.g. move the plane forward by this much per frame).  When the airport isn’t flat, the plane sways depending on its landing gear, weight, and wheelbase.  The plane turns based on its rotational inertia, easing into the turn (and skidding if Austin dials in too much tiller).  When the plane accelerates, the rate of acceleration takes into account drag, engine performance, and wind.

 

* Except for Logan – that’s George Grimshaw’s excellent KBOS version 2 – version 3 is payware and I hope they’ll some day bring it to X-Plane.  Unfortunately there is some Z-thrash in the conversion.

Posted in Development by | 41 Comments

Hardware Buying Advice (or Lack Thereof)

If I could have a nickel for every time I get asked “should I buy X for X-Plane 10”, well, I’d at least have enough nickels to buy a new machine.  But what new machine would I buy?  What hardware will be important for X-Plane 10?

The short answer is: I don’t know, it’s too soon.  The reason it’s too soon is because we have a lot of the new technology for version 10 running, but there’s still a lot of optimization to be done.

As I have posted before, the weakest link in your rendering pipeline is what limits framerate.  But what appears to be the weakest link now in our in-development builds of X-Plane 10 might turn out not to be the weakest link once we optimize everything.  I don’t want to say “buy the fastest clocked CPU you can” if it turns out that, after optimization, CPU is not the bottleneck.

One thing is clear: X-Plane 10 will be different from X-Plane 9 in how it uses your hardware.  There has been a relatively straight line from X-Plane 6 to 7 to 8 of being bottlenecked on single-core CPU performance; GPU fill rate has stayed ahead of X-Plane pixel shaders (with the possible exception of massive multi-monitor displays on graphics cards that were never meant for this use).  X-Plane 10 introduces enough new technology (instancing, significantly more complex pixel shaders, deferred rendering) that I don’t think we can extrapolate.

To truly tune a system for X-Plane 10, I fear you may need to wait until users are running X-Plane 10 and reporting back results.  We don’t have the data yet.

I can make two baseline recommendations though, if you are putting together a new system and can’t wait:

  1. Make sure your video card is “DirectX 11 class”.  (This confuses everyone, because of course X-Plane uses OpenGL.  I am referring to its hardware capabilities.)  This means a Radeon HD 5000 or higher, or an NVidia GeForce 400 or higher.  DirectX 11 cards all do complete hardware instancing (something X-Plane 10 will use) and they have other features (like tessellation) that we hope to use in the future.  We’re far enough into DX11 that these cards can be obtained at reasonable prices.
  2. Get at least a quad-core CPU.  It won’t be a requirement, but we have been pushing to get more work onto more cores in X-Plane 10; I think we’ll start to see a utilization point where it’s worth it.  The extra cores will help you run with more autogen during flight, cut down load time, and allow you to run smoother AI aircraft with the new ATC system.

Finally, please don’t ask me what hardware you need to buy to set everything to maximum; I’ve tried to cover that here and here.

Posted in Development by | 28 Comments

Managed Expectations

I’m a bit behind on posting; I’ll try to post an update on scenery tools in the next few days.  In the meantime, another “you see the strangest things when debugging pixel shaders” post.

(My secret plan: to drive down expectations by posting shader bugs.  When you see X-Plane 10 without any wire-frames, giant cyan splotches, or three copies of the airplane, it’ll seem like a whole new sim even without the new features turned on!)

Posted in Development by | 5 Comments

What Do You Mean I’ve Had Too much to Drink?

More dubious screen-shots of in-development pixel shaders gone bad.  This one was taken while working on full-screen anti-aliasing for X-Plane’s deferred renderer.

Deferred renderers cannot use the normal hardware full screen accelerated anti-aliasing (FSAA) that you’re used to in X-Plane 9.  (This problem isn’t specific to X-Plane – most new first person shooter games now use deferred rendering, so presentations from game conferences are full of work-around tricks.)

It looks like we will have a few anti-aliasing options for when X-Plane is running with deferred rendering (which is what makes global lighting possible): a 4x super-sampled image (looks nice, hurts fps), a cheaper edge-detection algorithm, and possibly also FXAA.

Posted in Development by | 3 Comments

X-Farm: Because You’re All a Bunch of Animals

If there’s one thing I hear over and over from our users, it’s this:

Why are there so few farm animals in X-Plane?  The deer on the runway are my favorite feature in the whole sim!  Why aren’t there more animals in X-Plane?  Please add more!!!

Now first, I’m going to let slip a little secret, because I know you guys are desperate for tidbits on X-Plane 10.  The big feature in X-Plane 10 that is taking us so long to get right: moose! While the deer on the runway aren’t going to clock in at much more than 300 lbs, a fully loaded bull moose weighs about as much as a C152 at MTOW.  (At least, according to Wikipedia…I’m not convinced a C152 that weighs as much as a moose can get off the ground.)  Trust me, you don’t want to hit one of these things, even in a 747.

But that’s not the big news here.  The big news here is a new simulator product we’ll be releasing this fall: X-Farm.  X-Farm will be the first animal simulator to work entirely from first principles.  X-Farm will use shoulder-blade-element-theory to calculate the forces on each part of each animal’s skeletal structure to simulate what the animal would do in the real world.  Wanna put the head of an alpaca on a gorilla?  Go for it!  (Actually, that’s a terrible idea – Camelids spit.)  Think Rover would look cute with 6 legs and a stinger?  Our animal-modeling application Animal-Maker will let you fully customize your animals.

X-Farm will feature a completely rewritten Animal Traffic Control (ATC) module, with AI Animals that wander around the farm on their own, and herding dogs to chase after them.  (The initial version will feature only 20 animals at a time, but we’ll be able to scale this number up over time; the animal AI is fully multi-core for great performance on your new Core i7.)

It’s too soon for me to give specific hardware guidelines, but I’m thinking a DirectX 11-class video card will be best for X-Farm; we’re putting a ton of new shader features into the core engine to support fur on the animals and grass for the fields.  The facade system is greatly enhanced and can be used to build a variety of fences and paddocks to keep your animals where you want them.

Finally, I think we’ll eventually be able to get plugin support into X-Farm, so that you can customize the behavior of your animals and create custom animations.  Hopefully Wade and I will have time to port XSquawkBox to X-Farm (new name: XSquawk), so that you can create flocks of birds and let them loose in your favorite VATSIM ARTCC.  I hear ZBW loves that kind of thing.

*EDIT (By: Chris): I added some screenshots for all the impatient followers who just can’t wait another second to get some sneak previews of some farming. Obviously these are still rough drafts. I’m still working on getting the farmer to look as muscular and rugged as I really do. It’s close but not quite right just yet. Please do NOT ask for more screenshots. We have a pact here as developers that I’ll explain to you a bit since Ben already let the cat out of the bag about the product. Each time we get a request for more screenshots we do two things: 1) We drink from our glass of scotch 2) We go to our whiteboards and move the release date of the product out by one full week. We do this to be spiteful of course. We have so many products stocked up here just waiting for release but it’s more fun to watch the mania ensue. Coming Soon; Surgery Simulator “Demonstrate that steady hand as you remove the remote control that your dog swallowed from his upper intestinal tract”. We’re still working on the price of this one but let’s just say we’ll be doing a wallet-ectomy on you. Post Office Simulator “You get to live the life through Postal Employee Newman’s Eyes. ‘The mail never stops!’ Stack and sort bag after bag of mail trying to beat your best score.” and finally Department of Motor Vehicle simulator “Take a ticket and get back in line”. We’re hoping to release this one around fall of 2012 but that depends on how many screenshot requests we get. This one is very unique. You can play the worker at the counter handing out tickets. You also get to instruct people to get into the wrong line and then laugh at them as it takes them 45 mins to figure it out. There’s also a level where you have to put your “Next Agent Please” sign up as fast as you can. Beat your previous times. Play with your friends on multiplayer! Who gets to take their 4 hour break first?!

Posted in Development by | 31 Comments

V10 Release Date Mania

First, let me say that this post represents my opinions and my thoughts and does not reflect the official view of Laminar Research.

I’ll be the first to admit that the news and events that have “leaked” out regarding v10’s release date have created quite a bit of confusion, controversy and general discomfort amongst you guys; our fans/customers etc. I’m sorry to see the drama unfold in this manner. It’s certainly not intentional, it’s not a sign of v10 being delayed further and it’s certainly not a sign of v10 being canceled.

As i’ve said a dozen times already, v10 is very much alive and kicking. It consumes about 99% of all of our (the staff) time. It’s our #1 priority, it will remain our #1 priority and it has been for a long long time. There are many factors that contributed to the original delay of v10. I’m not going to go into internal details but I feel that it’s going to be a better product as a result. We’re not slacking off here. I don’t think there’s a single LR employee who’s put in anything less than a 40 hour work week in the past 3 years. I actually think the average is quite a bit higher and has been for some time.

One of the reasons for this tech blog is to give those of you interested an inside view into what it takes to write a flight simulator. It’s no simple task. In fact, in some ways it is rocket science!

I’m amazed by the amount of attention to detail that goes into XPlane’s development. Just as a quick example, I was  recently working on some ATC code and wanted to get a list of the runways at a given airport that had full ILS approaches. I was expecting there to be some kind of database lookup in the simulator that would say “oh runways 06 and 33 have full ILS approaches”. That’s a pretty basic assumption. “It’ll take 2 seconds to wire up” I thought….but that’s not how it works. There is no magical database for ILS approaches. XPlane doesn’t know about approaches directly, it knows about antenna types and location, OBS and glide slope angles. What I mean is, the database says “there’s a localizer antenna facing 036 degrees magnetic at lat/lon x/y and there’s a glide slope at x/y with a 3.5 degree angle.” This made my job a little more difficult because i needed to then compute the geometry of the localizer, glideslope and runways to determine what runway would benefit from a signal in that direction (don’t forget about parallel runways!). That kind of realism is unparalleled. What it means is that if a localizer antenna is offset at an airport because of obstructions (like runway 15R at Boston), XPlane will model the approach angle perfectly just like in the real world and you’ll come in at a slight offset. This is not new, the sim’s always been like this but it’s a new discovery for me. I guess my point is, sometimes even tasks that seem simple on the surface can be a bit more time consuming because we care about realism and the world is not a simple thing to model accurately…and that’s why this blog exists. We like to share with our users how COOL all of this stuff can be.

Getting back on track here, this blog gives you guys an inside look into our world so you have some insight into what kind of moving parts are in there. Our conscious decision to open this kind of dialog with our fan-base is a great thing, but it also can sometimes lead to miscommunications. Sometimes, we might say something in an innocent manner and you might take it out of context and misinterpret what we meant. For that, I’m sorry and we’ll take the blame.

With that said, I must ask and beg and plea that we all think twice before jumping to conclusions, trying to read between the lines and make inferences from quick unofficial statements made in a forum, a blog, facebook etc. Please do not assume that if a 3rd party vendor makes their own prediction of when v10 will ship, that it’s evidence of an official ship date. Please do not assume that if Austin himself says “by the end of the year” that he literally means “the end of the year.” If it shipped tomorrow, that would technically also qualify as “by the end of the year”. And NO, it’s not shipping tomorrow either. I can’t say that I blame people for wanting to hang on our every word and analyze our statements down to the verbiage but as much as I understand it, please try not to continue doing it. Official news, announcement of official features and official dates will be clearly marked as official. You will not need to read between any lines or make any assumptions.

So if v10’s not necessarily shipping in August and if “by the end of the year” does not necessarily mean “the end of the year”, then when is it shipping? The answer is….I don’t know! And that’s why there hasn’t been any official news yet. We’re not thinking about official dates yet because the date is arbitrary to most of us. When we’re all done with the core features and when it seems stable, then it will be released.

And because every post is better with a picture….Here’s a quick visualization of the math behind computing some ILS antenna intersections. The green line represents the localizer antenna beam. It starts in the background at the localizer antenna’s location and extends outward at the “OBS” heading of the antenna (note that in this unusual case, the localizer is NOT down the centerline of the runway!). The blue line starts at the glide slope antenna and extends outward at some angle above the earth’s surface. Typically this angle is about 3 degrees. The red line just represents the runway end. The point of this visualization is to see if you were perfectly aligned with the localizer AND the glideslope when you crossed the runway, where would you be? The intersection of these three planes is that pink dot.

Posted in Air Traffic Control, Development by | 41 Comments

X-Plane 9.68 Beta

From fearless leader:

X-Plane 9.68 is here (in Beta) for Mac, Windows, and Linux!
Just some TEENY little tweaks and enhancements to make v9.xx perfect:

  • new airport and NAVAID data
  • fix for lighting in non-generic instruments with esys (rare bug)
  • sound stays on when X-Plane is pushed to background on windows… as requested, and now in sync with Mac version for better consistency
  • improvement in the situation saving and loading

Just run your installer (from X-Plane.com) with the BETA options turned ON to get it
Have at it and let me know how it goes!
austin
ps: X-Plane 10 is much, much, much slower in coming along than I planned.. but it is much, much better as well. It is slow because I have raised the bar ridiculously high for this release, simply because I CAN. SO, I am keeping v9 totally bug-free while v10 is developed, which I am hoping to have ready by the end of this year.

I am hoping to have v10 ready quite a bit sooner than that.

Posted in Development by | 22 Comments

Commenting Fixed

Comments should work again – sorry about that.  The anti-spam captcha plugin had a directory permissions problem.  We need that anti-spam protection though – without it WordPress is a magnet for spam-bots.

Posted in Development by | 3 Comments

Taxiway Markings – What Data Looks Like

This is a view of the underlying vector data for the current KBOS taxiway layout.  It is floating above the ground because the data hasn’t been “draped” onto the layout yet.  There are two copies because the data has been debugged once for each DSF tile that the airport spans; when the actual paint is put down, only one copy of the lines will end up on either DSF, so we don’t have double triangles.

Posted in Development, Scenery by | Comments Off on Taxiway Markings – What Data Looks Like