Basic optimisation

The time taken by X-Plane to update the screen obviously depends on the number of scenery object files (.obj) that it needs to display. A complicated scene can contain over a hundred scenery files, and many of these may be drawn multiple times. Therefore it is important that each individual scenery file is optimised for speed of rendering.

The time that it takes to render an individual scenery file primarily depends on the number of X-Plane primitives (lights, tris, quads etc) listed in the file. Normally, the number of X-Plane primitives that Blender produces in the .obj file is equal to the number of Faces plus the number of Lamps shown in Blender. You can tell how many Faces and Lamps are in the scenery that you're currently editing:

The numbers of Faces and Lamps in the selected objects are shown in the top menu bar - in this case 14 faces:

Menubar screenshot

The most obvious thing that you can do to reduce the nunber of faces in the scenery is to remove hidden or otherwise redundant faces. We've been doing this as we've been constructing the Virgin hangar - eg by removing the internal and downward-facing faces at the bottom of the "hangar" mesh.

The next obvious thing is to avoid setting a face as two-sided unless you really want it to be two-sided. (For instance, we haven't needed any two-sided faces in constructing the Virgin hangar). Two-sided faces are quicker to render than two single-sided faces, but slower to render than a single single-sided face. Plus, there's an overhead in switching between single and two-sided faces. When exporting, XPlane2Blender writes a message to the Console warning you about any two-sided faces that it finds.

It's easy to look out for these basic optimisations while you are constructing your scenery. But there are two important techniques that require more work; "Texture optimisation" and "Level Of Detail". We'll cover both of these in the rest of this chapter.

Texture optimisation

The theory

The texture bitmap files that you create for your scenery live in fast "video" memory on the graphics card. There's an overhead in loading the texture bitmap files into the video memory, but once the textures have been loaded then the graphics card can access them very quickly.

Unfortunately, the amount of video memory is limited; eg one 1024x1024 texture uses 4MB of video memory - some people are running X-Plane on computers with only 32MB of video memory, so one 1024x1024 texture at highest resolution uses 1/8th of it. Once you run out of video memory the graphics card has to fall back to accessing textures directly from the computer's main memory, and that really slows things down. Worse, X-Plane also expects to use video memory for storing terrain and aircraft textures, so once you run out of video memory then rendering terrain and aircraft will also really slow down.

We can therefore deduce two rules:

  1. Conserve video memory by using as small textures as possible - make every pixel count.
  2. Reduce loading overhead by collecting textures from nearby scenery objects into the same bitmap file.

The practice

Here's a house from X-Plane v7's autogenerated scenery, created by Sergio Santagada:

A house

It looks very detailed.

Here's the bitmap file (reduced to half size) that supplies the textures:

Autogen bitmap

We can see that Sergio is following the two rules:

  1. He's using a very small texture - every pixel in the texture adds detail.
  2. He's collected textures for nearby scenery into a single bitmap file.

In fact, Sergio has made another optimisation in this scenery. The two faces on the side of the house are mirror-images of each other. So he can re-use the same texture twice; mapping it in reverse on one of the faces. This doesn't directly speed up rendering, but it does help to keep down the size of the texture bitmap file. These are the textures that Sergio uses for the sides of the house that are visible in the above picture:

House texture

If you're interested you can examine how this house is modelled by importing it into Blender:

Re-open the VAhangar_open.blend file when you're done:

Level Of Detail

The theory

3D game designers have been making more and more complex and detailed 3D scenery over the last few years. Rendering lots of detailed scenery is very CPU, GPU and memory intensive and so takes a long time, especially on hardware that is not top-end. This slows down the frame rate and ruins the game experience. Techniques like making Strips help, but on their own they can't solve this problem.

However, game designers realised a few years ago that there's no point rendering detailed scenery when the viewer is far away from the scenery - all that detail is wasted because the viewer is too far away to see it properly. So rendering time can be greatly improved without sacrificing quality by substituting a less detailed version of the scenery when the viewer is far away. Game designers later generalised this technique and started to provide multiple versions of scenery, to be used at various distance ranges from the viewer. This technique is called "level of detail" (LOD). Automatic generation of reduced-LOD models is an active area of research and publication - eg Level of Detail for 3D Graphics, Action3D.

XPlane2Blender supports three fixed LOD distance ranges; 0-1000m, 1000-4000m and 4000-10,000m.

The practice

Here's what the Virgin hangar looks like in X-Plane at a distance of 1000m, 4000m and 10,000m:

1000ft  4000ft  10000ft

The Virgin hangar is quite a big building (big enough to hold an A340-600 or a B747-400) and we didn't model it in very much detail to start with, so we can still see all the detail at 1000m. By 4000m we can still see the general shape but we can't see any internal detail. By 10,000m the hangar is practically invisible.

So the only LOD reduction that we can usefully do with this scenery is to simplify the hangar at distances over 4000m. We can do this by getting rid of the internal walls, floor and ceiling. This probably isn't worth doing for such a simple object, but we'll do it just as an example.

In Blender, the LOD ranges are represented using "layers". XPlane2Blender will assume that you want to generate scenery with multiple LOD if it finds any Blender objects in layers 2 or 3:

Layer Distance
1 0 - 1000m
2 1000 - 4000m
3 4000 - 10,000m

We need the outside of the hangar to be the same all the way from 0-10,000m, so we need it to appear in all three layers:

A dialog pops up showing the layers on which this mesh appears:

Layer dialog
Layer dialog

We need the inside of the hangar to only be present at distances 0-4,000m, so we need it to only appear in layers 1 and 2:

Layer dialog

If you look in the 3D View window's menu bar there is another array of layer buttons. These show the layers that Blender is currently displaying (in this case layers 1 and 2):

Layer dialog
Layer dialog

You'll notice that the "Internal" mesh is not displayed (it's not even highlighted) because it's not present in this layer.

However, we can't just leave a big hole in the building - a hole would be visible even at 4000m. We need to add a face at the front of the hangar to close the building. We can re-use the texture from the rear face in the "Internal" mesh. In fact, instead of going to the bother of creating a new face, let's just copy the face from that mesh:

We want the rear face of the new mesh to be just behind the front of the hangar. We'll move it so it is 1m behind the front face:

Screenshot

We need to get rid of all of the faces except the rear face:

Screenshot
Erase menu

Blender deletes the selected vertices and associated faces, leaving only the unselected rear face. Now we just need to move the new mesh with the rear face to layer 3:

That's it. Here's what the Virgin hangar looks like in X-Plane at a distance of 4000m:

Non-LOD version Reduced-LOD version
4000ft 4000ft

If you look very closely you can just about see that the internal walls and floor are visible in the non-LOD version, and have been replaced by the flat rear face in the reduced-LOD version. We've managed to remove 4 faces in the reduced-LOD version, bringing the number of faces down from 14 to 10.

Go on to Placing scenery.