Fine Print: Water on the Bottom Please

Here's one of those little details that probably isn't in the scenery docs but needs to be: if you are making base DSF meshes and they use water (the special terrain type "water") it must be on the bottom of the stack of terrains - it can't be used as an overlay!

Read More

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!

Read More

Polygons Part 4 - Anatomy of a .pol file

Before I do this, an important disclaimer: we want you to use the .pol files that are found in the default scenery using the library system, not to copy the files! I encourage you to look inside the X-Plane resources folder to see how the system works, but don't copy a file if you can use it via the library; the library system saves loading time and VRAM.*

With that in mind, here's a line-by-line of what we might find in a .pol file. This one came from my X-System folder in Resources/default scenery/820 world terrain/pol/apt_desert_hot.pol. We have:

A
850
DRAPED_POLYGON

This is a standard header for a .pol file, which defines the look of a draped polygon.

TEXTURE ../textures/apt/apt_desert.png

This defines what texture the polygon will be drawn with. In this case, we are using our apt_desert.png file, found elsewhere in our package. (The double periods, .. move us up to a higher level directory. This is legal within a single scenery package.)

SCALE 500 500

This defines how large the texture appears in the X-Plane world. In this case, the horizontal span of the entire texture (before it repeats) is 500 meters (the first number), and the vertical span is also 500 meters.

NO_ALPHA

This tells X-Plane to ignore the alpha channel on the PNG file. Often PNG files used for base textures have alpha channels consisting of noise, for the purpose of creating terrain transitions. Since seeing this alpha isn't desirable in an overlay polygon, this command can be used to strip out the alpha. This lets us use one PNG file for two purposes.

SURFACE dirt

This defines the physical surface properties of the polygon. In this case, it is "dirt", which for X-Plane means some dust puffs will come off the wheels and your plane will clonk around. See the OBJ8 specification for a list of all possible surface types. (These names match the ATTR_hard command in X-Plane 8 objects.)

LAYER_GROUP airports -1

This defines where in the drawing stack to draw. In this case, we will draw one layer under airports (-1 means under, +1 would mean over). This means that this surface will be seen right below all aspects of the airport, but above regular terrain, which is what we want. The names here correspond to the same names you'd find in an OBJ8 in ATTR_layer_group - see the OBJ8 spec for the complete list of names.

* Basically any time there are two PNG files on disk, the VRAM is allocated twice, but any time one PNG file is referenced multiple times, the VRAM is shared. Since the library system lets you share other packages' resources, using it almost always means a savings in VRAM.

Read More