How to structure the code?
Rewriting a complete FM code from scratch and plugging it in an existing simulation is something extremely hazardous. While the campaign code can be considered the brain of Falcon 4, the FM code is clearly the heart and modifying it could have disastrous impacts in many aspects: AI behavior, avionics, autopilot, bombing computations, etc.
It was also obvious that the new FM code would demand complete new data files. I had a pretty good idea at the very beginning how complex the data file could become and I was absolutely certain that all the existing aircraft FM data could not be redone following the new format.
It was also clear that the AI code would probably have many difficulties in handling a complete physics model so it was critical to keep the original FM code for the AI intact.
I think that trying to plug new lines in the existing code could have been a wrong choice, therefore I decided to start from a blank page and use a dedicated data file format. The idea at this stage was to develop a new FM code that can be completely autonomous from F4. Then the new code would be fed values coming from F4 (atmosphere, terrain, weapons, fuel, etc) and would export output values into the F4 code (world positions, speeds, angles, etc).
Choosing this avenue, I was able to make two different code modules coexist – the original MPS one (that I will call “OFM” for Old Flight Model) for aircraft that don’t have the new data file format, but also for every AI controlled aircraft; and the new one (that I will call “AFM” for Advanced Flight Model) for the human controlled aircraft having a dedicated new data file format. The final code is even able to switch from OFM to AFM and back when necessary without any discontinuity (for instance when a player switches to combat autopilot, the AI takes control with OFM).
What model to choose and why?
The original MPS developers chose to develop a code that was able to simulate the effects rather than the causes. This way of thinking is perfectly understandable for the F-16…why simulate the causes when we know in advance that the FLCS will do its best to keep the aircraft the way we want it? We just have to simulate the FLCS results to get it right then! While the idea would appear attractive at first glance, it ended up with a cinematic model and a pile of scripted code with the disastrous consequences we already talked about in Part 1.
My way of thinking was the complete opposite. Let’s simulate perfectly all the real causes and we should get all the real results. The idea was then to develop a complete force and torque model and to compute in real-time the 6 DOFs (degrees of freedom) equations of motion.
Basically, the AFM code is articulated around 6 modules:
- Mechanical
- Aerodynamics
- Input – Output
- Engine
- Ground
- Equations of Motions
1) The Mechanical Module
The mechanical module computes in real-time all the mechanical coefficients related to the aircraft. That means:
- Total weight of the aircraft,
- Evolution of the position of the Center of Gravity (CG) with fuel consumption and weapons,
- Evolution of the complete 3 x 3 inertia matrix with fuel and weapons,
- Force and torques coming from gravity
2) The Aerodynamics Module
This module computes in real-time and dynamically the resultant forces and torques coming from the action of the air flow on the structure (wings, elevators, rudders, canards, and fuselage). This module will be detailed in a later developer’s notes.
3) The Input – Output Module
It handles the link between the action of the pilot and the responses of the corresponding controlling surfaces. This module will be detailed in a later developer’s notes.
4) The Engine Module
It handles the forces and torques generated by the engine(s). A vectoring thrust module has been developed to be able to simulate VTOL and thrust vectoring aircraft.
5) The Ground Module
It deals with the forces and torques coming from interaction with the ground, i.e., gear or direct structure contact. This module will be detailed in a later developer’s notes.
6) The Equations of Motion
The equations of motion module is the heart of the system. The 6 equations of rigid body motion are completed with the 4 attitude quaternion equations and the 3 equations of CG world position.
The system of 13 differential equations coupled and non-linear are solved without any simplification in the body system by the Runge Kutta RK4 algorithm that can solve with an amazing precision the complete set of equations in 4 iterations only.
It takes as an input:
- World initial position
- Initial body velocities
- Initial body rates
- Initial body quaternion attitude
- Forces and torques coming from aero
- Forces and torques coming from ground
- Forces and torques coming from engine
- Mechanical coefficients (CG position, inertia matrix) coming from mechanical module
The outputs are:
- World position
- Body velocities and rates
- Body attitude angles
From those outputs are derived:
- Angle of Attack (AOA)
- Side Slip angle (BETA)
- Velocity vector attitude angles
- AOA and BETA rates
PROS & CONS
The advantages of this 100% physical modeling are obvious:
- The computation is extremely dynamic and does not suffer from any problem of computation in extreme situations. Stalls can be accurately simulated without any discontinuity between normal and stall conditions,
- External forces (like refueling booms, turbulences and wind) can be directly fed into the model with real forces,
- There is absolutely no discontinuity between ground and air, and the aero computation is acting even when the aircraft is on ground,
- Accurate forces modeling will result in accurate aircraft behavior
The main problems raised by a 100% physical modeling are:
- Complexity of the modeling for the forces and torques,Possible divergence of the algorithm resolution if time steps are too big (an adaptive RK4 scheme has been developed to solve that issue),
- The trajectory, rates, speeds cannot be altered directly (i.e., no hacks possible) as it can make diverge the physical model very quickly,
- Unexpected force discontinuity (terrain LOD changing with viewing when an aircraft is on ground for instance) can make the model diverge.
