Friday, July 23, 2010

Performance of Panel Texture vs. 3-d Cockpit

I sometimes get questions from authors considering how much to rely on a 2-d panel mapped to 3-d via the panel texture vs. a true 3-d panel. I can't comment on what will look best, but I can comment on the relative performance characteristics of both techniques, and the answer might surprise you: in some cases you'll get better performance by modeling directly in 3-d.

The 2-D Way

When you use the panel texture to make an object, X-Plane goes through a lot of steps to create the final result:
  1. Your panel has to be rendered in 2-d. We atlas your panel textures, but we don't necessarily order them optimally - we don't know the optimal order. Each generic instrument is at least one batch, perhaps even two. Those batches have very low vertex count, and the vertices are stored non-optimally on the CPU. There may be a fair number of texture changes between instruments.
  2. If you use ATTR_cockpit_region, we then go back and do the same thing...again! Why? Well, we need your panel's raw color ("albedo" to graphics nerds) and the emissive light given off by anything self-lit separately, so that we can do correct 3-d lighting.
  3. Both of these are rendered to an off-screen texture that the video driver will feeel obligated to preserve at all costs, putting pressure on VRAM.
  4. Only when all that is done do we begin drawing your object, with the usual batches to change to panel texture and change back, perform animations, etc.
If this seems expensive, that's because it is. Periodically users send me airplanes to look at their performance, and lately I've been seeing a lot more problems with 2-d panels (that fuel 3-d cockpits) being the performance bottleneck, not the 3-d modeling itself.

The 3-d Way

What if we want to go 3-d? Well, we're going to "eat" a lot more of what your 3-d pit already has:
  • You'll need a lot more animations to move all of those parts.
  • You'll need new batches with ATTR_lit_level to dial up and down various lighting levels.
But you do get some advantages:
  • Geometry in objects is processed about as optimally as we possibly can. All of that work we've done on the rendering engine to make OBJs fast is available in your cockpit. So you can increase 3-d detail 'for free'.
  • Your lit geometry can be drawn in a single pass (we don't need to prepare two separate lit textures). So for example a needle would take three batches via the panel-texture route (a batch to rotate the needle for albedo, a second batch to draw the rotated night needle, and a third batch to draw the resulting texture in 3-d) but only one if you use the OBJ directly.
  • Since you organize your textures for OBJs, you can guarantee that all of the cockpit stuff is together, saving texture thrash.
  • You can use normal maps to add per pixel detail to your cockpit; panel textured geometry cannot be normal mapped.
A Balancing Act

Given the high cost of panel texture relative to native OBJ drawing, you'd think going native OBJ would be a no-brainer, right? Well, not quite.

A needle is an easy case: you can model a needle using a rotation animation, so your implementation in an OBJ and our generic instrument are quite similar. Same with the throttle lever generic instrument.

But what about a "glass pie indicator"? What about a moving map? What about a rotary?

There are some generic instruments that have "movement" for which there is no equivalent OBJ technique. With these generics, the generic instrument/panel code may be able to render the generic quite a bit more directly than your OBJ can simulate the same effect.

This is my suggestion on a cut-off: if you can directly model a generic instrument with an OBJ (needles, throttles, and other "simple moving things"), consider 3-d. If you would have to use a lot of extra texture space, copies of your mesh, or a lot of show-hides, use the panel texture.

Your goal should not be to eliminate the use of panel texture. But if you can cut panel texture down to a single 1024 x 1024 region from a larger area, you'll probably see a performance win or a reduction in your airplane's system requirements.

Performance Test First

Final thought: before you invest months in a complex cockpit design, mock up the "work-load" X-Plane must do and performance test it! For an OBJ, simply make one moving instrument and duplicate the mesh to get the number of expected animations. For the panel, drag out a bunch of instruments, make custom textures and just paint junk into them with photoshop. The goal is to make X-Plane do the same amount of work as it will in the final version. Then fly your test panel on target computers and observe performance.

2 comments:

Jack Skieczius said...

Thank you for this.

I know i will be balancing things a lot in my Q400. There will be a 2048x2048 2d/3d panel texture region, but. hoping it was not a mistake, but i will surely find out.
dose it make a difference if your 2d panel is "very" simple. dose x-plane still think about the 2d panel when you are in the 3d cockpit?

I also noticed, while i am thinking about it. the base EFIS maps don't scale up properly. Or rather the small icons and lettering that show the various way-points and nav aids do not scale based on how large you make the texture as in other base instruments that come with x-plane.

thats all i got.
love the blog.

Guy said...

I wholeheartedly support what Ben recommends: during development of my own project (DH-106 Comet 4c) I started off using the Plane Maker panel for the cockpit instruments, then changed so that each instrument was modelled in 3D. Flags, pointers, needles, and even flashing annunciators became part of the object animation. In spite of a huge rise in polygons, I saw a net gain of +6.0 FPS.
Of course, I must still use the Plane Maker panel for the radar scope - aircraft with glass cockpits must rely on it even more - but for classic aircraft with analogue gauges, I find object modelled instruments look fantastic, and work much faster.

Guy.