This text was supplied by by Hans van Kampen <email@example.com>
"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 <firstname.lastname@example.org>
Textures are colorized graphical patterns (collected in a texture file) to fill outlines of shapes projected in the X-Plane world. They are the envelope or image appearing on various wireframes calculated by the XP graphics engine.
-the cockpit display;
-the quadrilateral fills in ENVironment-files;
-the airplanes fuselage, appendages and wings;
-fills of various type of obstacles and objects.
For our scenery we have to deal with the texture fills of quads in the ENV files.
+Handling of textures+
A common misunderstanding is, that textures require no calculation power and only seem to be easily plotted within wireframes. Various control attributes can be added to specific textures as to produce fogging, transparency etc., which must be detected and interpreted by the graphics card accessory or video processor within a computer. This requires calculation power often diverted to special electronic circuits able to quickly handle these data.
When however unwillingly control attributes are added to a texture, or a accidental sequences of colours and patterns produce such a code, the speed of the simulation may be influenced in a negative way.
F.e. in version 5.1 adding a colour with the RGB-saturation 255,0,255 (purple) to a shape will make it transparent, causing calculations to fill (or better to open) the hole. Also fog at the horizon is an application of colours having effects on various outside textures (well discuss this later).
X-Plane builds its objects from a multitude of coherent wireframes and accordingly requires much calculation power to fill all these parts! This process is rather efficiently handled, but some colour patterns may indeed cause difficulties.
X-Plane has adopted the 24 bit BMP format for its textures - a standard widely used in the Wintel PC world. This format is universal, but consumes much RAM space, limiting its application to several dozens of textures only. It is interesting to know that only 16 bit are used for colour processing.
X-Plane has adopted the power of 2 arythmatic for sizes of various texture files, i.e. some may be 16 by 16 pixels, others may be 512 by 256 etc. Opening a texture file in f.e. Adobes PhotoShop® may give information on the file size and dimensions in pixels, or picture elements (image points). Do mind that this has nothing to do with the resolution of the texture, which can be anything from 8 to 1024 pixels per inch... However see the connection between texture size and its resolution!
A major misunderstanding concerns the on-screen resolution of a texture!
X-Plane formerly appeared with scenery textures with a resolution of 100 pixels per inch, whereas the file size could be 128 by 128 pixels or even 256 x 256. Likewise well find some runway textures of 128 x 64 pixels at 600 pixels/inch!
One should realize, that the X-Plane on-screen world at most comprises 800 x 600 pixels, of which (in version 5.03 of XP) 800 x 333 pixels were assigned to the cockpit texture. Whatever happens - the XP visual world is projected as max. 800 x 600 pixels.
The nag of this story is, that common monitors have a resolution of 72 dpi, which means that the distance between any RGB phosphor triangle (mixing intensity to produce colours and by consequence shapes), the so-called pitch of the monitor, is leaving 72 dpi only under optimum electronic circumstances (100% white = 60 Cd/m2 = 60 NIT, giving about 960 pixels width at -20 dB at a 43 cm/17 monitor), or a pitch of about 0.34 mm! More resolution is not on-screen and can only be visualized by magnifying an image and cutting gain of the monitor (lowest possible contrast - are you a nightflyer?)...
It would go too far here to discuss bitrates, line-frequencies and other typical properties of the electronics and phospors of monitors, but the consequences are highly intriguing for our texture design.
Since textures are colour-fills of specific calculated wireframes it is far more important to adjust their size and shape to those dimensions, than creating yet invisible high resolutions that would go lost in stretching those textures to the limits as to fit a wireframe...
+Optimizing textures for on-screen projection+
Since an ENV-file consists of quadrilateral buildingblocks, which pretend to be roughly 1 km in dimension on a monitor producing 800x 600 pixels at 72 dpi (2.54 cm), we can derive the dimension of any power of 2 texture, that would optimum fill any quad...
Let me save you the mathmatics. A texture of 800 x 600 pixels at 800 dpi would perfectly do, but costs us 1.28 Mb of RAM, c.q. disk space. However this size is prohibited, since it is not a square but a rectangle and doesnt comply to the Power of 2 rule. The nearest neighbour would be 512 x 512 (768 kb) or 1024 x 1024 (3 Mb) instead.
Since we must use multiple scenery textures (in fact dozens of them) to fill water-grass, grass-mountain and water-mountain combinations and need several more generic textures and custom textures to produce special effects (airports, airplanes, cockpit, cities, snowclad peaks etc.) we should run out of memory in next than no time. When we go for the optimum situation we would need 32 or more Mb of RAM to accomodate all necessary BMP-textures.
Processing times of this immense volume of data would put XP to a grinding real-time halt forever...
Therefor we are bound to find a compromise: 256 by 256 pixels at 4 x 72 dpi= 288 dpi resolution (or 192kb, but still 2.26 cm, thus nearest to the optimum 72 dpi).
This now is interesting, because it utilizes a hidden feature of most graphics cards: rendering quality. As is known many graphics cards, but also XP itself offer various rendering qualities, such as normal, high, very high or extreme. It is evident, that the extreme mode implies maximum utilization and calculation of all individual pixels, whereas the normal mode shifts back to the normal screen resolution of ... 72 dpi. This thus means loss of information (=resolution) and therefor a somewhat blurred image, but high calculation speeds by skipping lots of pixels.
When we now assign 256 x 256 pixels image size at 288 dpi, we standard offer 4 x 72 dpi=288 dpi resolution to the texture at next to maximum monitor pitch and we do not need any other setting than the optimum for our computer, i.e. the fastest processing and best on-screen resolution! We now kill 2 mosquitos with one swap.
True, 256 pixels on a row and offering 288 pixels/inch means a slight blurring when seen close-up (288/256=1.125 stretch factor). Of no real significance when flying 1000 feet up! This can be compensated for by a good colour pattern!
For slower computers (<250 Mhz) the graphics card could be set to Normal, but the rendering in XP to High to get fastest running textures and optimum results. Changing to Very High or Extreme in this constellation wouldnt bring a single pixel more resolution, at most somewhat more crispness..., but of no significance compared to the loss of framerates (say: fluid running of the simulator, or speed with which the simulator produces on-screen images).
When some cards (f.e. Ati RagePro 8 Mb) are preset to High rendering (as well as XP) this causes the nasty blurring of distant objects and high rendering per half quad at near distances and nearest the airplane. The advantage is, that line jitter by lack of mipmapping in XP is minimized, the disadvantage however loss of detail in the distance. It may be possible that this nasty phenomenon is solved in future XP releases. Line jitter and moiré are a consequence of the way XP projects images when overall sharpness (resolution) is required. By blurring the distance in the double High setting X-Plane tries to hide this programming deficiency. Good scenery textures however can reduce these jitter effects.
In experiments it has been proven that a card set to Normal rendering and High Compression (!) still works well when X-Plane is set to High rendering. The framerate is hardly influenced by it, yet more textures can be loaded.
By any standard it seems that currently 256 x 256 pixel image size scenery textures at 288 pixels/inch resolution are optimum and should be a standard for the +ESP project+. For airport runways the 600 dpi resolution of some 128 x 256 textures is ridiculous - when set to 288 pixels/inch the results are equal and processing times become much faster. Gain of FPS is at least as important!