3D for Flight Sim By Bruce Wilson

3D.

If you read the newsgroups on the Internet, or if you belong to a flight-sim mailing list, you’ve heard a lot of talk about 3D. Microsoft Flight Simulator ® 98, released late last year, now supports 3D acceleration. Other civilian flight sims, like Looking Glass Technology’s Flight Unlimited® II and Laminar Research’s X-Plane 4.0, also run with 3D acceleration, along with almost every military flight sim available. New video cards are showing up every day with claims of being the fastest or the best. And like any new technology, 3D has more than a few simmers scratching their heads over it all. What we want to do here is talk about what 3D is, and how you can best use it to enhance your flight sim experience.

What is 3D?

The world is 3-dimensional. Every point you see can be described as an x, y, z coordinate relative to some reference point. The designers of 3D software use this same system to describe their simulated world. Everything you see on screen is described in three dimensions. But because it’s only a computer, the programmers had to make some simplifications. The basic one is this: everything is made of triangles. They divide everything in their world into triangles defined by three x,y,z coordinates (one for each vertex) and a realistically-lit texture. The texture is an electronic picture (a bitmap) of how that triangle should look. For example if the triangle was part of a city, it would have a city texture, but if the triangle is part of the wing it will have a wing texture. A typical scene in 3D will have anywhere from 100 to 5000 triangles (or polygons) in it.

Rendering is the process of converting all the polygon definitions (three coordinates and a texture) into a picture, or image on screen. There are two rendering systems commonly used today, commonly known as 2D-mode and 3D-mode. 2D rendering has been around a long time. It is the only rendering mode used in FS95 and previous versions of flight sim. 2D rendering is performed in software, where the CPU converts the polygons to an image. This extra work slows the program down and sometimes limits the usable resolution of the program. This is called 2D mode because the data is sent to the video card in a 2D format (the x,y location of each pixel you see).

Enter hardware rendering. I suppose some clever group of engineers said one day, "what if we add a second chip to do the rendering? That way the CPU will be free to do faster flight calculations, and we’ll have a faster program." Whether they said it or not, that’s what they did. Hardware rendering has a second processor (a chipset) converting polygons to an image at the same time the CPU is calculating flight parameters, so the frame rate goes up. This is one advantage of 3D hardware. The other is an improved image at no expense to the frame rate. Visual effects like fog, colored lighting, see-through clouds and smooth shading can be rendered better in hardware without slowing the frame rate.

API’s. Unfortunately, more than one group of engineers thought of this, and they each came up with a different way of doing 3D rendering. These ways are called API’s, and there are currently three big API’s used in sims and games: Microsoft’s Direct3D, Silicon Graphics OpenGL, 3Dfx’s Glide. And it is equally unfortunate that no 3D hardware supports all the API’s used for sims and games, so there are some decisions to make if you want to buy a 3D card. To help you, There are two charts at the bottom of the 3D Card Summary (see link at left) that list the most popular flight sims and the API’s they use, and the most popular chipsets, and the API’s they support.

Here's an example. Say you want to do something simple, like draw a red box on a black background. To do it in 2D requires a very different way of writing the program than writing it in 3D. Programmers don't write visual code at the pixel level: they use API's to assist them. The API used for 2D is usually DirectDraw. The API used for 3D is usually Direct3D, Glide or OpenGL. Each of these uses a very different way of defining that red box, and they are all very different from doing it in 2D.

Now, there is a way to take a 2D program and make it use some 3D. It's typically called a 'kludge', because it's a brute force way of cramming the 3D routines in place of the 2D ones, and because there are some essential incompatibilites between them, it always comes out rather poorly. For example, in 2D you might define a box as "Three visible parallelograms, each such-and-such pixels long and so-and-so pixels wide, each meeting on two sides, oriented thusly (give coordinates of rotation), with the top colored bright red, and the sides colored dull red (it's lit from above)". This definition requires a lot of CPU time to calculate. Now you want to convert your program to do this in 3D. But the 3D API doesn't understand the way the box was defined, so you need to add an extra bit of code to convert the former definition to something like, "6 planes (here are the coordinates of all of them), each colored red, located at this point in space, and viewed form this other point in space, and lit by this color of light from above". The API then figures out what it will look like (size, rotation, lighting), and gets the 3D card to help with the calculations. These are very different definitions of that box. There are exceptions to this rule (like the Quake/GLQuake conversion, which had defined the limited world well enough in the 2D version that the 3D conversion was a success) but they are rare. So once you've kludged the code (which is frankly a lot easier that rewriting it), you're left with a less-than-idea setting for expansion. To add an effect you have to first figure out how the 2D did it, then what the kludge did, the force the new effect in without messing up any other kludge.

The benefits of a 3D rewrite over a patch: Now, if you start writing for 3D from the ground up, adding new 3D elements is fairly easy, because you are already talking a '3D language': You've got all your programming conforming to the API standards, so all the little things like how do you define a box is already done properly. And dropping new effects is in easy.

Conclusion.