I’ve been meaning to write a post about the difference between general purpose flight simulators and AAA first person shooters for a while; a particular feature in X-Plane 10.04 brings some of these differences to light.
A typical high-end first person shooter is a closed game; the art content and the rendering engine ship together, and the art content is authored specifically for (or repurposed for) that particular rendering engine. The content is also completely available ahead of time; it can be authored without worrying about rendering engine changes or the addition of third party add-ons. Similarly if a rendering engine change requires revising all art content, this is at least possible, since all art assets live in house.
Compare this to a general purpose flight simulator. The rendering engine and art content may be revised on different schedules. The artists building third party content have limited access to the developers writing the rendering engine, and the rendering engine acts like more of a platform than a closed product.
Because X-Plane’s rendering engine is a platform, rather than part of a closed product, we try to keep optimization and performance work generic. When possible, we put in optimizations that act automatically without author participation. When we do have optimization advice, it tends to be generic advice that applies over a wide range of rendering engine revisions. (For example, using less OBJ ATTributes and atlasing many small textures into one big texture have been good advice for at least the last seven years.)
Sometimes, however, it becomes necessary to put in authoring features that are somewhat specific to the rendering engine and optimization. This is what has happened with cockpit pre-filling.
Before we go any further, you may want to read about pre-filling here. (One thing I am trying to do is to put the specific tutorials and documentation into permanent articles and not blog posts that are lost in the archives after a few months.) Basically when we pre-fill, we draw part of the airplane early on to mask out clouds, saving fill rate on the GPU, improving framerate.*
For the 2-d panel, we put in pre-fill in X-Plane; no artist intervention is needed. But for the 3-d cockpit, we can’t easily pre-fill without you setting some check-boxes on your airplanes.
The problem with the 3-d cockpit is that it is, in its entirety, rather expensive to draw. So we can’t just draw the entire 3-d airplane (for the purpose of masking clouds) or we’d be burning a possibly large amount of CPU to save a possibly large amount of fillrate. The right trade-off depends on the actual plane, and X-Plane can’t figure out automatically what the right thing to do is.
Hence the pre-fill check-box in X-Plane 10.04. With the pre-fill check box, you (the author) mark your content for optimization to hit the right balance of CPU and fill rate savings. (See the articles linked above for guidelines on how to set the flags sanely.)
Fortunately if the check boxes are set wrong, the worst thing you get is poor frame-rate (not crashing). But this is a rare case where third party authors can (and have to) input tuning data directly into X-Plane.
(And for concerned users: if an airplane doesn’t have the pre-fill check-boxes set up, the performance is the same as 10.03 – there’s no loss, this is just an opt-in optimization.)
* If you are asking at this point “why didn’t you guys do this years ago, you idiots?!?” the answer is: because it never mattered before. X-Plane 9 simply doesn’t use much fill rate, so it never made sense to spend CPU time to save fill rate.
You know, this is funny cause just last night i was thinking to myself this. “these clouds really are a pain to render, ya know with all that z-buffer stuff and such. I bet someone, perhaps Ben, will someday come up with a way to drastically improve frame rates.”
Funny cause today i read this.
I really like this new feature
Okay, something new to consider. If one has a panel with a lot of animations load before a cockpit shell, would it suffice to pre-fill the shell and not the panel even if part of the shell is behind the panel from the pilot’s viewpoint?
And what is it that cuts out 3D internal lights to my panel miscellaneous object in daytime? The lights work fine at night, but changing sim time until the sky lightens darkens the object unnaturally by cancelling the effect of said lights.
You can just pre-fill the shell regardless of draw order and Z order – as long as the shell blocks the clouds, you’re good to go!
3-d internal lights, not sure; please file a bug!
Rather off topic but I finally splashed out on the CRJ200 to go with my copy of XP10. It gives me the best frame rates I have achieved with XP10 and I can even use HDR basic at 30FPS in fairly complex areas or so now. Maybe because it is optimised for multicore systems? I have a phenom x6
Bad allocs, bad allocs! Pretty pretty please, need mooar raam!
How do I enable pre-filling?
That is covered in the articles linked to in the post!
Plane Maker – Miscellaneous Objects
Ok I have a question. Doesn’t also impact optimization that X-Plane “has” to be a multiplatform product? Laminar is a “macpeople” company and you also publish X-Plane for Linux. Honestly wouldn’t things be better (development and optimization wise) if you just embrased the most popular platform? Which sorry to say, is Windows and DirectX. VGA cards are for years now way more optimized to Direct3D than OpenGL (except maybe workstation cards). AFAIK (I am not a gfx expert). Also AFAIK DirectX current implementation is way more feature filled than latest OpenGL.
So, without making this a Win-Mac flame war, just asking an expert for educated opinion, wouldn’t what I suggest make things simpler and “better” for the end product? I don’t expect it will change (LR is USA based and you guys have Apple almost like religion – been there and seen it) and this discussion never goes well in the forum, but still I am asking for as much UNBIASED opinion as I can get.
It does not impact optimization; OpenGL and D3D are at feature parity right now. There was a while during GL 3.0 where the GL spec fell behind the hardware; the GL 4 roll-out (which matches DX11, roughly) has been a lot more aggressive, probably due to pushback from the community regarding the GL 3 lag. This is all moot for us; we aren’t on the bloody edge of feature use, so even with minor latency we wouldn’t see an impact.
I am not aware of any driver paths that are better in D3D than OpenGL; they both have hot paths and cold paths, and in the end you always end up batch limited on the CPU side.
Thanks for clearing this out.
Since you talk about CPU limits… why not use GPU partially for that role too? I mean it’s the trend now with CUDA, OpenCL and DirectCompute… Actually for our case only OpenCL (which is both VGA and OS “agnostic”). I don’t know if I am saying something stupid.
The GPU isn’t particularly well suited for some of the CPU-centric tasks that can limit X-Plane’s framerate; they have to be solved by changing how we use the GPU.
While portability in general is something that could hurt performances, in this particular context I think it is not really the case. Despite of different OSes, we are basically speaking about the same hardware (all of the mentioned systems – MacOS, Linux and Windows – run on the same x86 CPUs). If we wanted to have a software that is required to run on different hardware platforms things would obviously be different, in the sense that either the developer does NOT exploit hardware-specific optimizations to keep the code portable and gives up on performance front, or he/she duplicates the hardware-specific part of code for each targeted platform, at the expense of increased maintenance burden.
Concerning DirectX vs. OpenGL, this is a loooooong debate. All I can say is, while it is true that the recent GPUs are “crafted” around DirectX requirements, it is also true that feature wise OpenGL is not (any more) inferior to D3D, as Ben said.
All of this makes me think that supporting multiple platforms does not really hurt performances in X-Plane.
Best regards,
Filippo
There are a few things OpenGL does that the DX guys can’t get access to. For example, in OpenGL you can use immediate mode vertex attributes as a quick way to do batching. (On many systems, attribute changes don’t need to be validated and simply get pushed into the GPU’s registers; this is faster than a uniform update, which requires some validation, possibly a buffer operation and changing some or all of the uniform window. The trade-off is that you lose some register space to the GPU, which can hurt fps if done too much. But the option is useful.) I am sure there are some DX tricks that OpenGL cannot do. But in the end the very fastest code paths are available to both.
Can you very briefly comment on Single Instruction, Multiple Data CPU instruction sets. Any advantage with a newer CPU?
The only SIMD we use is SSE/SSE2 I think, which goes back a million years. SIMD isn’t going to be that useful to us because most SIMD-friendly code lives in libraries we use (e.g. OpenGL) and not in native sim code. Native sim code tends to be bottlenecked on L2 bandwidth and possibly branching.