This text was supplied by by Hans van Kampen <>

"Unofficial" texts are member contributions that have not yet been discussed or approved by the ESP community.

X-Plane Texture Definitions
... a different approach
by Hans van Kampen <>

2. Environment files
Without environment files (ENVs) the X-Plane simulator wouldn’t know where it is flying and which aerodynamical properties apply in a given situation. The ENVs are crude representations of DEM satellite maps offering ‘worlds’ of 1 x 1 degree (about 60 nm2 or 109 km2), each comprising a grid of 4660 different ‘elevation points’. Each ‘buildingblock’ of this grid (as can be viewed in World-Maker) has 4 moveable corners (each one is an elevation point) and is called a quadrilateral or ‘quad’.

As can be seen in World-Maker and viewed on the charts produced by XP some distortions are present, whereas the ENV-segments of the world are flattened to accomodate aeronautical objects and perform simple mathematical calculations as to ‘fly’ across the individual ENV-file. The XP world always comprises 9 adjacent flattened and glued ENV-files with the take-off airport at the center-ENV. To change from a flat world to a global world would require a next to new programme design.

The distortions accumulate from equator toward polar regions, making cross-polar flights next to impossible for the moment. The cartography of X-Plane is rather unconventional for calculation purposes.

Due to the position of the satellite with respect to the Earth’s surface some distortion (parallax) always occurs in Digital Elevation Maps. Aside from this the crude XP-world-interpretation only produces a quad with about 1.37 km x 1.85 km or about 0.75 nm x 1.01 nm resolution. Missing very fine surface details this way must be understood. It would require immense calculation power to further refine this resolution. In the future however faster computers will enable this. DEM imagery isn’t capable yet of producing geographically correct data - waterways and rivers, even lakes may be falsely interpreted. Low countries may be projected as being under water and not outlined at all... Here a special ‘coastline’ file provided with X-Plane and used in World-Maker can bring some relief. But this implies design work by the users.

The corner-points of each quad may be moved to follow geographical or topographical lines, f.e. rivers and mountain chains. Some quads may become highly distorted though and even undercutting their diagonals, causing or showing various optical problems later. An intelligent usage of this option is required and in many instances custom textures can be a relief, preventing unacceptable effects.

Any ENV file is ‘naked’ and comes usually without obstacles (buildings, towers etc.) and other objects (houses, bridges etc.). In the naked fashion most ENV files comprise about 80k of datapoints. The ENV-file may grow however to well over 90k when custom objects and custom landscape textures are incorporated. The file may grow so large, that a good glueing of the ‘world’ becomes impossible, leaving the user with misinterpretations (f.e. misplacements) and even unusable ENV-files.

A slowdown in World-Maker’s edit mode reveals upcoming or existing problems.

Particularly when buildings are edited from within World-Maker’s ‘Edit Obstacle’ menu option and misused to design villages and cities several problems may arise. Any obstacle requires some calculation power, gradually deteriorating the real-time performance. Here accordance with the AGA/MAP charts for obstacle placement is of utmost importance, reducing the file size and the workload.

This means, that different avenues have to be followed to accomodate the existence of cities and other non-vital surface markings: +custom textures+.

Keeping the ENV file size below 90 kb seems imperative still.

+Airports and Navaids+
Airports and NavAids are overlays across the ENV-files. Their positions are calculated from specific Apt.Dat and Nav.Dat files within the package, residing in a special, preferent, ‘additional nav data’-folder. Both files can be edited by the user with a regular wordprocessor. However there exists a conflict between the DEM data within the ENV-files and the Apt.Dat and Nav.Dat positioning data. It may occur that airports appear next to their geographical position. Both datasets (ENV and Apt/Nav.Dat) are derived in a different way, causing slight misinterpretations.

Normally a user will hardly discover this imprecision. However when a regular map (from an atlas!) is projected across a screenshot (!) of a World-Maker ‘edit screen’ and corrected for distortions (!) one will immediately see the error(s)! This is the only way to finally achieve optimum realism for XP. The option projecting regular maps across ENV-files for finetuning all data is absent though, aside from the fact that one will hardly find 1 x 1 degree maps in atlasses. Many rather gross errors go undetected this way.

Due to rounding errors within X-Plane it even may occur, that an airport may be viewed, but can’t be flown using its navigational aids, like localizer or ILS. In such case locking on an Instrument Landing System will cause the airplane to veer off into a false direction, incapable of locating the runway... This rare type of error can be predicted and viewed in World-Maker by looking at a suspect runway and comparing its given position with the Lat-Lon values when moving the mousepointer along the runway. The Apt.Dat position may not appear and thus the runway becomes skipped when flying its localizer (part of the ILS)!

The flat XP world and the slight distortion of the ENV files often cause imprecisions when positioning navaids. In XP’s Airport Charts imprecise localizer positions often can be found. Trial and error is the best solution for a correct placement of vital navaids. A Localizer mostly sits 0.5 km (about 1/4 nm) behind the runway centerline. The Glide Slope Transmitter sits next to its Touch Down Zone (TDZ).

It is imperative to adjust all XP parameter (Apt/Nav.Dat) to the correct +geographical positions+ as shown on the DEM interpretation of the ENVironment.
This means that in some instances an airport no longer is near the officially anounced global position. An example is EHSB Soesterberg AFB in The Netherlands, sitting some 6 nm from its geographical position, whereas EHEH Eindhoven couldn’t be flown due to the mentionned calculation rounding! Both parameter have been corrected in the latest versions of Apt.Dat, but no longer comply with the formal position in AIP’s (‘air information publications’).

The file size of the individual ENV file must be kept small and obstacles only set for vital positions according to the AIP - AGA/MAP sections.

Proceed to the next page