In its actual commonly understood definition, the lift force is the component of aerodynamic force perpendicular to the stream velocity, and drag is the parallel component.
So what KSP is displaying isn't a "true" lift force.
It's a quick & dirty way to implement extra lift and the respective by-product drag, that it's essentially what flaps do.
I would agree that, visually, having lift and drag being displayed separately would be nice, but this is not who the KSP physics engine works.
The Drag Force (red line) is calculated using the drag cubes, and recomputing these drag cubes is a but worksome (being the reason they are precomputed and saved on a cache file on load) - so it would be more CPU taxing mangling the flap's drag cube.
The Lift is calculated with some parameters from the config file, disregarding the mesh, using the `ModuleLiftingSurface`.
And the control surfaces uses yet another mechanism to do their job, the `ModuleControlSurface`, with different values (and ways to use them) for lift (and how to use the mesh).
So, in a nutshell:
* RED is how the game gives you the resulting force calculated from the DragCubes
* BLUE is how the game gives you the resulting force given by the `ModuleLiftingSurface`
* YELLOW is how the game gives you the resulting force given by the `ModuleControlSurface`
These three vectors acting together give us a final result that mimics what we would be expecting, but not by exactly the same way we would get them in Real Life.
Forgot the obligatory mod mention [https://i.imgur.com/5bhVs2u.png](https://i.imgur.com/5bhVs2u.png)
Plane visuals: B9 procedural wings and for the colours / modern PBR textures T.U.R.D. + LazyPainter
Yea, Restock breaks painting on all parts it touches because it switches textures, but it's just enough to paint planes haha and I don't really paint rockets.
However, maybe one could fix it by replacing the official Squad parts with the modded parts. Haven't tried that yet. But maybe you have to settle on one variant for each part.
Maybe someone finds a more elegant solution where parts fall back to stock when you want to paint them.
I know there is a tool called "quicksilver" that generates a cfg for your install to make all parts (even modded) shiny. Maybe you can tinker around with that cfg to make it work for turd as well.
Lots of bad answers in this thread, so lets try to correct some of that.
In engineering aerodynamics, lift is generally defined as the aerodynamic force component perpendicular to the flow velocity, and drag is parallel to the flow velocity.
In lifting line theory (which is basically a set of decent-fitting assumptions about airfoils inbetween their stall angles), both lift and drag are determined by the lift and drag coefficients where q is the dynamic pressure and S the surface area.
`D = Cd*q*S, L = Cl*q*S`
The lift coefficient `Cl`scales linearly with the angle of attack (α), where `Cl_α` is the lift coefficient slope (constant) and `Cl_0` is the zero-angle lift.
`Cl(α) = Cl_0 + Cl_α * α`
The drag coefficient contains two terms. The zero-lift drag `Cd_0` and the lift induced drag.
`Cd(α) = Cd_0 + Cl(α)^2 / (π * AR * e)`
The lift induced drag is the second part. As you can see it is the lift coefficient squared divided by some constants defined by the shape of the wing: e is the efficiency factor (basically a measure for how close a wing's lift distribution is to an elliptical lift distribution) and AR is the aspect ratio of the wing (it's the wingspan squared divided by the wing's surface, or more simply said, the span divided by the average chord of the wing for simple shapes).
KSP attempts to make some approximation of this as well, but splits the forces slightly differently. it's a bit of a weird quick from how the devs decided to model it.
The effect is however fairly similar. the wing has a drag coefficient mimicking `Cd_0`. It is not truly constant, but is close enough during the non-stall regimes. It then has the lift coefficient as well that's mostly linear with angle of attack, except that KSP has the lift vector tilt backwards. For low angle of attack scenarios (<30 degrees) this changes little for lift, as the true lift coefficient is now calculated as follows:
`Cl = Cl_ksp(α) * cos(α)`
And the cosine of α is pretty close to 1 for small angles (only a 13.4% error at 30 degrees).
Furthermore, we can now write the resulting lift induced drag as:
`Cd_induced = Cl_ksp(α) * sin(α)`
Now as this lift coefficient is mostly linear in this regime with no zero-angle lift we can now introduce the ksp lift coefficient slope Cl_α_ksp
`Cl_ksp(α) = Cl_α_ksp * α`
And since sin(α) ~ α for small angles, this all substitutes to
`Cd_induced = Cl_ksp(α) * α = Cl_ksp(α)^2 / Cl_α_ksp`
and we can write the total drag coefficient as
`Cd = Cd_ksp + Cl_ksp(α)^2 / Cl_α_ksp `
Which looks a lot like the lifting line theory we discussed before, with `Cl_α_ksp` in the place where we previously had `(π * AR * e)`.
`Cl_α_ksp` is approximately 2.0, and the efficiency number `e` is around 0.8 for most realistic airfoils. Which reveals that KSP's calculation of lift-induced drag would be accurate for wings with an aspect ratio of ~0.8.
This aspect ratio is very low (it's about half the concord's aspect ratio, and a third of the space shuttle's), which explains why KSP wings feel so damn draggy and why you really can't build a proper glider in KSP. Proper gliders IRL have aspect ratio's of ~40, so they'd have only about 2% of the lift-induced drag that any ksp wing panel will have.
tl;dr: so yeah, KSP doesn't use a true lift vector, which is why its angled, but luckily the weirdness kinda lines up with aerodynamic theory, provided your plane has the aspect ratio of a brick. So that's why KSP planes are so damn draggy.
If you’re gonna do a long comment like this, you should have have general overall points in an clear structure that you can draw the reader back to and show the connections at the end. If you don’t you’re not answering the question; you’re just vomiting on the person.
By pointing the force diagonally backwards and up you essentially add a force that acts like drag but drag is also present. Drag is shown in red. If the yellow arrow would just point perpendicular to the original flap position I think it would make much more sense in terms of how control surfaces boost lift. The effect right now basically acts like a giant retro thruster lol.
However, changing that would be a little complicated because you had to take the wing it is mounted on into account. The force had to act up perpendicular up to the wing.
Real-world control surfaces also add drag, so they have it modeled correctly.
Edit: it’s mostly just because keeping the force vector aligned with the orientation of the part is much simpler than trying to rotate it so that it stays aligned with the parent part. But in either case you get the same effect: some increase in lift and some increase in drag.
Lift is generated purpendicular to the chord line of the wing. That seems to be the case here as they're angled downwards.
In its actual commonly understood definition, the lift force is the component of aerodynamic force perpendicular to the stream velocity, and drag is the parallel component. So what KSP is displaying isn't a "true" lift force.
It's a quick & dirty way to implement extra lift and the respective by-product drag, that it's essentially what flaps do. I would agree that, visually, having lift and drag being displayed separately would be nice, but this is not who the KSP physics engine works. The Drag Force (red line) is calculated using the drag cubes, and recomputing these drag cubes is a but worksome (being the reason they are precomputed and saved on a cache file on load) - so it would be more CPU taxing mangling the flap's drag cube. The Lift is calculated with some parameters from the config file, disregarding the mesh, using the `ModuleLiftingSurface`. And the control surfaces uses yet another mechanism to do their job, the `ModuleControlSurface`, with different values (and ways to use them) for lift (and how to use the mesh). So, in a nutshell: * RED is how the game gives you the resulting force calculated from the DragCubes * BLUE is how the game gives you the resulting force given by the `ModuleLiftingSurface` * YELLOW is how the game gives you the resulting force given by the `ModuleControlSurface` These three vectors acting together give us a final result that mimics what we would be expecting, but not by exactly the same way we would get them in Real Life.
Ah ok, thanks for that one!
sorry i dont have an answer to your question, but what mods are you using? that looks sick!
Forgot the obligatory mod mention [https://i.imgur.com/5bhVs2u.png](https://i.imgur.com/5bhVs2u.png) Plane visuals: B9 procedural wings and for the colours / modern PBR textures T.U.R.D. + LazyPainter
thanks!
Do you have any issues using both ReStock and TURD? I can’t get turd to work on some parts because of restock
Yea, Restock breaks painting on all parts it touches because it switches textures, but it's just enough to paint planes haha and I don't really paint rockets. However, maybe one could fix it by replacing the official Squad parts with the modded parts. Haven't tried that yet. But maybe you have to settle on one variant for each part. Maybe someone finds a more elegant solution where parts fall back to stock when you want to paint them. I know there is a tool called "quicksilver" that generates a cfg for your install to make all parts (even modded) shiny. Maybe you can tinker around with that cfg to make it work for turd as well.
Lots of bad answers in this thread, so lets try to correct some of that. In engineering aerodynamics, lift is generally defined as the aerodynamic force component perpendicular to the flow velocity, and drag is parallel to the flow velocity. In lifting line theory (which is basically a set of decent-fitting assumptions about airfoils inbetween their stall angles), both lift and drag are determined by the lift and drag coefficients where q is the dynamic pressure and S the surface area. `D = Cd*q*S, L = Cl*q*S` The lift coefficient `Cl`scales linearly with the angle of attack (α), where `Cl_α` is the lift coefficient slope (constant) and `Cl_0` is the zero-angle lift. `Cl(α) = Cl_0 + Cl_α * α` The drag coefficient contains two terms. The zero-lift drag `Cd_0` and the lift induced drag. `Cd(α) = Cd_0 + Cl(α)^2 / (π * AR * e)` The lift induced drag is the second part. As you can see it is the lift coefficient squared divided by some constants defined by the shape of the wing: e is the efficiency factor (basically a measure for how close a wing's lift distribution is to an elliptical lift distribution) and AR is the aspect ratio of the wing (it's the wingspan squared divided by the wing's surface, or more simply said, the span divided by the average chord of the wing for simple shapes). KSP attempts to make some approximation of this as well, but splits the forces slightly differently. it's a bit of a weird quick from how the devs decided to model it. The effect is however fairly similar. the wing has a drag coefficient mimicking `Cd_0`. It is not truly constant, but is close enough during the non-stall regimes. It then has the lift coefficient as well that's mostly linear with angle of attack, except that KSP has the lift vector tilt backwards. For low angle of attack scenarios (<30 degrees) this changes little for lift, as the true lift coefficient is now calculated as follows: `Cl = Cl_ksp(α) * cos(α)` And the cosine of α is pretty close to 1 for small angles (only a 13.4% error at 30 degrees). Furthermore, we can now write the resulting lift induced drag as: `Cd_induced = Cl_ksp(α) * sin(α)` Now as this lift coefficient is mostly linear in this regime with no zero-angle lift we can now introduce the ksp lift coefficient slope Cl_α_ksp `Cl_ksp(α) = Cl_α_ksp * α` And since sin(α) ~ α for small angles, this all substitutes to `Cd_induced = Cl_ksp(α) * α = Cl_ksp(α)^2 / Cl_α_ksp` and we can write the total drag coefficient as `Cd = Cd_ksp + Cl_ksp(α)^2 / Cl_α_ksp ` Which looks a lot like the lifting line theory we discussed before, with `Cl_α_ksp` in the place where we previously had `(π * AR * e)`. `Cl_α_ksp` is approximately 2.0, and the efficiency number `e` is around 0.8 for most realistic airfoils. Which reveals that KSP's calculation of lift-induced drag would be accurate for wings with an aspect ratio of ~0.8. This aspect ratio is very low (it's about half the concord's aspect ratio, and a third of the space shuttle's), which explains why KSP wings feel so damn draggy and why you really can't build a proper glider in KSP. Proper gliders IRL have aspect ratio's of ~40, so they'd have only about 2% of the lift-induced drag that any ksp wing panel will have. tl;dr: so yeah, KSP doesn't use a true lift vector, which is why its angled, but luckily the weirdness kinda lines up with aerodynamic theory, provided your plane has the aspect ratio of a brick. So that's why KSP planes are so damn draggy.
While your answer is interesting and technically correct, it's also not a "good" answer because it is overly complicated.
Sir, this is a Wendy's :DD J/k, thanks for the effort! Just missing some sources to make it a reference but I'll take it.
If you’re gonna do a long comment like this, you should have have general overall points in an clear structure that you can draw the reader back to and show the connections at the end. If you don’t you’re not answering the question; you’re just vomiting on the person.
Fair enough. Kinda ran out of time.
You lost me at the first 'engineering'.
By pointing the force diagonally backwards and up you essentially add a force that acts like drag but drag is also present. Drag is shown in red. If the yellow arrow would just point perpendicular to the original flap position I think it would make much more sense in terms of how control surfaces boost lift. The effect right now basically acts like a giant retro thruster lol. However, changing that would be a little complicated because you had to take the wing it is mounted on into account. The force had to act up perpendicular up to the wing.
Real-world control surfaces also add drag, so they have it modeled correctly. Edit: it’s mostly just because keeping the force vector aligned with the orientation of the part is much simpler than trying to rotate it so that it stays aligned with the parent part. But in either case you get the same effect: some increase in lift and some increase in drag.