Previously I blogged about the difference between integrated first person shooters (FPS) and flight simulators, and how these differences mean that FPS tend to adopt new graphics technology significantly ahead of flight simulators. One of the major differences is that a FPS often will have its content packaged with the rendering engine in a single, unified product, while a general purpose flight simulator is expected to cope with third party content.
The need to be a platform for external content doesn’t just impact our ability to optimize for “special cases” (e.g. we can’t assume anything about third party); it also puts more pressure on the rendering engine to be robust in the case of error.
X-Plane has low level and high level scenery abstractions.
- Low level: an OBJ is low level. You give us a textured mesh, and we draw it. We don’t process the mesh, we don’t interpret it, we just draw what you made in Blender, AC3D, etc.
- High level: a forest. You tell us the outline of the forest’s area and give us some trees and we fill in the forest, picking trees and placing them.
Now there is always the risk that third party content can look stupid. If you model an airplane and you use 4 quads for each engine, your airplane is going to look bad, and there’s nothing the rendering engine can do to fix that.
But with higher level abstractions, the problem is more subtle. If the input data to a high level abstraction has a problem, X-Plane’s rendering might look bad. But what constitutes a problem?
In the case of forests, if the polygonal area of a forest is too thin (along certain axes) we will fail to put any trees into the polygon. Exactly what represents too thin isn’t particularly well documented or even easy to measure. This is difficult for third parties, because they don’t have an explicit set of guidelines for “you will make the rendering engine grumpy if you do X.”
This is the kind of thing that, in an integrated FPS, is much easier to cope with. The art team tries a technique, and if it looks bad, they email the rendering engine coder. The coders then either fix the rendering engine or tell the artist “don’t do that”.
In our case, we need to be more robust in the case of input data problems because we can’t tell everyone who tries X-Plane “don’t do that”, particularly when the edge cases may change with rendering engine improvements. So whereas a rendering engine feature in an integrated FPS might be useful if it looks good when used in a few usage cases , a rendering engine feature in X-Plane is only useful when it looks good under most usage cases.
The give us rules to work within that can't be broken. You change the rules when you need to.