Posts by Murmur

    Good day, a question for developers. Is the turbulence discretely modeled (i.e. as a 3d flow field, where for example the left wing could be in an updraft and the right wing in a downdraft), or is it simply modeled as a single "gust" event affecting all the parts of the aircraft at the same magnitude?

    In the Aerofly FS wiki, I see that the AeroWing class has an attribute for downwash (it's not well explained, actually).

    I assume this controls the amount of downwash an AeroWing receives from itself or from another AeroWing (e.g. the downwash produced by the main wing and acting on the horizontal stabilizer).

    My question is this: is the actual downwash of one wing on another calculated with or without lag due to the distance between the AeroWings?

    An example to better understand the issue: let's say the aircraft AoA impulsively goes from 2 degree to 4 degrees. Even if the main wing downwash doubles, it will take some finite time before the increased downwash travels downstream and "hits" the horizontal stabilizer.

    In the conventional stability-derivative-based flight models, this is accounted for using the so called "alpha-dot" derivatives.

    These alpha-dot derivatives affect the short period dynamics of the aircraft, and if not accounted for, produce a virtual aircraft that is more stable than it should be in reality.

    Does Aerofly FS accounts for this time lag of downwash? In case it does not, are you planning to add it in future?

    the downwash is computed for the next iteration. This is where the aspect ratio and the 3D wing as defined by the wing's sections comes in. For a low aspect ratio wing, we have a higher downwash and effectively a reduced lift slope for the 3D wing. The AspectRatioMultiplier is mainly used to tell the left wing that it is just one half of the total wing and vice versa.

    So, the key message is: the lift, drag and moment curves are defined for 2D airfoils, and the sim takes care of the lift slope reduction for finite wings automatically.

    Thank you for the detailed explanation IPACS Developer :) Just what I was looking for. I like how you designed the flight model.

    So, I assume the AspectRatioMultiplier is also used when calculating the downwash angle, otherwise only wings designed as a single Aerowing would have a correct lift slope. Thank you again for the explanation.

    From my experience I would say case 1) is true but I was also told that ClAlpha should stay at 2 pi... So there might be some effect of the actual geometry of the wing...


    Ok, I see in the wiki that 6.28 is the suggested value for airfoils Cl_alpha, and I also see there are some values related to the downwash for the aerowing class, so I assume it is calculated depending on the wing aspect ratio.

    In any case, should you get further details from developers, it would be nice to know them. :)

    How is the lift curve slope of the 3D wing calculated? In other words, which of the following 2 cases is actually used by the flight model?

    Case 1) the lift curves of the AirfoilRoot and AirfoilTip are directly used to compute the lift of the entire wing, with interpolation;


    Case 2) the actual wing aspect ratio (possibly corrected with the AspectRatioMultiplier) is used to compute a reduced lift curve slope (or, equivalently, a downwash angle);

    In other words, does the actual wing aspect ratio (+ AspectRatioMultiplier) only affects the induced drag, or does it also affects the lift curve slope of the wing?

    Good day,

    is the internal flight model applied to the original position of the relevant rigidbody (e.g. wing, stabilizer, etc.) or to the displaced position?

    For example, when the wing bends upside under g-load, are the lift/drag vectors applied to the original ("unbended") wing position, or to the actual bended wing?

    Ok, after experimenting, I can answer myself.

    The correct interpretation seems to be the one given by Jet-Pack.

    In other words, the three InertiaLength values are not the conventional radii of gyration, but they represent instead the length of the sides of a homogeneous box having the same inertia as the one of the RigidBody.

    So I assume the following equation is used internally for the inertia tensor?

    (Source: )

    Think you meant ( Z) yaw axis Murmur.

    Anyway, the tensor matrix should allow to infer the cross-moments, unless they're not being considered in the present aircraft modelled in AEFS2 ?

    If I increase the radius of gyration for the X (roll) axis, that should simply increase the inertia around the roll axis, without changing inertia around the other two axes (according to how Radii of Gyrations are used).

    But according to how I interpret what Jet-Pack wrote, increasing the inertia length for the X axis, it should increase the length of the "virtual" homogeneous box in the x direction, and hence it should not change the inertia for the roll axis, but it should change the inertia for the pitch and for the yaw axis.

    With regard to cross-moments, from what I understand the RigidBody class allows to specify the direction of the principal axes of inertia (with the B0 rotation matrix) and hence cross-moments are not required.

    Thanks for the clear answer, it confirms my assumption that the InertiaLength is sufficient to describe the inertial property of the RigidBody.

    BUT! There's something that doesn't seem right. You said:

    InertiaLength would be the size of a Box with homogeneous mass distribution in meters. The first parameter is the length along the X0 axis, second along Y0 and third along the Z0 axis. You can rotate the Body using the B0 matrix which consists of these axes.

    I interpret that in the meaning that in the RigidBody class, the inertial lengths (let's call them Lx, Ly, Lz) give the RigidBody the same moments of inertia that would have a solid homogeneous box with the same mass and with the sides of length Lx, Ly, Lz.

    But usually, the radii of gyrations are used in a different way, i.e. each of the three lengths, squared and multiplied for the body mass, give the moment of inertia _around_ that axis.

    So, which of the two interpretations is correct?

    An example to better understand: let's say I increase the value of Lx (the first element in the InertiaLength vector, corresponding to the roll axis if the body is not rotated).

    According to how I interpret what you wrote, that should correspond to a homogeneous box with a longer X side, and hence it should yield a bigger moment of inertia around Y (pitch) and Z (yaw) axes, but the same moment of inertia around the X (roll) axis.

    According to my interpretation instead (the conventional one), increasing Lx should correspond to just increasing Ixx (the moment of inertia around X (roll) axis), while Iyy and Izz (the moments of inertia around the Y (pitch) and Z (roll) axes) do not change.

    What is the correct interpretation?


    in the "RigidBody" class, there are 2 attributes with regard to rotational inertia.

    The first one is "InertiaLength", and that describes the radii of gyration that, when squared and multiplied for the body mass, give the values of the principal moments of inertia.

    The second one is called "Inertia", and is described as: "The strength of the inertia tensor as a 3 x 3 matrix".

    So my questions are:

    1) What is the use of "Inertia" attribute? As I understand it, the "Mass" and the "InertiaLength" attributes alone should be sufficient to describe the inertia tensor?

    2) In the Aerofly Wiki, the units of the "Inertia" attribute are given as "kg * m² / s". Shouldn't it be "kg * m²" instead?

    The P-38 doesn't Mach tuck and the Aermacchi behaves like an area ruled razor blade winged 1950s trans-sonic X plane. Does it really matter though?

    Well, if AeroflyFS wants to aim at the (let's call it) "complex flight simulator" market, implementing Mach effect is necessary to accurately model subsonic and supersonic aircrafts.

    Mach effects include multiple aspects:

    Parasite drag increase (Mach drag rise);
    Compressibility effects on indicated airspeed;
    Increase in lift slope;
    Aft shift in center of pressure (Mach tuck / trim changes);
    Decrease in max Cl (Mach buffet -> Coffin corner);
    In some cases, variation of flight controls effectiveness;

    Most of this are necessary to accurately model airliners or supersonic aircrafts, if they are to be considered "study aircrafts".

    Mach "physics" is something we will consider in the future. We already bugged our main physics developer to add support for this. Wouldn't it be great one day to fly with the Concord in Aerofly FS?

    That's great news! I hope it's high in the priority list. Of course, as I explained above, it's necessary not only for the accurate modeling of supersonic aircrafts, but also airliners. :)