MSFS flight model

[mrueedi 702]

 

57 minutes ago, blingthinger said:

That section is after they are back in FSX land.

They are never back in FSX land. Again, the normalization does not takes the dynamic out of the model, it only scales the output to match the static variables like roc, speeds, fuel flow. And the section you mention does not describe the generation of the forces and moments at all.

1 hour ago, blingthinger said:

My point is that the 20 config lookup table is going to smear out the dynamic response of the airframe.

How can a static factor, which is mulitplied with dynamically changing forces smear out anything? Again, at initialization, they once calculate this normalization factor per surface, which then at runtime is simply applied to the dynamically calculated forces and moments. It does not smear out anything. It only guarantess, that little deviations of the 640-surface-model over the time are canceled out and the forces mid- to long-term will cause the required (by the classical aerodynamics model) flight performance figures.

1 hour ago, blingthinger said:

What motions are induced? Are there motions about more than one Cartesian axis?

Yes. In the section "handling time step", you can read this "It is important to understand that Fb=Fb(xG,θ,vG,ω) and MGb(xG,θ,vG,ω) are themselves dependent on these 6 unknows, i.e: forces and moments obviously depend on the translation/rotation velocity and position of the aircraft, which makes these equations strongly coupled."

1 hour ago, blingthinger said:

CFD requires some sort of geometry definition. It's not CFD otherwise.

IIRC the SDK page was written before the CFD additions. The last section says "Future work using the 3D visual model will help improve the computation of occluded/washed surfaces". Whether that "future work" applies to the CFD update shipped with SU9 or means "future = post SU9", I dont know. From the documentation about CFD that we have received, they are certainly considering the 3D visual model for it.

1 hour ago, blingthinger said:

it would then get reduced down to a 20x20x20 volume grid

What do you mean with that? The 20 aircraft control configs? Again, that methodology only calculates normaliuation factors once, which are statically applied during runtime to ensure that the 640-surface-model produces the flight performance figures in the right ballpark.

Anyway, anybody who is denying that the presented flight physics are not a serious effort in pushing the boundaries of PC based flight sims is only lying to himself...

[lwt1971 7,419]

37 minutes ago, mrueedi said:

Anyway, anybody who is denying that the presented flight physics are not a serious effort in pushing the boundaries of PC based flight sims is only lying to himself...

Absolutely 100% this.. and it's a narrative that's been well orchestrated and pushed out there about MSFS's flight physics since its release, and now it's those who're deluded or lying to themselves or agenda-driven that keep parroting it.

In addition to the CFD-driven atmospheric airflow improvements and gliders coming in SU11, let's not forget the various aspects of helicopter physics MS/Asobo plan to tackle: see https://youtu.be/_AAiraI837U?t=2289 .. where over a 1000 surfaces will be simulated, and stuff like translational lift, ground effect, phase lag, ring vortex, rotor flapping will be simulated.. also rotor spin granularity being increased from 100hz to 1000hz, temperature effects on climb, etc
 

Edited September 9, 2022 by lwt1971

[blingthinger 649]

43 minutes ago, lwt1971 said:

Absolutely 100% this.. and it's a narrative that's been well orchestrated and pushed out there about MSFS's flight physics since its release, and now it's those who're deluded or lying to themselves or agenda-driven that keep parroting it.

It's a cute marketing effort that is still not fully matching the dynamics achieved by other methods. There's a reason the level D sims solely use single point lookup tables instead of these force elements or blade elements. Asobo isn't pushing any boundaries yet. They're doing something different to spice up the look up tables that are too simple to compete effectively without massive manufacturer input.

That said, when FSX is removed from the equations (and the SDK) and this is fully CFD-based, then there's reason to be excited. For now, FSX remains the "achilles heel" of the algorithm. 

[lwt1971 7,419]

24 minutes ago, blingthinger said:

It's a cute marketing effort that is still not fully matching the dynamics achieved by other methods. There's a reason the level D sims solely use single point lookup tables instead of these force elements or blade elements. Asobo isn't pushing any boundaries yet. They're doing something different to spice up the look up tables that are too simple to compete effectively without massive manufacturer input.

That said, when FSX is removed from the equations (and the SDK) and this is fully CFD-based, then there's reason to be excited. For now, FSX remains the "achilles heel" of the algorithm. 

The merits & negatives of table-lookup based methods vs CFD/BET aside, don't see how this is a "cute marketing effort" sorry... their modern flight dynamics engine along with the CFD improvements have resulted in very plausible aircrafts like the default C172 which employs all aspects of their FDE to some degree, and even better FMs from 3rd party aircrafts like the Sting S4 and Milviz C310 that also use all these new features like CFD.  "Pushing boundaries" might be up for debate sure, but the main point here is the Asobo is surely giving equal if not more focus to improving flight physics, atmospheric airflow, weather etc in addition to visuals and world rendering (counter to the traditional drumbeat criticisms).

Outside of being beneficial to pure aircraft flight models, the CFD technology is also being employed by Asobo for simulating atmospheric airflow which lookup tables can do nothing for... hopefully we'll get more details on this in their upcoming feature discovery series.

When using the moderm FM +/- CFD in MSFS, how is the legacy FM (FSX-related) stuff being an archilles heel? Can you explain further? Apart from ground handling I mean.

Regardless of table lookup schemes or CFD or BET there is always going to be a need for the particular aircraft experts' inputs in order to refine the final flight model for that aircraft... that much is clear I'd say.

Edited September 9, 2022 by lwt1971

[blingthinger 649]

2 hours ago, mrueedi said:

They are never back in FSX land.

They average all the forces back down to a single point force and then move the model. That's FSX.

 

2 hours ago, mrueedi said:

which makes these equations strongly coupled."

Again, you're reading in the FSX section. After everything is averaged down to a single point force or moment.

I'll repeat the force element text here. Again.

"We then initialize the algorithm by attributing - to each surface element - local lift, drag and moments coefficients".

They're very clear that lift, drag and moments are distributed to each element. Distributing moments does not make sense if you already have forces. Unless you don't trust what the forces will end up doing. (Edit: I explain in a later post)

 

2 hours ago, mrueedi said:

From the documentation about CFD that we have received, they are certainly considering the 3D visual model for it.

Source URL?

 

2 hours ago, mrueedi said:

What do you mean with that? The 20 aircraft control configs?

No. The spatial resolution of the volume grid for the CFD solution. Their default spatial resolution is 20x20x20.

https://en.wikipedia.org/wiki/Types_of_mesh

They are creating a volume around the airframe and filling it with cube cells. 20 wide by 20 deep by 20 long. This means 8000 cells. A small fraction of those touch the airframe surface because most are comprising the volume around the airframe. Modern, physically-accurate CFD places millions of cells in the volume box. There's no boundary-pushing here. There is a medal to Asobo for first place though. 

2 hours ago, mrueedi said:

How can a static factor, which is mulitplied with dynamically changing forces smear out anything?

Let's clarify what they mean by the 20 operating points. Point 1 might be the baseline, so for example: flying at a given velocity, straight and level, gear up, flaps up, no control deflections. Point 2 might be identical except that flaps are at 5 deg. Point 3 might be the same as point 2, except that ailerons are deflected a few degrees....and on. 20 points. That's it.

So if your control surface combination while flying is NOT at one of those 20 points (which is MOST OF THE TIME), you're interpolating: combining an average of the nearest of the known 20 points. Any dynamic behavior that might be induced when between those points is going to be missing.

Edited September 9, 2022 by blingthinger

[blingthinger 649]

19 minutes ago, lwt1971 said:

how is the FSX-related FM stuff being an archilles heel?

Let's say the left wing passes through a cloud with a lot of updraft (correct me if I'm wrong but this scenario has been discussed by Asobo but isn't implemented yet). There's suddenly a big force acting on that wing. It's inducing a rolling moment on the entire airframe. Rolling right.

So the force elements on that wing tip section have a huge force. Nice. Then they start the squeezing algorithm. They scale every single force element (600+ of them) together such that the final summation is equal to the FSX curves. Those massive forces on the tip now get squished down...or maybe even scaled way up (beyond what would actually be there) because of the neighboring forces, such that the overall sum is = FSX. So there will be some dynamic bumpiness, but only as far as the FSX curves (and neighboring force elements) let it be.

Now...I could be wrong in how I'm reading the SDK. That's the main reason why I'm posting all this. I want to know if I'm wrong. As far as I can tell, there's no way PMDG (for example only!) can recover this lost dynamic movement. Unless they put so much additional input into the model that it's....overriding Asobo's?

 

19 minutes ago, lwt1971 said:

Regardless of table lookup schemes or CFD or BET there is always going to be a need for the particular aircraft experts' inputs in order to refine the final flight model for that aircraft... that much is clear I'd say.

100% agree.

Edited September 9, 2022 by blingthinger

[blingthinger 649]

1 hour ago, blingthinger said:

They're very clear that lift, drag and moments are distributed to each element. Distributing moments does not make sense if you already have forces. Unless you don't trust what the forces will end up doing.

Correcting myself here. It's not a matter of trusting the forces. Table lookup models need both force and moment information. The fact that the moments and forces are being calculated simultaneously is simply to match the FSX curves. This means that moment information does need its own solution on all the elements, uncoupled from forces, but will suffer the same scaling artifacts as the forces.

There's nothing fishy going on here. It's just following the general algorithm.

[mrueedi 702]

3 hours ago, blingthinger said:

So the force elements on that wing tip section have a huge force. Nice. Then they start the squeezing algorithm. They scale every single force element (600+ of them) together such that the final summation is equal to the FSX curves.

You clearly do not understand, what they are doing.

You also miss, that the sum of all forces acting on a solid body are effective at one point.

And you clearly have not understood, what part the FSX normalization plays in the whole processing.

A big force acting on one wing will be processed by the respective 200 or so surfaces and create a roll moment, which will be computed into the 6Dof solid mechanics equations.

The SDK document is quite comprehensive, but it does not cover all, and it allows apparently terrible misinterpretations. I mean, you are even getting the sections wrong, which are talking about FSX and those which aren't.

 

[robert young 2,897]

I think that sometimes there is quite unnecessary complexity in the CFD ambitions described in many posts. While a sophisticated approach is desirable, that is only the case when reaction to control inputs are reasonably believable - and many of the really basic flaws currently present in MSFS can be solved with very simple solutions. For me the most glaring repeated mistake is the gross over-sensitivity in pitch control in over 90% of current default AND addon GA aircraft. This is such an elementary flaw and I have never understood why some simmers and even experienced real pilots seem to accept it as "normal". It isn't.

If you can only control a typical light sim aircraft by tiny movements of the stick then straight away that is not at all realistic. yet somehow many forgive these flaws or adjust their flying technique in maybe an effort to adapt. In addition, if your sim aircraft is bouncing up and down at the slightest pitch input this is also a basic flaw. In modern light aircraft, and many vintage aircraft too, the tendency to return to previous pitch then oscillate wildly at the slightest stick input is GROSSLY exaggerated in not just MSFS but other sims as well. You do not need sophisticated CFD algorithms to solve this. You just need to damp out the undesired oscillations.

Similarly, if it is difficult to perform a simple coordinated turn with aileron and a little rudder then you do not need advanced CFD to solve it. You just need to tune quite simple parameters to iron out the worst of the problems. It really does not need hugely complex computational stuff to do this.

However where crosswinds are concerned it is very difficult to correct what is obviously a flawed underlying core flight model and all you can do is iron out the worst of the effects that are clearly baked in.

I think it is always best to take the simplest approach possible to produce a reasonably good flight model. It really does not require enormously complex systems, which is why the much maligned look up table method is quite recklessly criticised in some quarters. Flight simulators are purveyors of illusion, just as CGI animations create an illusionary world. The goal is to deliver the illusion of flying and for that simple look up tables are perfectly adequate for 90% of desired characteristics.

The problem is that some want to run before they've learned to walk. There is no point in claiming to develop sophisticated CFD systems when you can't even make a simple aircraft respond to the simplest control input. 

[Sky_Pilot071 580]

My thought is based on the current architectures which are best guesses at best.  So pros or cons to one or the other follow suit.

That said my chosen platform is the one I like best.  Currently that is MSFS  due to its close approximation to a realistic flight environment.

sp

[blingthinger 649]

 

1 hour ago, mrueedi said:

You also miss, that the sum of all forces acting on a solid body are effective at one point.

And you clearly have not understood, what part the FSX normalization plays in the whole processing.

Please do, tell me where I'm wrong here. That's exactly what I'm asking for. You keep saying I'm wrong but then do not explain anything.

I have repeatedly stated the the forces get summed up to a single point. FSX is a single point model. The lookup tables are based on a single point in space. Generally somewhere in the middle of the airframe.

Asobo's model adds the force elements together. If that sum doesn't equal what is on the FSX curve at that particular flight condition, it scales the force and moment (actually it's the coefficients). It shrinks or grows all of them, together, multiple times if necessary, until they match FSX. That explanation is very clear in the SDK:

"At the end of each iteration, we correct the surface elements local aerodynamics coefficients - uniformly multiplying surface elements lift, drag, side, and moments coefficients by a ratio comparing FSX legacy models with the new model."

After the sum of the force elements equals the FSX lookup tables, it moves to the next step. That step is the section with all the motion equations you keep referencing.

 

[blingthinger 649]

37 minutes ago, robert young said:

There is no point in claiming to develop sophisticated CFD systems when you can't even make a simple aircraft respond to the simplest control input.

This why my feelings are mixed on this one. I love the fact that they're trying to do it. But there's so many places it can and does go wrong. This is likely why it is restricted to just a few applications in the flight model.

 

40 minutes ago, robert young said:

If you can only control a typical light sim aircraft by tiny movements of the stick then straight away that is not at all realistic.

I wonder. How much of this is due to a wide range of joystick equipment and sensitivity curve settings? Would this play into the pitch oscillations as well?

[tweekz 2,165]

This landig pretty much sums up all I have to complain about MSFS' landing physics. Exaggerated lift, sensitive ground movement. The handling on the ground seems sensitive all the way. Not just after touchdown.

 

Edited September 10, 2022 by tweekz

[mrueedi 702]

7 hours ago, blingthinger said:

Asobo's model adds the force elements together. If that sum doesn't equal what is on the FSX curve at that particular flight condition, it scales the force and moment (actually it's the coefficients). It shrinks or grows all of them, together, multiple times if necessary, until they match FSX. That explanation is very clear in the SDK:

"At the end of each iteration, we correct the surface elements local aerodynamics coefficients - uniformly multiplying surface elements lift, drag, side, and moments coefficients by a ratio comparing FSX legacy models with the new model."

After the sum of the force elements equals the FSX lookup tables, it moves to the next step. That step is the section with all the motion equations you keep referencing.

What you are missing, is that this calculation takes place only once at initialization when the plane is loaded. It runs with the goal to compute the normalization coefficients. These are calculated per surface. They are just constant numbers, factors to be precise (normalization is about scaling or multiplying), per surface, which are applied to the forces and moments during runtime.

During runtime however, the full dynamic of the flight model is at work and the forces and moments are just multiplied with these constant normalization coefficients in every step. They don't interfere with the dynamic part of the flight model. They just scale its output so that the requirements of the classical aerodynamic theory are met.

See this diagram, lets say the curve is the lift force over time:

Red is the curve, which FSX would have computed, orange is the curve computed by the 640 surface model alone, and green is the curve of the 640 surface model, scaled by the normalization coefficients to match the dimension needed met flight performance requirements.

Green is the result of the MSFS flight model, red would have been FSX.

Unless you understand this basic processing flow, all your conclusion are somewhat moot.

[jcomm 5,939]

1 hour ago, mrueedi said:

What you are missing, is that this calculation takes place only once at initialization when the plane is loaded. It runs with the goal to compute the normalization coefficients. These are calculated per surface. They are just constant numbers, factors to be precise (normalization is about scaling or multiplying), per surface, which are applied to the forces and moments during runtime.

During runtime however, the full dynamic of the flight model is at work and the forces and moments are just multiplied with these constant normalization coefficients in every step. They don't interfere with the dynamic part of the flight model. They just scale its output so that the requirements of the classical aerodynamic theory are met.

See this diagram, lets say the curve is the lift force over time:

Red is the curve, which FSX would have computed, orange is the curve computed by the 640 surface model alone, and green is the curve of the 640 surface model, scaled by the normalization coefficients to match the dimension needed met flight performance requirements.

Green is the result of the MSFS flight model, red would have been FSX.

Unless you understand this basic processing flow, all your conclusion are somewhat moot.

Very interesting essay over MFS's Flight Dynamics Engine / Model !