Flight Simulation Control Interface Harmonisation Tutorial
may think of this as a 'panel design tutorial', but I hope to demonstrate that
the whole idea of 'panel design' is one that should be set
aside. Harmonisation is the
process of writing the required scenery projection code which causes the
flight simulator to display the real flight path vector being achieved
by the user. It is virtually the same process as harmonising a parallax gunsight
in a real aeroplane. Harmonisation is the core of
the process which is sometimes wrongly called 'panel design' and which is in
reality flight simulation control interface design.
Some readers may think of this as a 'panel design tutorial', but I hope to demonstrate that the whole idea of 'panel design' is one that should be set aside. Harmonisation is the process of writing the required scenery projection code which causes the flight simulator to display the real flight path vector being achieved by the user. It is virtually the same process as harmonising a parallax gunsight in a real aeroplane.
Harmonisation is the core of the process which is sometimes wrongly called 'panel design' and which is in reality flight simulation control interface design.This tutorial explains and illustrates how to recognise broken flight simulation control interfaces and how to harmonise them to work properly. This tutorial applies equally to FS9 and FSX.
By agreement with Kazunori Ito, in conjunction with others, I am in the process of creating an enhanced realism package for his Macchi MC.200 Saetta, including realistic flight dynamics, prototypical gauges, and the necessary harmonisation of both simulation control interfaces. Screenshots of the user interface harmonisation process are provided here with full explanations. Kazunori Ito prohibits alteration of his MDLs, polygons, bitmaps and any other textures. Harmonising faulty flight simulation control interfaces does not require any such modification. In the MC200 project none of those components was deficient anyway. Screenshots are included throughout to illustrate the process of simulation control interface harmonisation.
Let’s begin with the simulation control interface known as a Cockpit View and often wrongly called a 2D panel. The 2D bitmap used as part of the Cockpit View (CV) in any project can be hand drawn or 'photoreal', but in the latter case the eyepoint and eyeline of the original camera lens are unlikely to match that of the real pilot. That false CV eyepoint and eyeline must be corrected to achieve flight simulation compatibility. This must be done in part via the following panel.cfg code content.
SIZE_X=8192 //always 8K = 8 * 1024 = 8192
SIZE_Y=5700 //ideally 6K = 6 * 1024 = 6144
MSFS assumes by default that we have a screen (or window) running in 8:6 aspect ratio. We select our actual screen aspect ratio via an FS menu and Microsoft code in the simulator product or in Windows should handle the conversion. The distortion of scenery perspective deliberately introduced above by using SIZE_Y < 6K < 6144 squashes 0.6 radians of vertically scrolling scenery in the rear window of the simulation into less than 6K pixels to correct the scenery projection versus the excessively low 2D bitmap eyepoint and eyeline within the 2D bitmap of the original MC200 cockpit photo. As we shall see later it is also the means by which we harmonise the Cockpit View (CV) with the Virtual Cockpit (VC) vertical Field of View (FoV).
Original project CV with eyepoint and eyeline chosen by a photographer long ago
Cockpit views often consist of a photograph over which bitmaps have been laid. A photorealistic picture of a panel taken from a camera at a random eyepoint, looking along a random eyeline, (in this case below the true pilot eyepoint and eyeline), does not deliver a fully functional Cockpit View, even after correction of scenery placement by deliberate distortion of scenery perspective using the code above. Before we have a functioning simulation control interface a 'views' section must also be created.
view_forward_dir = 9
The DIR may usually be allowed to default to zero yaw and roll correction. Yaw and roll corrections are rarely required and are probably best avoided, consequently
view_forward_dir = 9, 0 , 0
is admissible but the trailing zeroes are redundant
This variable projects the 0.6 radians of external scenery, (scrolling vertically in the rear window of the flight simulator and which in this case is perspective squashed into only 5700 pixels), correctly versus the panel bitmap, (static in the front window of the flight simulator), so that the elevation or declination of every object in the scenery is realistic. When we use a flight simulator we judge our flight path vector by comparing the position of the front window, (with the 'panel' painted on it), to the scenery scrolling in the rear window behind. From that parallax picture we judge our current flight path vector , (including any glidepath), to anywhere in the scenery. That parallax picture must be real not random.
True angle of elevation and declination from our eyepoint to the visible horizon, and to any scenery that we hope to reach or avoid, are vital in a flight simulator. They must never depend on where a photographer placed and pointed a camera lens long ago. The code, view_forward_dir= 9, corrects the scenery projection by replacing the eyeline down which the original camera lens was pointed during creation of the source image.
The [views] section and its vital view_forward_dir must never be omitted from an MSFS panel.cfg
CV in level flight at zero pitch before harmonisation (left) and after (right)
This tutorial is not a gauge compatibility tutorial, but note in passing that many CFS gauges are incompatible with FS9 and FSX. In this case the CFS default artificial horizon in the original panel.cfg (left) displays zero pitch as positive pitch and equal and opposite negative AoA. Gauges should never be selected because they ‘look nice’. They must be selected after beta testing that they actually work in the simulator that the project is said to be compatible with. The real situation is shown on the FS9 compatible artificial horizon on the right. Note that both pitch and VSI are zero.
The original flight simulation control interface (left) incorrectly displays the flight path vector as climb with the centre of the gunsight far above the horizon.
All of the MC200 screenshots in this tutorial are just swaps of panel.cfg with no change in the pitch (or anything else) being output by the constant flight dynamics which was zero pitch in level flight throughout. The left hand screen shot illustrates how a faulty simulation control interface projects the scenery with a false parallax relationship. We are misinformed by the simulation interface that the aeroplane is nose up when it is not. The aeroplane is in level flight and at zero pitch in both screen shots above. The original user simulation control interface has a significant pitch display error which must be corrected until the user interface correctly depicts what we have achieved via our inputs, which in this case is the goal of level flight at zero pitch.
‘Panel designers’ are required to project the flight simulator scenery correctly in both LAT/LON and relative pitch!
False flight path vector original (left) and real flight path vector after harmonisation
The ‘panel designer’ whose correct job title according to Microsoft is really 'Cockpit View designer' is responsible for coding the view from the cockpit, not just the view of the cockpit. It is his job to project all of the simulation scenery exactly where the gauges say the scenery should be, which is exactly where it is in real life. The gauges always use LAT/LON to point at scenery in azimuth and elevation (ADF only in azimuth, but ILS in both). In the example above we see that the FS9 compatible artificial horizon (right) is calculating correctly that the user has achieved zero pitch. The VSI shows that the user has also achieved level flight. Yet the original user simulation interface on the left projects (harmonises) the horizon randomly. Now notice that the significant pitch error in the original simulation control interface above not only confuses us concerning both aircraft pitch and aircraft flight path vector, but also prevents us from seeing where we are going! We cannot navigate by reference to the scenery even after achieving level flight at zero pitch. This design error must be corrected before that simulation control interface can be used in any flight simulator.
CV after harmonisation
The post harmonisation screen shot has prototypical gauges which also display the correct values, but they are not the point of this tutorial. The parallax error has been removed using VIEW_FORWARD_DIR. The simulation interface now indicates true pitch and true flight path vector to the user. Those values were always being poked into memory by the flight dynamics, but were being mangled by the broken simulation control interface. The sea level horizon is now just below centre of the gunsight in level flight at zero pitch. Visible curvature of the Earth is very slight from this altitude (550 metres).
VIEW_FORWARD_DIR also controls user vertical Field of View (FoV) in Virtual Cockpit view.
Original (left) has false eyepoint, parallax and pilot vertical FoV – all corrected in harmonised VC right
After correction of the VC vertical Field of View (FoV) all the key gauges needed to control aircraft energy state become visible by default. Any other gauges which may be required are 'one click down' at default hat switch key repeat rates. The default FoV within the VC is controlled by the same mandatory View_Forward_Dir command above that controls scenery projection in Cockpit View. Because that single Microsoft variable controls two different things in two different simulation control interfaces the two interfaces must be harmonised at the design stage so that they project identical pitch parallax cues when flying head up, yet at the same time render all the key gauges visible by default in the project VC. The project design must simultaneously deliver a dual head up and head down picture in the VC so that an approach, (or combat), can be flown without any scrolling to see either the touchdown point or the necessary gauges. The default VC view should be neither wholly head up, nor wholly head down. The interface designer must use SIZE_Y in combination with VIEW_FORWARD_DIR to deliver the required harmonisation of the two user control interfaces.
The default VC view must deliver the necessary head up and head down views simultaneously.
When the 2D bitmap is perfectly designed, (as it should be for new projects if you are the producer), it should be designed so that SIZE_Y = 6144 allowing the 0.6 radians of vertically scrolling scenery in the rear window of the simulation to be projected into 6K pixels with no perspective distortion. When we need to harmonise a broken flight simulation control interface we do not have that choice. We must determine the values of SIZE_Y and VIEW_FORWARD_DIR that deliver all the goals above by trail and error. That may require compromised and squashed scenery perspective as in this case; (SIZE_Y = 5700 needed v 6144 correct).
The approach must be flyable without resorting to video game cheat solutions to keep either the runway or the gauges in sight.
'Landing panels' and 'VFR panels' are never required.
That which is visible through the windscreen in real life, must be visible in our simulator and in both viewing modes.
VCs are not an excuse for denying users access to the head up view and the gauges simultaneously.
Flight simulators have scenery projection variables that must be encoded correctly until we see what the real pilot sees. He does not need to scroll and 'cheat' in real life and we should not be forced to scroll and 'cheat' when using flight simulators.
CV and VC harmonised for real eyeline and parallax, but eyepoint in VC further forward and more realistic. Vertical FoV in VC corrected.
The objective is not to place the horizon at the same position on the screen. The objective is to equalise the parallax between the front and rear windows.
How closely the horizon position on screen matches just depends on the contour differences of the two cockpit environments. The two simulation interfaces must be designed so that the user derives the same pitch cue from both environments. The pitch cue is a parallax cue. The two environments do not have identical cockpit contours imposed on the front window of the simulation. The scenery in the rear window of the simulation must be displayed by the panel.cfg author to deliver identical parallax in the rear window regardless. If anything the horizon might be positioned a little lower versus the glazing bars at zero pitch in the harmonised VC with greater discrepancy of horizon screen position between the CV and VC simulation control interfaces. The correct solution never relates to equality of screen location. The correct solution always relates to equality of parallax .
The types of gun sight which combat pilots look through, (there are other kinds in real life), are provided as precise parallax measuring devices. The guns are usually mounted parallel to the fuselage datum line in elevation. The bullets begin their flight parallel to that datum line and fall away with the ‘ballistic' trajectory caused by the gravity of planet Earth. The harmonisation point of the parallax gunsight intended to hit aerial targets at close range allows for very little bullet drop. To all intents and purposes it indicates the flight path vector when the aeroplane is in level flight and also at zero pitch.
If designing a user control interface for a combat simulator we would have no choice. We would be forced to equalise gunsight centre parallax precisely. When designing simulation control interfaces for a flight simulator we can and must take other parts of the airframe into consideration because the user of the simulation control interface will use the whole of the windscreen to frame the scenery and create the user parallax reference picture. That parallax picture is how the simulation interface conveys aircraft pitch. What it conveys must be real in both user interfaces. In other projects with greater variation of cockpit contour between the two viewing modes the position of the horizon on the monitor screen would need to differ much more to convey equality of parallax.
The screen shots in this tutorial all depict level flight with both zero pitch and zero bank which is the design time beta testing case. As users we also need to maintain level flight with bank applied whilst turning. We need to track the present or imagined parallax gunsight along the horizon whatever bank we apply. The simulation control interface must position the horizon correctly, not randomly else the user can never fly a head up level turn. Even when we intend to fly a climbing or descending turn we always need the cue for level flight to be real.
Unless the 2D bitmap is a screen grab of the VC from the VC eyepoint it will always be the least realistic simulation interface.
The 2D simulation interface is less realistic
Viewing the screen shots above we can see that (even after harmonisation) the 2D interface denies the simulation user the peripheral view of the ground ahead that the real pilot has in level flight at zero pitch, (or any pitch, including especially approach pitch, and tail down pitch on the ground). Flight simulation users need to see the scenery to navigate in 4D, not the interior of the aeroplane. This is particularly true of taildraggers during ground handling. The harmonised VC above allows the simulation user sufficient peripheral vision to follow taxiway and runway edges on the ground. Even when looking straight ahead the peripheral vision is adequate for ground handling, especially keeping the aircraft straight during take off and landing on a runway with a defined edge, whether grass, dirt, or tarmac. The 2D bitmap does not provide that necessary user control interface.
Some of you will have read that as a criticism of the original 2D bitmap. You misunderstood. I am explaining the inherent deficiency of 2D panels (Cockpit View). The scale of the CV bitmap could have been decided simply by taking the screen shot of the VC above. However Kazunori Ito did not have that choice. The CV had to be designed with sufficient vertical FoV to make the lowest and least used gauges of the real panel visible by default. This forced him to move the CV eyepoint aft until that required vertical FoV was on screen. This is not a design error, but preferring that false aft eyepoint is a user error.
Flight simulation is all about navigating aeroplanes in 4D. For some or all of the flight we must navigate by visual reference to the scenery. Even after the parallax error in the original CV has been harmonised the requirement to have greater vertical FoV in CV forces the CV designer to obscure more of the scenery.
The CV designer has no choice he must hog the screen obscuring scenery that should not be obscured and is not obscured in real life
The designers ‘screen grab’ of the VC to create the CV, (or just scale the CV bitmap), must be from an eyepoint further aft to deliver the extra FoV, in this case only extra vertical FoV, but in many other aircraft also extra lateral FoV. We can see that Kazunori Ito scaled the CV correctly. It has to be overscale. It has to block sight lines it should not block to deliver adequate vertical gauge FoV. However many 2D bitmaps are not produced to any scale at all. Many are wildly overscale and hog the screen at the expense of the scenery which we need to see to navigate in 4D.
The more scenery that is obscured, and the further aft the eyepoint is of the real eyepoint the less realistic the simulation. Flight simulation is about controlling parallax pictures. It is about aligning parts of the airframe with external moving or static scenery. The optimum choice if we want to understand what it was like to fly particular aeroplane x in real life is to use it with exactly the correct lines of sight blocked. In the combat case a fighter pilot often needs to ‘pull lead’ to have adequate angle off. It matters what ‘lead’ causes the target to disappear under the nose. As the harmonised MC200 VC discloses the real MC200 pilot can just see the tip of the nose from his real eyepoint. If the MC200 had a V-12 or a single row radial engine it would block more of the view. These things matter. The real eyepoint of the harmonised VC has more ‘scenery vertical FoV’ at the expense of ‘gauge vertical FoV’, but it is the VC with its realistic eyepoint that allows us to simulate MC200 operations realistically. That is true whether we are exploring difficulty of use in combat or the difficulty of flying the final approach. The penalty that we must pay for having the real world lines of sight from the VC is occasional one click hat switch snap scrolling to look at rarely used gauges below the default FoV of the VC.
The penalty for using many VCs is huge because nobody bothered to design the default vertical FoV!
Far too many aircraft are uploaded with VCs in which the default FoV is just a liability to the user. VCs with FoV errors are almost as broken as CVs with parallax errors. They are functionally useless. The whole point of the VC is to block only the sight lines that are blocked in the real aeroplane from the real eyepoint. That does not preclude the design of VCs with FoVs that form superior simulation control interfaces to CVs. The CV will usually compromise our ability to see the mobile or static scenery that we may need to keep in view, whether it is an air to air target in a fighter, or a touchdown point in a propliner. CVs usually obscure parts of the scenery they should not obscure to have adequate vertical and/or lateral gauge FoV. Correctly designed VCs do not impose that liability.
Using a CV in a propliner, (or most other aircraft), compromises our ability to navigate en route by visual reference to the scenery, or to fly instrument approaches to the real world minima. The touchdown point will disappear under the nose before it should because the bitmap must be overscale and must obscure scenery it should not obscure to deliver the necessary gauge FoV. In VC we see what the real crew see and we can fly to the same minima. We can navigate en route and down the approach in lower visibility when using VC.
Using a VC is more realistic because it is always correctly scaled.
The fact that it is 3D is not a benefit. That is the price we pay to enjoy realistic simulation. Because a 3D environment is a price not a benefit it is essential that the VC FoV be correctly designed to minimise the price we all have to pay to to have the possibility of navigating in reduced visibility, seeing scenery that is blocked by the overscale CV. As visibility reduces the horizon is lower and lower in the sky. As visibility reduces the horizon tracks down our monitor screen.
At some visibility the overscale CV blocks all of the scenery and the 2D simulation control interface precludes simulation.
The VC is always to scale and does not block scenery that is not blocked in real life. In most cases only 3D simulation control interfaces can be correctly displayed to real world scale. Only they allow simulation to proceed in low visibility. 2D bitmaps should never be a pixel bigger than they need to be. They are always a liability to the user. They must be scaled so that the liability is minimised and they work as semi realistic flight simulation control interfaces obscuring nothing in the rear window of the simulation they do not need to obscure. The MC200 2D bitmap was scaled correctly and with great care by Kazunori Ito to minimise its liability, but these days do 2D bitmaps for single or tandem seaters serve any useful purpose?
Believe it or not flight simulators are about navigating aeroplanes. We need to see where we are going. We need to identify landmarks and line features from level flight. We need to be able to follow line features, (always slightly to our left), without scrolling to see them. We need to do that for hours in the cruise, and then we need to be able to see the airfield on the approach, and runway and taxiway edges on the ground. That is what a flight simulation control interface must deliver. A 2D panel must be more than randomly scaled artwork covering the scenery by which we need to navigate. Real pilots need to see where the aeroplane is going and so do we. Real pilots move their eyepoint until they can. That is what simulation control interface designers are supposed to do too. If they don’t we must, or the simulation control interface is useless.
The panel.cfg author must deliver the correct scenery location in the windscreen of both viewing modes simultaneously.
Projecting scenery correctly is not an optional extra when designing components for a flight simulator. The scenery projection code must be calculated and supplied by the author of the panel.cfg. He is responsible for harmonising what scenery appears where in the world outside in both viewing modes even if he is not the author of the VC. Panel design is potentially a minor part of Cockpit View design.
The ‘panel maker’ is the provider of both user simulation control interfaces. He is required to harmonise the visible content of the rear window in CV and user FoV in VC.
He is the member of the flight simulation community responsible for projecting all of the scenery at its real LAT/LON and at its real ‘angle off’. The majority of ‘panel makers’ are still unable to grasp this.
Original CV and VC before harmonisation with huge variation of eyepoint and parallax. Both parallax cues are false.
Neither the bullets nor the flight path vector are going where these original simulation interfaces pretend. In each case the aeroplane is in level flight and also at zero pitch. The bullets will not go into the sky and they won’t impact the rear of the cowling where the VC gunsight indicates they are aiming either. Just because we use a flight simulator rather than a combat flight simulator does not mean that we have no interest in where our flight path vector is going. The purpose of both of these simulation control interfaces is to show us where our flight path vector is going as a result of our skillful user inputs. For some reason flight simulation users worry endlessly about tiny errors in flight dynamics but fail to notice that the simulation control interfaces they use are causing huge errors that are not in the flight dynamics!
In level flight at zero pitch our flight path vector and the bullets are really going here
Remember I am using these two fighter cockpit environments to illustrate a tutorial aimed at propliner users for three reasons.
1. They have no scaling errors and no graphics errors.
2. A project with 'gunsights' helps us to grasp the concept of 'harmonisation' of two views from two different eyepoints.
3. The different contours of the two front window interfaces demonstrates why the design requirement is to 'harmonise' scenery projection within those different front window contours in the two viewing modes. The front window of the 2D and 3D user simulation interfaces will often have different cockpit contours. The scenery in the window behind must be projected so that each contour in each interactive simulation interface delivers the same 'pitch parallax cue' from either interactive simulation interface.
Most aircraft releases have errors of software encoded
eyepoint, parallax and FoV which anyone can fix.
Most aircraft releases have errors of software encoded eyepoint, parallax and FoV which anyone can fix.The fix can never be micro radian perfect. The view of the simulated world from the two different interactive user simulation interfaces must be 'harmonised' until the user will 'react' or 'not react' in exactly the same way to the pitch cue provided regardless of the interactive simulation control interface in use. Without a gunsight most MSFS users and even most 'panel designers' simply fail to notice how broken the simulation control interface they are using / designing actually is.
The sea level infinite visibility horizon must be just below our zero pitch eyeline from our eyepoint (default view, no hat switch invoked up or down). The horizon will always be just below (real or imagined) mid gunsight in level flight at zero pitch. That is how we identify zero pitch in a flight simulator, because that is how we identify zero pitch in a real aeroplane. We identify any other pitch by noticing it is not zero, but first the pitch cue for zero must be correct! It must be correct in both interactive user simulation interfaces. At zero pitch the sea level horizon will be just below our default zero pitch eyeline, (through any parallax gunsight, present or imagined), due to curvature of the Earth. The higher we fly the more the earth horizon drops away from our zero pitch eyeline, in real life or in MSFS. Consequently scenery projection code must always be tested at zero pitch and low altitude by reference to the horizon over the sea.
Every VC must deliver a default view that allows both head up and head down flight without user scrolling and without user cheats
The simulation control interface must provide the necessary FoV whilst delivering true parallax
Someone has to 'bother' to design this. It doesn't just happen! The someone who is supposed to bother is the author of the panel.cfg. However if the creator of an entire aircraft project has no intention of ever flying the aircraft, from the inside looking out, because he just likes making model aeroplanes and only uses MSFS as a radio control model aeroplane simulator, then someone else has to bother, and most of the time that will have to be the downloader. Many / most 'panels' which claim flight simulation compatibility deliver nothing of the kind for want of a few lines of code. Remember during the enhanced realism harmonisation process depicted here I did not alter one pixel of Kazunori Ito's bitmaps or VC. They were not broken. I just bothered to calculate and write two lines of very simple panel code correctly and I bothered to correct the eyepoint in the original aircraft.cfg so that it now reads;
eyepoint=0.75, 0, 2.85
Bothering to calculate and write SIZE_Y=5700, view_forward_dir=9, and eyepoint= 0.75, 0, 2.85 is the difference between creating two flight simulation control interfaces that allow users to simulate the operation of an MC200, or bewildering them with random and different parallax cues which fail as user simulation control interfaces from either and both viewing modes, because they deliver false and differing flight path vector cues. There are other mathematical combinations of these three scenery projection variables that also project the scenery correctly and deliver the required vertical FoV in the VC, (because real pilots have different body sizes). What is required is that someone bothers to calculate and provide just one of those valid scenery projection solutions in every panel.cfg!
I cannot emphasise too strongly the extent to which users of flight simulators worry too much about realistic flight dynamics whilst flying with wholly random scenery placement and pitch parallax cues which are giving them false flight path vector cues. That makes no sense at all.
The MSFS scenery projection code, (just three variables), is much easier to calculate than realistic flight dynamics code.
Yet in many uploads it is just randomised. There is endless babble in many forums about ‘fixing’ flight dynamics by users who cannot notice huge errors in the simulation interface they are using to judge the flight dynamics!
There is no point in craving or creating realistic flight dynamics code for use with any aeroplane that has no functional simulation control interface capable of projecting the scenery correctly.
Nobody needs realistic flight dynamics that pitch the aeroplane correctly to zero degrees, in response to a given set of skillful user inputs, if that user does not care whether the visual horizon is then displayed at minus 5 degrees or plus 5 degrees when they use those skills and realistic dynamics to pitch the aeroplane to zero degrees.
It matters whether the next ridge line is 5 degrees up or 5 degrees down when we are in level flight at zero pitch towards it!
It matters whether the glideslope to a runway is displayed as three degrees or eight! Displaying one as the other is not acceptable in any flight simulator. Simulation control interfaces which display false flight path vectors (including glidepaths) must be harmonised before use. We need the real pitch parallax cue to display the real flight path vector being output by realistic flight dynamics! There is much more to realistic flight simulation than realistic flight dynamics. We need realistic simulation control interfaces. We all need to be able to recognise how broken most of them are else we will not understand the need to harmonise them ourselves, or discard them.
The user simulation control interface must show where the scenery really is whether we intend to strafe it, bomb it or land on it!
Remember it is the scenery that is being misprojected in all those screenshots. The 2D panel or 3D cockpit interior which are the front window of the simulation never move a single pixel around the screen.It is the scenery projection in the rear window of the simulation that the panel.cfg author is required to calculate and encode correctly, but that many never bother to encode at all! The angle down to that scenery (declination = glidepath = flight path vector) must be real. When the flight dynamics output a pitch of zero degrees our eyeline must be just above the low altitude sea level horizon else all the other glidepaths and climb slopes are wrong by the same amount. A real or imagined gunsight must have its centre just above the sea level horizon, whether or not the simulator is a combat simulator, whether we are using any CV or any VC.
When the flight dynamics output a pitch of minus three degrees on final approach our eyeline must be just above the touchdown point, not pointing at some random location in scenery that was projected randomly by the panel.cfg producer.
When we use a flight simulator we need to know where the aeroplane is going as a result of our inputs! Simulation interfaces that show it diving or climbing when it is in level flight at zero pitch are worse than useless. Users start developing stupid habits of aircraft operation or start tinkering with unbroken flight dynamics to correct huge simulation interface errors. Broken simulator control interfaces cannot be harmonised by flying with pitch errors or messing with flight dynamics. They must be corrected where the error was perpetrated by the designer of the simulation control interface. Cockpit environment design is all about projecting the simulation scenery correctly in the rear window of the simulation! That is why Microsoft call it a Cockpit View not a 'panel'.
After harmonisation of both simulation control interfaces the displayed flight path vectors match and more to the point they are real.
When an aircraft has no gunsight we must imagine one. In every 2D panel our eyeline must be encoded to pass through the centre of the real or imaginary parallax gunsight which is always directly in front of our eyepoint. Our eyeline must be parallel to the fuselage (zero pitch) datum line. When the aeroplane is in level flight at zero pitch the sea level horizon must be just below that eyeline (due to curvature of the Earth).
Before we can use an aeroplane in a flight simulator we need a properly harmonised flight simulation interface.
That is created first by the correct mathematical harmonisation of SIZE_Y and VIEW_DIR in the CV. The VC eyepoint variable is then harmonised with their mathematical product to deliver the same result in VC. Making them the same is not enough. They must both be real! The aeroplane must be going where the flight simulation control interface depicts it as going.
Study the supplied screen shots below until you understand that the original MC200 VC eyepoint and eyeline are both false (too high) and that the horizon is in an impossible position versus the gunsight to depict level flight at zero pitch flight vector from the correct eyepoint. The pitch cue is correct, but from the wrong eyepoint.
Study the harmonised VC jpg to notice that the eyepoint is now realistic (behind the real or imagined parallax gunsight) and that the horizon parallax picture is real for zero pitch level flight at low altitude. Notice that the user vertical FoV has been corrected to create a functional flight simulation control interface which displays the real parallax picture AND all of the gauges needed to control energy state simultaneously. That is what any simulation control interface must deliver to the user by default.
The original VC has false eyepoint, false eyeline and functionally useless FoV preventing control of energy state
The eyepoint variable and the VIEW_FORWARD_DIR variable in combination must deliver the necessary vertical Field of View that the real pilot adjusts his head and eyeline to achieve by default. The real pilot positions his head so he can see both where he (the aircraft flight path vector) is going and the gauges he needs to control aircraft energy state, whether in combat, or decelerating to Vref on approach.
Pilots need both the 'parallax reference picture' and simultaneous ability to see the energy state gauges.
One of those results is not enough. It is the job of the simulation control interface creator to deliver an eyepoint value and a VIEW_FORWARD_DIR value whose mathematical product deliver what the real pilot sees without requiring flight simulation users to employ silly video game cheats in either viewing mode.
Virtual Cockpits must deliver the necessary vertical pilot Field of View else they are just a nuisance to the user.
Remember in any project which has a CV we do not have freedom to vary VIEW_FORWARD_DIR at all. It must be encoded to deliver the true parallax picture which displays the flight path vector correctly in CV. The VC design goals above must be achieved by manipulation of eyepoint alone after determining the VIEW_FORWARD_DIR that creates true parallax and real scenery placement in the rear window of the simulation with CV in use. Errors in original camera lens eyepoint and eyeline of a photoreal bitmap, or a badly drafted 2D bitmap, may require SIZE_Y < 6144, but that should be avoided if possible. Simulation control interface design always begins with SIZE_Y = 6144 and we only compromise that value later and if absolutely necessary to achieve the stated design goals.
Savoia Marchetti S.M.79 VC with true eyepoint, eyeline, vertical FoV and parallax at zero pitch
Now study the screen shot of the Savoia S.M.79 VC above, originally by the 'Italian Wings' team for CFS3, and subsequently adapted for use in MSFS, mostly by Manuele Villa. Although it is a medium bomber P1 really had that gunsight. Notice that the project eyepoint is correctly harmonised with the project VIEW_FORWARD_DIR, and the project's realistic flight dynamics. When the user skillfully achieves zero pitch in level flight he can see that he has achieved his goal using the gunsight. Parallax is harder to judge without a parallax sight, but the flight path vector displayed to the user would be (and must be) real anyway. Notice that when aeroplanes are in level flight and also at zero pitch those who fly them can see where they are going! That is in fact the point of flight simulation. Flight simulation is the skill of compliant aircraft navigation in 4D in all weathers. No one can acquire or retain that real world skill using flight simulation control interfaces with randomly projected scenery!
Using broken flight simulation control interfaces may constitute a flight safety hazard for real aircrew.
The parallax picture must be as realistic as the flight dynamics. The flight simulation files must be properly harmonised. No video game cheats should be required to see where the flight path vector is taking the aeroplane, whilst simultaneously having access to all the required energy state gauges.
The energy state gauges include AH, ASI and VSI as well as MAP and RPM.
The S.M.79 screenshot shows pretty much the real panel layout in the real cockpit space, from the real eyepoint. There is no 'cheating' by the producers and they imposed no requirement for silly video game cheating by the downloader. The eyepoint is just far enough aft to include the slip ball within the vertical default FoV. When zero VSI is mandated no scrolling is required to cross check the head up picture with the head down picture. If you focus your eyes on the horizon the gauges will be out of focus, but just like real life they are just a pilot eye movement below. Please practice doing that now.
That change of eye focus does not require a head movement in real life and it does not require scrolling in FS9.
Always provided somebody bothered to design the user simulation control interface properly.
Things that would be out of focus in real life without a head movement are not visible by default. They are one hat switch click down or right. Those who prefer not to (snap) pan and (snap) scroll can use the icons bottom left to pop up things that are not in view by default. When designing or fixing the VC FoV we must consider the difference between eye movement and head movement. However we must always remember that the further back in aviation history we go the worse the ergonomic design of the real cockpit environment is likely to have been. Replicating the difficult working environement in many real historic cockpits is not always a design error. It is however always a choice. Gauge positions can be swapped. or moved a little, or gauge diameters can be reduced, to deliver an easier to use simulation control interface with adequate FoV. Like everything else in this tutorial that requires nothing more than Windows Notepad to (re)design.
Study real pilot eyeline
through the real gunsight position
Study real pilot eyeline through the real gunsight position
Now study where the real parallax gunsight is in the real S.M.79 windscreen versus the top of the real panel. That position is real world; not a position faked by the producers to deliver the goals specified in this tutorial. Now use that screen shot to inform your understanding of where the virtual gunsight, (the real pilot eyeline), is in real life in a real 'propliner' or other large side by side seat aircraft when the crew sit in a cockpit near the nose of the aeroplane. Notice that pilots who sit 'up front' can see more of the scenery than fighter pilots who sit at CoG to minimise ear canal disturbance. In a 'propliner' with no engine in the nose all of the scenery above the panel would be visible in level flight at zero pitch. Navigation by visual reference to the scenery is possible down to very low visibility minima when aircrew sit 'up front'.
The key is to notice where the (real) eyeline is in the vertical depth of displayed windscreen in front of the (real) eyepoint.
Notice the realistic peripheral vision which allows P1 to follow a taxiway edge or runway edge even whilst looking straight ahead. Having the real peripheral vision makes it easy for us to follow line features and height keep in low visibility too. The freeware Savoia Marchetti S.M.79 can be downloaded from the usual websites should you wish to examine how easy it is to operate a large aircraft from a correctly designed VC, in which you can see the gauges you need to see head down, and the parallax picture you need to fly head up simultaneously. It is even easy to just slide from the P1 to P2 seats without losing situational awareness in a correctly designed FS9 VC. Both should work equally well. The Macchi M.C.200 enhanced realism update was still a work in progress at the time this tutorial was published. It will be available for study at a later date.
Most 'panel makers' and 'VC creators' have no adequate aviation background. We cannot expect them to understand what they are supposed to be doing, or to explain what they are supposed to be doing to one another. The whole idea that they are supposed to be creating the flight simulation control interface and that they are required to project the scenery at its real LAT/LON, and with the real glidepath is wholly lost on most of them.
Perhaps if all the moderators of 'panel design forums' renamed them 'simulation control interface design forums' those involved in creating them might understand their role in the flight simulation community better?
Many aircraft releases and many 'stand alone' panel releases continue to contain no functional user simulation control interface. The vital parallax relationship between the front window of the simulation and the rear window is all too often false and randomly false in the Cockpit View. It tells us that our flight path vector is one thing when it something quite different. Many VCs continue to be produced with a random FoV from a random eyepoint making them no more than a nuisance to use.
The role of simulation interface designers is identical whether the simulation control interface they are designing is for a combat simulator or a flight simulator. Their role is to deliver true parallax between any front window (panel contours) that they design and the scenery in the rear window whose content they are also required to design . Their role is to carefully position and reveal the scenery for navigation !
Study this text and screenshots until you understand how to recognise broken simulation control interfaces and how to harmonise them. The best way to learn is to practice manipulation of the three allowable MS variables that every cockpit designer must use to place the simulation scenery correctly. Remember many flight simulation interfaces are so badly designed that they may have no [Views] section at all. You may need to create one.
Before all those broken simulation interfaces can be used for flight simulation we must harmonise them, else we must discard them.
1) In every 2D panel our eyeline must be encoded to pass through the middle of the real or imagined gunsight in front of our eyepoint. Our eyeline must be parallel to the fuselage (zero pitch) datum line. When the aeroplane is in level flight and also at zero pitch the sea level horizon must be just below that eyeline (due to curvature of the Earth).
2) The VC eyepoint must then be encoded to deliver the identical parallax reference picture when user eyepoint is switched, (with the simulation paused and by cycling the S key), displaying identical flight path vectors to everything in the scenery. That can also be achieved simply by using the same 'gunsight v sea level horizon harmonisation technique', whether or not the real aircraft actually has a parallax gunsight.
3) Default vertical FoV in VC is also controlled via VIEW_FORWARD_DIR. This must first be used to create the real parallax picture in CV above. However different combinations of SIZE_Y and VIEW_FORWARD_DIR can all deliver the real parallax in CV. The one needed from the many possible is the one that delivers the required vertical FoV in VC at the highest possible value of SIZE_Y (not exceeding 6K = 6144 pixels) which is parallax compliant in CV. Always attempt to create CVs which are functional with SIZE_Y=6144 before imposing a lower value that distorts scenery perspective.
All these problems can be greatly minimised by the creation of VC only releases and those who need to harmonise and create a functional FoV for a broken VC will find that much easier if they are willing to discard the CV. Once an aircraft has no CV the VIEW_FORWARD_DIR variable is not used by FS9.exe in the scenery projection parallax equation and may be used solely to create the necessary VC vertical FoV. This can easily reduce the effort required to create a functional user simulation control interface by 90%. When a CV is correctly designed it is hardly less useful than a correctly designed VC, but it adds a huge burden to the simulation interface design workload. Always consider whether you need a CV before you do the work to create one or harmonise one that is broken.
All of the above is true for both FS9 and FSX.
See addendum at bottom if you use a wide screen monitor.
Panel.cfgs for use in FS9 must be free from random ZOOM statements.
Random ZOOM statements inserted into FS9 causes false scenery placement that cannot be corrected by any means. The Microsoft FS9.exe code must be allowed to impose the correct value in every direction.
Flying with a false ZOOM to misplace the scenery at false LAT/LON is the silliest mistake any flight simulation user can make.
The 2008 Propliner Tutorial explains why (see below). The design goals above cannot be met by imposing false scenery placement with false ZOOM values to cover up bad simulation interface design.
Imposing fake zoom factors just compounds the simulation interface design error by adding false LAT/LON to false parallax cues.
FSX has additional and serious design errors by default. FSX is different with regard to ZOOM. Consequently FSX has its own scenery harmonisation tutorial by Tom Gibson which is linked from the same page as this tutorial.
FSX requires ALL the corrections above and ALL the additional corrections in the FSX simulation interface tutorial by Tom Gibson.
The design errors in FSX are explained and illustrated in greater detail within Part 2A and Part 7 of the 2008 Propliner Tutorial also available from ;
Hosting of all three tutorials is limited to that location so that they can be supported in the relevant flight simulation forum;
Stop reading now. Go and practice identifying broken simulation interfaces by flying or slewing cockpit environments to zero degrees pitch at low altitude over the sea.
Did the creator deliver real parallax to deliver the real flight path vector in both viewing modes?
Did the creator deliver realistic FOV in the VC?
If not practice manipulating the three allowable scenery projection variables, (VIEW_FORWARD_DIR + SIZE_Y + eyepoint), but never ZOOM to deliver real parallax, then refine that skill to allow the required vertical FoV in VC mode without invoking false parallax and false scenery placement in either viewing mode. Remember false parallax is the same thing as displaying false flight path vectors and a simulation control interface which displays false flight path vectors is worse than useless however pretty it may be.
FSAviator 4/2008 Addendum Re: widescreen monitors by Tom Gibson
Addendum Re: widescreen monitors by Tom Gibson
The tutorial above was written for older "square" monitors (4:3 proportion), or if you use a wider monitor you fly FS in a window and make that window the same 4:3 proportion.
If you use a widescreen monitor and instead the outside view stretches all the way across the monitor, to maintain the same outside view you will need to change the zoom value.
As an example, I use a 1920 x 1080 monitor. This has a 1920/1080 = 1.778 proportion, compared to a square screen's 4/3 = 1.333 proportion. Since FS changes the apparent zoom as you widen the outside view, we have to compensate by changing the zoom value the opposite way. The proper amount to change the zoom is the ratio of the "normal" square screen proportion to your monitor's proportion. For me this means 1.333 / 1.778, or 0.75. Since the proper zoom value using a square screen in FS9 is always 1.0, I now need to use a zoom value of 0.75 so my widescreen monitor displays the same apparent zoom as the square monitor did.
If your monitor has a different screen proportion, just substitute those values into what I did above and get your own zoom values. For example, "16:10" screens need a zoom value of 0.85 in FS2004.
In FSX you can eliminate this problem by using a cfg file setting. Please see the FSX Propliner Tutorial for details.