Polygons Part 5 - Orthophotos

I just finished an example scenery package that shows how to place orthophotos using .polygon files. Check out the scenery website (look under tutorials) to download the package and also read the illustrations. (This is an experiment: this is more of an annotated scenery example tha a true step-by-step tutorial.)

The basic anatomy of an orthophoto-in-a-polygon is:

1. A PNG file contains the orthophoto. (In the case of our example, ksbd_alpha.png.)
   
2. A .pol file references the PNG file and defines the physical properties and layering information. (In the case of our example, ksbd.pol.)
3. An overlay DSF references the .pol file. (In our case this is +34-118.dsf.)
4. The DSF overlay contains exactly one usage of the .pol file, with a polygon parameter of 65535 (a flag to indicate that texture coordinates are in the DSF) and each vertex of the polygon contains texture ST coordinates.

This pattern is actually the same design pattern that is used everywhere in the X-Plane scenery system:

• PNG files are never used directly by DSFs, they are always referenced by some kind of "definition" file, like an OBJ, .pol, .ter. Sometimes the definition file has a lot of info (like an OBJ, which contains a 3-d model), and sometimes they just contain some basic attributes (like a .ter or .pol file, which contain info for the physics engine).
  
• The artwork definitions are always separate from the DSF, so that they can be reused easily in a lot of DSFs.
• The DSF says where the polygon goes and the .pol file says what it looks like, just like the DSF says where an object goes and the OBJ says what it looks like.

One decision I made early on in my work on the scenery system was to stop using "magic file names". Prior to X-Plane 8, in a number of cases it was enough to add _LIT to the end of a texture file and a lighting mask would appear. In all modern file scenery format, there is a texture command (usually TEXTURE_LIT) to add this information.

Now this is probably more confusing to new users, and certainly a little bit confusing to anyone who was used to X-Plane 7. To some extent my goal is to have most scenery files be generated automatically - we're still a long way away from that, so my decisions to prefer extensibility to ease-of-use in the low level formats cause problemes for now. (But try the new AC3D X-Plane plugin version 3.0 - with UI to edit all X-Plane properties, does it matter anymore whether OBJ8 files are easy to read? We now have a real UI for editing X-Plane specific properties.)

In the case of file formats my concern was extensibility. There are only so many "tricks" that we can possibly cram into a file name, and the more we try to make the file name do, the less simple it becomes. When textures can only be "lit", tagging _LIT on the end is simple, and haivng to add TEXTURE_LIT can be annoying. But since then we've also added layering information and physics information. Imagine ksbd_LIT_AIRPORTS_-1_GRASS.png. Now we're getting into the domain of confusing file names.

Take a look here at some of the things we'd like to someday do for textures...seasonal textures would really make the texture names crazy. (MSFS9 accomplishes this using four seasons, which keeps the names simple...but what if we want to customize the time range for seasons?)
And dataref-controlled textures? Well, you can't encode a dataref in a file name - the / is reserved!

So all of these text files (.OBJ, .pol, .for, .ter, etc.) provide extensibility - they let us add new features to the way that DSF content is viewed without requiring cahnges to the DSF file format itself.

Since this blog post has gone off into a philosophical rant and the real info is in the tutorial, let me drift totally off subject by mentioning that while you're looking at tutorials, take a look at Kriss's tutorial on OBJ8 animation using the new AC3D plugin. If you've tried using the old system of animation (by typing cryptic goo into the AC3D object naes) you'll find the new plugin will let you work a lot faster!