The Future of Facades

Sergio and I were discussing the future of facades today. Facades are DSF polygons that are extruded into buildings by pushing up the polygon into a roof and texturing the roof and walls from a single texture using some simple formulas. The rules for facades are very simple - we originally thought them up for the purpose of creating buildings that precisely fit a city grid no matter what the block spacing.

The problem with facades is that the rules make very simple buildings - especially the roofs. So we want more powerful facades and the question becomes: how best to do this? There are two possibilities and I mention them here because they underscore what I think is the largest overarching design decision when creating a flight simulator scenery system.

1. We could make the facade builder in X-Plane smarter (write new rules).
2. We could write a stand-alone tool that converts the DSF polygons (plus a rule file) into OBJs that are then placed directly into the overlay.

This second strategy would turn the facade from a type of scenery element into a tool for making OBJs. We would be "pre-compiling" our facades.

Here are some of the considerations:

SPACE VS SPEED

Precompiling primitives is a space-vs-speed trade-off. For any given algorithm, it's usually faster to pre-build the entities and load them from disk than to build them in the sim. But pre-building means more files on disk, meaning bigger downloads, more DVDs, etc. Building up buildings from facades inside X-Plane is actually a form of compression.

EASE OF DEVELOPMENT

This is one criteria where I think pre-compiling scenery is a clear win: it's easier to build a stand-alone facade-to-OBJ converter than to implement it inside X-Plane. X-Plane is a relatively unfriendly place to build scenery algorithms because it's busy being a flight sim.

STABILITY VS UPGRADABILITY

If we make OBJs out of facades using a tool, the objects will look the same even if we create a new version of the tool. This is good in that it means that custom scenery won't change how it looks, but it is also a limitation because improvements to facade technology require rebuilding a lot of objects to take effect.

(Another aspect of this: if the objects made from the tool use a texture, that texture can't have its shape changed even if we make new rules, because some objects will be on users machines that were built with the old rules.)

X-Plane mostly errs on the side of pre-building scenery, and this is the one area where we really take it on the chin for that decision: the inability to easily create a new composite look from changes to some parts of the scenery. (Airports that don't cause grass to appear under them is an example of this.)

Perhaps some good questions for weighing these options are:

1. Would an author care whether the facade looks exactly the same in the future?
2. Are there enhancements coming along in this technological area that we would not want to miss out on for older scenery?

OTHER CONSIDERATIONS

Information loss: when we turn a facade into an object, the original polygon information is lost. Is it important that we ship the actual base polygons that make up buildings, or are the OBJs that represent them good enough?

Contextual Information: often we know more about a given situation when making scenery than when displaying it. Could we do better at building up a facade inside the sim (where we have context from other scenery packages), or when creating the sim (where we have a much larger dataset)?