EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

In a previous post I noted that we weren’t attempting dynamic ambient occlusion inside the 3-d cockpit, due to problems of quality, availability, and because it wasn’t really better than what authors do now: prepare the AO offline using a high quality render in their 3-d modeler.

I’ve been thinking about this a while: while I like to get up on my soap box and shout that X-Plane is not like a first person shooter any time we get compared to a AAA console title, there is one case where X-Plane kind of is like one: inside the user’s aircraft.

First person shooters often specialize in rendering highly controlled, closed, constrained, claustrophobic environments in ludicrous detail at very high framerate. To achieve this, they take advantage of optimizations specific to those closed, controlled environments: lots of things are pre-computed, pre-baked, and pre-calculated.

X-Plane’s scenery engine mostly focuses on throughput; once you climb through 500 feet you can see everything at an airport, so we just try to draw really fast. But the inside of the aircraft is different. Baking at least part of the interior lighting is pretty much a standard practice. We provide object-kill datarefs to let authors script their own culling algorithms to squeeze framerate out of a confined space.* We define sound spaces within the aircraft that can change how sound effects are filtered.** We let you mark which parts of your aircraft receive interior and exterior light. (This feature is called “light groups” in a regular 3-d game engine and it’s very common, particularly in older forward-rendering engines.)

All of this stuff is a lot more like a game with a 3-d level editor than the rest of X-Plane. Techniques that focus on interior spaces are a good fit inside an airliner.

Better Baking: one of the features planned for our next-generation modeling format is to allow multiple UV maps for a given model***. We can then add an ambient-occlusion texture to an object’s shader and you can bake your aircraft interiors at a much lower resolution than you albedo textures.

For example, you could use a high-res repeating texture to draw the seats inside the aircraft, copy-paste the seat down the cabin, and then unwrap a second UV map that covers the entire cabin uniquely.  Bake to this second UV map, down-size the texture to super low res (it’s ambient occlusion, “soft” is okay) and you’ll get high-res detail with unique correct lighting queues all over the aircraft. This is a standard work-flow for 3-d game engines and seems like a good fit for aircraft interior.

Edit in the Sim: we can take another clue from game engines and provide editing of graphical aircraft information inside X-Plane. We already do this for the particle system – the editor is built into the sim itself.**** The advantage of editing in the sim is that you can see your work exactly how it will look in real time.

 

* Engines that focus on interior spaces often have techniques like portal culling built-in and tools to precompute the information for this culling automatically.

** This is part of the new FMOD SDK – we will get this documented around or shortly after 11.0 goes final.

*** I realize this isn’t very “next-gen” in the world of rendering engines – it’s just the next major modeling revision for X-Plane.

**** The particle system isn’t documented because it isn’t quite finished yet. It’s shipping in mobile, enabled on desktop, but it is not running the default effects right now.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

21 comments on “Maybe X-Plane Is a First Person Shooter”

  2. Off topic since Ryzen can be pre-order now ! Will there be a advantage of having more multi-cores when you port XPX to Vulcan ?

    1. I don’t know – we ALREADY take advantage of multiple cores – our multi-core utilization may get better but it’s too soon to say whether the sweet spot of cores vs clock speed will shift.

      I can say Vulkan will give us more options to target multi-core with less overhead and restrictions. I can also say that right now we consider an i5 game machine to be sort of a “mental model” for a good high performance X-Plane machine. We don’t actively target 16-core machines, for example, because they’re not at a great place on the price-performance curve.

      1. With the upcoming market shakeup it’s better to start targetting many-thread CPUs. In my experience a major limiting factor is that X-plane still does a lot of drawing & object manipulation single threaded. My eternal pet peevee is that plugins are fundamentally single threaded, the plugin api has no synchronization capability and plugin calls happen in-line with the drawing thread, meaning any holdup in a plugin will cause drawing jitter.
        I know it’s not easy to rework the API, primarily because I see that there’s fairly little forced control what each plugin can do during a particular callback. For my part, I’d love to see more explicit sychronizarion being introduced into the API and more forced compartmentalization so things like flighloop callbacks could be moved out of the drawing thread and be all invoked in parallel (x-plane is an app, so all threads are preemptible and fairly cheap to meep around anyway).

        1. There’s no question that the single-threaded synchronous nature of the plugin system is a real problem. I’ll comment on this more in a future post, but note that we could, for example, collect our datarefs from the main thread serially while doing rendering work asynchronously – there is NO guarantee for plugins that the dataref callback is being made from INSIDE drawing code, and any plugins that try to take advantage of that are doing some really bad stuff. (We have some bridge code that transitions OpenGL for plugin use, and it is not used to make drawing work from dataref callbacks.)

          I looked briefly at actually decoupling drawing from the physics entirely and concluded that it wasn’t a great win, at least right now: there are still a lot of opportunities for parallelism even if we guarantee that the physics model is fully stepped before drawing takes place. If someday we capture all of that parallelism and we still have cores available for most of our users, we can revisit, but the overhead of going async on the FM is very high (in terms of both run-time costs and getting the code right), so it’s not worth it unless it’s going to be a real win.

      2. Do you plan on taking advantage of avx? Since x-plane probably deals a lot with vectors, maybe you can get a few extra percent performance increase this way. Almost every cpu you set as a minimum requirement for xpl11 should have at least avx support, and newer ones also have avx2

        1. It’s not a high priority. We use SSE2 (as a vector instruction set, not as a cheap replacement for x87) in a few places, but there actually aren’t a ton of places where it helps us. The GPU tends to take the cases where vector instructions could really win.

          1. Interesting, besides rendering the world, I actually thought that calculating the flight models and updating non-static world objects would consume the rest of xplane’s cpu usage.

  3. Great news, this will be perfect for X-Plane! Woow…
    Now next will not be bad a Human View Point – like module of view when user are out of aircraft if is not too much requesting.

    1. Also, Ben, regarding what you said about “Editing in the sim”. What would may work nice as a halfway point (and an alternative as well) would be provide a set of configurations of some of the mainly used tools for game assets today, such as Quixel Suite, Marmoset Toolbag etc.

      All of these have HDRI and other lightning, shader and post-FX configs which can be saved.

  5. Hi Ben. It would be really great to be able to do this for scenery objects as well. When I’m creating terminals or buildings where I want nice detail, I often unwrap the entire object uniquely so that no parts are repeated, enabling me to get a good AO bake. However lots of the albedo texture could be repeated in parts so I could get much better use of the texture space but still have the AO bake. It would be really cool to be able to apply a lower-res AO map with a separate UV map to the object.

    1. Multi-UV maps will be available for scenery – it’s an OBJ-based feature – when we rev the OBJ format (someday, when I have some free time) those features will be available to airplanes and scenery.

  6. Hello Ben, its off-topic… but i have some friends with the same issue that i have with the new public beta 12. The engines are not running at the default and 3rd party aircraft! Here the default cessna 172 not be able to turn on the start ignition when is cold and dark.

    Any idea whats is going on? or have any trick to fix it!
    Thanks a lot.

  8. As David Farragut said, “Damn the torpedoes – full speed ahead”.

    You guys are doing a phenomenal job. I really appreciate the ride as the PBs continue to flow.

    Thanks for all your work and devotion to our addiction.

    John

Comments are closed.