More Physics, More Real Winds

my god you’re hopeless. I’m done here.

4 Likes

And now I’m lazy, and hopeless? Thanks, I guess.

1 Like

You might want to read the SDK docs about flight models to get some info about this? Maybe you have already I don’t know, but once you’ve done it, I’d suggest you play back multiple times the part where they start talking about flight models, and then Martial’s comments about icing. I might be mistaken, but he is clearly saying they might need to (something like) “reduce the values in their tables”. Of course I know this is about icing and they most likely are using multi-dimensional LUT to interpolate icing values. But knowing how FSX is made, where they come from, how the SDK is built and what it is delivering, let alone the config files greatly inspired from FSX, there is no doubt to me their “new” flight modeling is a mix of FSX area equations, FSX like tables, Augmented LUT interpolation based on “1000 elements” implementation (don’t fetch 1 but blend a mix of N values yet each one comes from a table in any case), and FSX like fine-tuning scalars.

The difference with XP11 is that it simulates air flow and air mass around surfaces mostly (only?). You can watch Austin’s videos explaining prop wash and similar concepts only attainable with flow simulation if you want to make it “credible” and “realistic enough”.

The 1000 element model they are using in FS2020 is in nothing similar to the blade element model in XP11. The latter is about air flow per element, and in my opinion the former is about increasing LUT probe sampling only.

Please note: I’m not saying one is better than the other, just they are different with different expectations, and I’m just speculating to what the 1000 element model really is.

3 Likes

I’ve always thought that the X-Plane flight model feels like balancing a spinning plate on a chopstick. Perfect for simulating a helicopter (maybe?) but not a C172.

The X-Plane flight model has never felt right to me.

(Got my PPL in 1978 by the way…)

5 Likes

That’s what I remember watching as well, that they took an existing model, and improved upon it. Increasing its “resolution” for want of a better term.

1 Like

Do you mean typically like this?

Note the perfect sinusoidal oscillations.

For the rest of it:
[BUG/FEATURE] FS2020 is breaking the VR golden rule: don’t move the camera, the user is

Sooo…
What would you suggest? Phasers or Disruptors?

Speculation firing arguments. Until someone official stands up and details the math behind the flight models. We are all guessing. Is it really worth all the testosterone fighting over whose guess is right? Does it matter? The proof will be in the actual flight characteristics at the end of the day. LM has had years to tweak their model and the ONLY aircraft that fly even remotely like a real airplane are created by third parties. We don’t have any fully modelled aircraft available for this 6 month old sim to even compare.
Can we maybe try discussing the provable aspects of the models we have and what physics are currently missing? This speculative shouting match is getting old.

1 Like

Sort of.

Watch the base C172 in X-Plane negotiate turbulent air. The datum point (not certain if I’m using the term datum correctly) is in the center of the airframe, while the rest of the aircraft “wobbles” around that center point.

MSFS does the same thing to some extent.

Again… all I’m really after is a reasonable simulation of aircraft behavior, and to make that simulation stable.

That’s what’s missing in MSFS at the moment, though the “pretty pictures” are certainly nice.

1 Like

Hear, hear. Agreed.

1 Like

Perhaps a good place to start would be listing some of the elements in an unlocked planes flight model config file?

I recognise some, others I’ve never heard of. I assume they are not just there for show, so it then becomes how well modelled they are.

I’m sure I saw parasitic drag in there, and yet I’ve read some here state that it is not simulated. So perhaps more a case of not simulated well enough?

Thank you Yeti64, for your time and effort to contribute to our argument.
If you please, Can I conclude that if Asobo is claiming to use 1000 points of data on the airframe to calculate the average lift force, and the point of lift on the 3D wing frame, that would enable the representation of the movement of accumulated forces that would present a general vector of movement, then why to have a CFD file? for what reason? we need to have the user change the data in this CFD file, but only to trim the 1000 points of calculation? Why do we need trimming of the aerodynamics calculations? If I understand programming, after calculating 1000 points of force, and then trimming the calculation to one value in the CFD file, Algorithmically speaking, it would be very beneficial to omit those 1000 points and present them only for visual marketing demonstration, so all the pilots over here that don’t have a clue about what is written within the code will be very impressed by all the marketing stunts, to claim we have a very fine simulator with great graphics to play with because we don’t have the brains to check out our investment.

I am very sad that Microsoft thought of me to be so stupid :frowning:

So, a quick read of the SDK would have produced an answer here. We do know a lot about what MSFS is doing. And yes, they are still using lookup tables…

LDRt or rather Long story short, 1. what was most important to their client (Microsoft) was that information from FSX be usable in MSFS. 2. "Indeed, we do not simulate the fluid movement around the aircraft at the moment so we must find a way to tell how each surface elements contribute to lift, drag, side forces and moments. "

From this quote from the SDK (after several pages of aerodynamic and geometric translation equations):

Normalization algorithm

This algorithm is used to compute aerodynamics coefficients of each surface element. Indeed, we do not simulate the fluid movement around the aircraft at the moment so we must find a way to tell how each surface elements contribute to lift, drag, side forces and moments. One guideline we want to follow when attributing local aerodynamics coefficients to each surface is to ensure consistency with the classical aerodynamics theory underlying FSX historical flight model. To this aim, an original normalization algorithm has been developed, that helps redistribute global aerodynamics coefficients and tables as provided by user across all surface elements so that the final forces and moments match the ones computed by FSX. Of course, this does not mean we are finally equivalent to FSX modelling, as forces are now distributed over all the aircraft geometry. It rather means that, when suming up all contributions, and thus losing geometrical distribution information, our more general model reduces to FSX historical model. This makes our model an extension of the historical model, which is in accordance with the objective of retro-compatibility. One great advantage of this is to guarantee a consistant behavior for aircraft designed with the historical model when used in the new model. This requirement is actually of the utmost importance for our client Microsoft.

The normalization algorithm is performed only once at the beginning of the game session.

The idea is to pre-compute, during this initialization stage, lift, drag, side and moments normalization coefficients for a pre-defined set of controls configurations. More precisely, 20 configurations involving flaps and spoilers deflections have been chosen. For each of these 20 aircraft controls configurations, 6 normalization coefficients are computed and stored. A detailed explanation of how these normalization coefficients are computed is provided further below.

During the game, at each simulation step, this big look-up table linking a given controls state to a set of normalization coefficients will be used to linearly interpolate current normalization coefficients from the current aircraft controls configuration as input by player. This interpolated set of normalization coefficients is then used to uniformly ponderate the lift and drag forces and the moments computed on each surface element, so that the simulation reaches the same global « zero order » solution as the one we would have computed with FSX historical model.

Now let us explain how these normalization coefficients are computed for each of the 20 chosen aircraft controls configuration during the initialization stage. The algorithm is illustrated in the scheme below.

To be fair, X-plane, for all it’s vaunted “Blade Theory”… They are actually only calculating the discretized forces on the wings, tail surfaces, and propeller. The gear, and apparently the fuselage, are not accounted for, at least at the time of the initial writing of the MSFS SDK.

3 Likes

To continue, there are some major advantages to the MSFS code over X-plane, and that will be exploitable in the future (it certainly sounds like they might be planning to include CFD in the future). And it is more than lookup tables a-la FSX, which only accounted for a few bodies, in this new code, they can calculate the affect of airflow over surfaces that get hit before others, there for simulating prop-wash and flow occlusion, which X-Plane cannot do.

to whit:

" Complex physical phenomena modelization

Stall modelization improvements in relation with surface elements model.

When an aircraft is flying normally, the air moves across the wing in a smooth stream. If the aircraft is pitched upwards sufficiently, the air stream becomes less fluid until it finally “detaches” from the wing. This is called a “stall”. FSX had a stall model, but the stalls weren’t entirely native to the simulation. That is, when the conditions for a stall occurred, some additional code would take over to simulate the stall, as a global phenomenon. While using FSX historical flight model, Asobo people and experimented pilots collaborating with Asobo have noticed poor behaviors for limit cases, typically when approaching stall which has motivated the team to put some additional efforts on physical modelling of « limit » flight configurations, which are notoriously badly represented in the classical aerodynamics theory underlying FSX historical flight model.

The introduction of 3D geometrical information in the flight model through surface elements, as described in the previous paragraph, was clearly a first mandatory step toward improving the physics, as it has enabled the modelization of local phenomena. To better account for stall and all its variants (spin stall, deep stall, simple stall), each surface element has been enriched with a float parameter describing its level of stall. When reaching a certain level of stall, the behavior of the surface is changed using additional parameters so as to follow, broadly speaking, the behavior of a falling plate. Reading the litterature about airfoils behavior in stall configurations, it can indeed be shown that local boundary layer detachment leads to a very sudden change in the aerodynamical behavior of the airfoil, that can be assimilated to a falling plate. The interested reader is refered to this NASA experimentally based study.

This plate model is used in the new flight model to locally change the behavior of surface elements depending on local stall state. This local stall model enables to accurately simulate classical stall but also spin stall, which is intrinsically impossible with FSX non-geometrical flight model. The effect of geometrically twisted wings on stall, which tends to delay stall as the wing root stalls before the wing tip, is also clearly simulated and can even be depicted in-game using debug mode. In the same way, a spin stall is like a normal stall, but it happens to only one wing of the aircraft. When one wing has lift and the other does not, the flying wing will continue to rise until it flips the plane. Without geometrical input in the flight model, historical FSX model could not really account for spin stall, which is now the case with the new flight model.

Surface elements interferences and geometrical self-perturbation modelization

We also believe that our new flight model has some notable and measurable advantages over XPlane11 due to surface interdependency: a surface hit by air will create a change in the airflow that will impact all other surfaces behind the first surface, an effect which is essential for simulating: - Engine wash - Shadowing - Deep stall

Geometrical analysis with respect to the flow direction is performed in the code. This enables to spot which surface elements are shadowed or washed and to temporarily alter their lifting properties accordingly. Future work using the 3D visual model will help improve the computation of occluded/washed surfaces for instance using ray tracing."

So I thought that was interesting, an advantage of ray tracing for flight simulator, is, that it can be used for flight modeling, too…

3 Likes

Thank you FlyingCool, for your professional approach in our auto deduction of what FS2020 will share with us as pilots of these flight models, I really hope Microsoft and Asobo, will read this thread and improve on the general impression of our users or pilots, and improve on the product, not in 15 years, but in a short time period, relative to how much money they have already made with the super marketing skills.

And Thank you Asobo/Microsoft for reading and paying attention to our intelligence in order for you to improve.

2 Likes

as I cannot be bothered to read the SDK.

is that excerpt pertaining to the legacy flight modal with respect to importation of old FSX etc aircraft only, being distinct from the modern flight modal that in the main doesn’t support legacy FSX aircraft - given the Asobo aircraft are geared around the modern flight modal, and the legacy flight modal is ONLY there for support legacy FSX aircraft

No, what it says is what I said at the top. It does indeed devolve to an FSX final calculation per se. IOW, the output is similar to what would be found from FSX for the position of the body at any given moment. How it gets there is very different, though, with lots of room for expansion.

But, the most important thing to Microsoft was that they wanted the ability to move FSX aircraft forward.

As a developer myself who routinely interacts with clients, who often think they know what they want, It’s REALLY important to really understand the clients problem, and sometimes guide them to solutions they didn’t realize they wanted. The good thing is, they do usually have a pretty open mind, and when shown an even better solution, don’t mind the result…

Edit: I suppose you could be right, this might be just the legacy model only, but I’m just repeating what the SDK says, and it says this is their “new”, which, upon reading several times, does seem like it has legs to grow in a lot of directions, and can be used effectively.

If I were to think logically about this, since they are calling this their “new” model. My bet is the legacy model is just that, they just repeat the FSX calculations, likely for situations where they don’t have as much information, or the information is, well, stuff in, stuff out, that worked in FSX, but would fail in the new more accurate model.

1 Like

What gives you the idea that XP can or does not simulate prop wash? In the link I posted prop-wash is specially mentioned and also how it is calculated.

Maybe I misunderstood what you wrote?

1 Like

I’m just repeating what they wrote. They did specifically say that X-Plane models the propeller, and they did imply that X-plane does not model surface interaction as deeply as they do (see above at the end).

Granted… They don’t state what version of X-Plane they are discussing. My bet, however, is that X-Plane’s calculations haven’t probably changed a whole lot since 10, which would have come out long before this was an twinkle in someone’s eye.

Here’s the initial stuff I left out, this led up to the information I posted above:

3 Likes

I appreciate you taking the time to reply and be informative and non-confrontational.

Well I enjoy understanding physics by playing with it, is that called applied physics? not Theoretical physics? Well, Why does the 787 in FS2020 stall at 120 knots while having max weight. While in X-Plane 11.52, I seem to bring the aircraft to the ground with gusting winds and I don’t seem to have those intense feelings of holding onto the stick in FS2020? What needs to change in my Joystick settings maybe or in the CFD file? or invest another 150 USD for an addon in another 2 years? or may be 5 years?

Please help, I love the graphics of FS2020… Please.