If you can’t figure out how to simulate a plane yet, simulate a parachute. That’s a lifting surface where the air always hits it from the same direction.
Well in that case let me explain anything and everything about flight dynamics to you in a way you won’t understand!
A dynamic configuration is the exact state the aircraft is in at that moment in time; its airspeed, pitch angle, bank angle, yaw, angle of attack, angle of sideslip, pitch rate, aoa rate etc. all these factors combined determine the aircrafts forces and moments, some of those factors are negligible, others aren’t. The most important and prominent one is the angle of attack or AoA, also denoted as α.
The angle of attack of an airfoil is the angle between its chord line and the airflow relative to it:
This is THE primary component of lift, as the angle increases, lift increases, if the angle of attack reaches a critical angle, the airflow will separate and the wing will stop producing lift.
Here’s an example graph of the F-16:
As you can see, at a little over 35 degrees AoA the lift coefficient starts going down again, this is what a stall looks like. Basically all Cl vs α curves look like this, it goes up almost linearly and then drops off. And here’s where stability derivatives lie in. If you sample 2 coefficients at 2 angles of attack, you can get a slope/derivative, a derivative is the rate of change of a thing in regards of another thing, velocity for example is the rate of change in position. A stability derivative can be calculated like this:
change in force (or coef) / change in dynamic configurationHere’s an example on a lift coefficient curve:
Here the resulting stability derivative is 0.13 units of lift coefficient per degree of angle of attack, if you multiply any number by this number, you will get the coefficient of lift at that angle of attack, assuming the AoA is in degrees. This linearization generally works for smaller things that actually are linear, as you can see the Clα curve is not linear, it curves downwards eventually, so the stability derivative method will work for the main lift, up until the critical angle, at which point it will just keep increasing and therefore not model stalls, you can come up with a quadratic equation that closely matches the actual numbers, or you can just use a look-up table, which is what Microsoft Flight Simulator does, they also use stability derivatives for less significant factors that can be linearized, unlike the Clα curve.
A stability derivative also doesn’t take into account any offset that may be present at α = 0, cambered airfoils for example generate lift at 0 angle of attack, but there’s a simple solution: just add the difference after calculating the coefficient.
Look-up tables
A look-up table is exactly what is sounds like, it’s a table full of numbers which specify how much lift a given angle of attack gives.
Here’s an example of how a lookup table might look:
Here the left column is the angles of attack and the right column are the coefficients of lift. According to this table at 15 degrees of AoA the lift coefficient is 1.6.
You’re probably asking yourself now “but what if the plane is at an AoA that has no table entry? Like 4.5 for example? what if it’s some ridiculously specific number like 4.543534765474234234534534?? You can’t have infinite precision, it’s just not possible, so how do account for that?”
Simple, get the closest number below 4.5 and the closest number above 4.5 and interpolate the two coefficients at those angles. Now you can get the coefficient of lift at any angle of attack as long as the input aoa is within the minimum and maximum specified range. Here’s what the graphed out table looks like:
And this is also what the entire 360° spectrum of lift vs aoa looks like for the NACA 2412 airfoil, generally you won’t find this information anywhere as no one cares about numbers below -5 and above 15 degrees, but if you plane is tumbling or something where the aoa keeps changing rapidly and goes in all sorts of different areas, you need to get some number for your calculations to avoid errors or unwanted behavior.
So, Either make up numbers or try to find them on the internet, there’s a site called airfoiltools.com where you can get aerodynamic data of various NACA airfoils. Apply this method for the other forces/moments, drag, side force, pitch, yaw, roll and you got your coefficients!
Now we can finally move on to getting the forces and moments, and making the plane actually move.
There’s 5 total forces acting upon an aircraft. No, not 4. 5.
Lift, Drag, Weight, Thrust and the Side force. The side force is basically lateral lift created by the fuselage and the tail of the plane if it flies with a yaw angle, which is not negligible. We won’t talk about weight and thrust because I don’t know how to model engines and weight is already done by Roblox. Just add a forward force * a throttle setting or something.
Drag acts in the direction opposite the airflow:
dir_drag = -aircraft.Velocity.Unit That’s it.
Lift and side forces act perpendicular to the direction of the airflow.
A common misconception is that lift acts upward of the actual airfoil/aircraft, THIS IS NOT TRUE, THAT IS THE NORMAL FORCE! You can use either lift & drag, or normal & axial forces, you don’t need both. if you know one pair of forces, you can figure out the other.
So now we need the angle of attack (again), to get the direction of lift:
Assuming -Z is the forward direction, you can calculate the angle of attack as such:
AoA = atan2(-v.Y, -v.Z)and while we’re at it, sideslip:
AoS = asin(v.X / v.Magnitude)Note the v is the velocity in the local body frame of reference, which can be calculated as:
aircraft.CFrame:VectorToObjectSpace(aircraft.Velocity) (i think you may have to normalize it so put a .Unit at the end just in case, idk tho)Now you can rotate the body frame into what’s called the wind axis:
windex = aircraft.CFrame * CFrame.Angles(-AoA, 0, 0) * CFrame.Angles(0, -AoS, 0)(idk why theres so many minus signs, im just copy pasting my code which works)
Using this CFrame you can— no. no you don’t use that CFrame to set the plane’s position no. This CFrame will act as the wind frame of reference, if you remove the sideslip term you’ll get the stability frame (which is stupidest reference frame seriously who uses this)
Now you can get the lift and side direction:
dir_lift = windex.UpVectordir_side = windex.RightVectordir_drag = -windex.LookVector - or just the negative velocity unit, both works
Ok now let’s start with calculating the lift force.
We will use a very simple model with only one parameter for lift:
Cl_α - Cl vs angle of attack
First you get the lift coefficient from the angle of attack, whether it be from a lookup table, quadratic function or a stability derivative.
Then you get the density of the air at the aircrafts position, which varies with altitude, you can use either the international standard atmosphere table or just google the equation for air density vs altitude it’s a really simple equation.
The air density unit will be in slugs/ft^3 and the velocity in feet/sec and with it you calculate the dynamic pressure:
Q = air_density * .5 * aircraft_velocity.Magnitude^2
The reference area S can be any number you want, in square feet
And here’s your final lift force:
F_lift = Cl_a(AoA) * Q * S
(forces are in pounds)
Now on to drag:
Drag is both created by the air pushing against the plane, called parasitic drag and the compressibility of the air as the plane approaches the sound barrier, called wave drag. But is also induced via lift, that’s why we calculated the lift first, we don’t need the lift force, just the coefficient. And the parasite drag… can be neglected for some reason?? Because Microsoft Flight Simulator actually neglects parasitic drag vs angle of attack, and only uses lift-induced drag + parasitic drag at AoA = 0, so if this is good enough I guess we can simplify this and just use 1 constant for drag at 0° AoA.
We can ignore wave drag.
Hence, the drag coefficient is calculated as:
Cd0 = any number you want, generally between .01 - .025 – drag at 0-aoa
Cdi = (Cl_a(AoA)^2) / (pi * AR * oswald) - lift induced drag
Where
pi is 3
AR is the aspect ratio of the wings, calculated as: (wing_span^2) / wing_area
oswald is the oswald efficiency factor, generally less than 1
(MSFS calculates induced drag slightly differently and I can give you their equation if you want, but this is good enough)
And the total drag force is:
F_drag = (Cd0 + Cdi) * Q * S
Side force:
ughhh let’s move on
Moments
The general moment equation is similar to the lift & drag equation but with 1 extra parameter: wing span (b) for yaw and roll, or mean geometric chord (c_) for pitch
Let’s start with the pitch moment
As the angle of attack increases, the plane will either want to pitch down if it’s stable, not do anything if it’s neutral, or pitch up even more if it’s unstable. You can use a simple stability derivative for the pitching moment even though a lookup table would be better as the pitching behavior changes post-stall.
So the pitching moment is calculated quite easily:
M_pth = (CM_a * AoA) * Q * S * c_
except, you can’t ignore dynamic effects and you need to include at least one extra factor:
The pitching moment due to pitch rate (CM_q), there’s also the pitching moment due to AoA rate (CM_adot), so we might as well just include that as well.
These are generally linearized so 1 single number for both will be enough, no need for tables. You want CM_q to be negative and this derivative can get quite large.
These are also called damping coefficients, these are required so that your plane doesn’t pitch up and down like crazy, like a spring without a damper.
Since these are dynamic coefficients you can’t just add them onto the main pitching moment coefficient, you need to add them onto the total pitching moment like this:
M_pth = M_pth + (((CM_q * q) + (CM_adot * adot)) * ((c_)/(2*airspeed)) * Q * S * c_)
Where q and adot are the pitch rate and aoa rate respectively
Do the same thing with the yawing moment:
M_yaw = (CN_b * AoS) * Q * S * b
M_yaw += (((CN_r * r)) * ((b)/(2*airspeed)) * Q * S * b)
Once again, CN_b is the yawing moment vs sideslip, AoS is sideslip, CN_r is the yawing moment due to yaw rate and r is the yaw rate itself
And of course roll just damping:
M_roll += (((CL_p * p)) * ((b)/(2*airspeed)) * Q * S * b)
Of course, if you want to add controls, all you need to do is add another extra coefficient and multiply it by the deflection of the flight stick.
for example:
M_roll += (CL_da * ail) * Q * S
where CL_da is the roll moment due to aileron deflection and ail is the aileron deflection. Do the same for pitch and yaw and you got working controls.
Now to make the aircraft move:
Since you asked, :ApplyImpulse() and :ApplyAngularImpulse() just simply apply a force and a moment (or torque) to a part, that’s it. Imagine pushing something, yeah that’s it.
So you add up all forces:
F_lift3d = dir_lift * F_lift
F_drag3d = dir_drag * F_drag
F_thrust3d = aircraft.CFrame.LookVector * F_thrust
And you apply the forces:
aircraft:ApplyImpulse(F_lift3d + F_drag3d + F_thrust3d)
And the moments are in the local object space, so it’s slightly different:
aircraft:ApplyAngularImpulse(
(-aircraft.CFrame.LookVector * M_roll) +
(aircraft.CFrame.RightVector * M_pth) +
(aircraft.CFrame.UpVector * M_yaw)
)
There you go, do that every frame and you got a very basic simple plane
10 Likes
you can also just use the built-in roblox aerodynamics if you dont want any realism
2 Likes
The issues you’re experiencing have to do with the limitations of discrete-time simulations. The laws of aerodynamics are defined in continuous time, which means time can be sliced up infinitely fine in order to create a valid path from one state to another. A fundamental issue in simulating continuous time physics on a computer is you have to pick finite, and usually constant, time step.
Instability comes from using too coarse of a time step. Not all problems allow you to pick a “small enough” time step either. Many flight sims use a step about 4 times higher than the framerate, so about 1/240th of a second. Essentially too large a step causes the rules to diverge from what your simulation actually shows. This can even be a source on un-conserved momentum or energy.
This is probably not relevant as you aren’t going to want to simulate fluids at such a low level, but I found this video very informative for thinking about aerodynamics and it might interest you: https://www.youtube.com/watch?v=IVLpbOQUdqU
1 Like
I don’t think that’s exactly what I meant, but alright.
I made a breakdown of how to implement realistic aircraft physics, as well as an example of its implementation. I think its got everything you need to understand how to approach something like this, and how to actually make it work. I hope it helps: Creating Realistic Plane Physics
Hey all. Thank you for all the replies, I apologize for being late here. Tried to extend my break.
I did it and it was a good start. I made it in a way the drag would only apply on the wide area and not the edges, locally. It did not only simulate the air resistance, but tilting the plate causes it to fall towards the lowest point as well.
I think you overexplained it, but it was amazing. I had to read it several times within the timespan away from the forum since my brain wasn’t pairing with. A bit rough there, but I appreciate the effort you put here.
Tested the place. It’s good, but I found strange behaviors. Some of the scripts aren’t explained, I went for the Physics script . I’m unfamiliar to ModuleScripts, so I don’t recognize some of the language.
I’ve had taken a break from Roblox developing for too long, way before I made this topic. Looking at those numbers and calculations scared me.
I assume that BodyVelocity is not ideal for “realistic” aerodynamics, and BodyForce will do the job. Since they work by applying constant forces, they are known to send objects to beyond lightyears. And this is where drag force is important.
I’ve tried testing it in a single BasePart to see if they work, while also experimenting different approaches and combinations.
@Imperiector told me to get CL from AoA, but I don’t feel like writing the lookup table. So, I had to ask ChatGPT’s opinion—knowing most of my questions for Ro-deving resulted in failure 
local airDensity = 1.2
local CL_alpha = 4.5 -- Depends on wing types, GPT said ¯\_(ツ)_/¯ (F-15 Eagle)
local CL_0 = 0.2 -- CL at zero AoA
local S = 2 -- "The reference area S can be any number"
local Q = airDensity * 0.5 * velocity.Magnitude^2 -- Dynamic pressure
function calculateLift(Q, AoA)
local CL = (CL_alpha * AoA) + CL_0 -- GPT's formula
local lift = CL * AoA * Q * S
return lift
end
I’ve printed out the CL while the part goes in different directions, and… random, numbers. Somewhere between -13 to 7, I am clueless. I’ve made sure that AoA was correct.
Even worse with the lift. Went from negative tiny decimals to randomized, uneven numbers.
I am unable to calculate lift-induced drag without CL.
1 Like
For the lift equation, you dont want to directly use the AoA to calculate the lift force. The AoA is used to calculate the lift coefficient. To clarify, AoA in simulations should only be how much the plane’s nose(cord line) deviates from the velocity vector ON THE PITCH AXIS. This means we are not concerned with the yaw axis AoA. In my physics module i use this function:
function Physics.calculateLift(velocity, liftPower, AOA)
-- Lift = 0.5 * velocity^2 * liftcoefficient * liftpower(hand tuned)
-- A curve sin(3x) derives the Lift Coefficient outputting values from 1 to -1 depending on the AOA.
-- Only values from -60 to 60 aoa will output coefficiencients from -1-1 beyond is the stall region, where coefficient stays 0.1
local liftCoefficient = math.clamp(math.sin(math.rad(3 * AOA)), -60, 60)
local lift = 0.5 * velocity.Magnitude^2 * liftCoefficient * liftPower
return lift/1000
end
It might sound complicated, but its essentially using the AoA to output a value from -1 to 1, that will determine the lift force. Planes are designed to go up when they face up, and down when they face down. The lift force can be positive, or negative, and its strength is dependent on angle of attack. The lift coefficient in this scenario is calculated by a sin(3x) curve.
You can see how when we provide an angle of attack(lets say 30) to the sin(3x) equation, its giving us a value of 1. This means at 30 the lift force is at its maximum. You can also see that at -30 (30 degrees BELOW the velocity vector) AoA we get maximum NEGATIVE AoA. This way, the lift force will be pointing down when we are flying down, and pointing up when we fly up. Past 30 degrees, the lift force starts to fall off, and at 60 degrees, we are stalling, since the plane no longer generates lift.
So, to summarize, the lift equation IRL is Lift = CoefficientLift * wingArea * 0.5 * airdesnity * Velocity^2. Our equation is simplified, we ignore airdensity along with wing Area, and replace it with a custom tuned liftPower variable that can be changed for different planes. We effectively get: 0.5 * V^2 * LiftCoefficient * liftPower. Our lift coefficient will make the lift force positive when we are pointing our nose above the velocity vector, and negative when we point below it. This is how i calculated my AoA:
-- Oncoming wind is opposite to the direction of the velocity vector
-- The AOA is calculated by getting the angle that the look vector deviates from the velocity vector
if velocity.Magnitude > 0 then
-- Project the velocity vector onto the plane's vertical plane
local projectedVelocity = velocity.Unit - CF.RightVector * velocity.Unit:Dot(CF.RightVector)
-- Calculate the angle between the projected velocity and look vector
local dotProduct = math.clamp(CF.LookVector:Dot(projectedVelocity.Unit), -1, 1)
local cross = CF.LookVector:Cross(projectedVelocity.Unit)
local sign = cross:Dot(CF.RightVector) > 0 and -1 or 1 -- Check if the aoa is pos/neg, if nose is above/below velocity vector
-- Convert to degrees and apply neg or pos, clamp from -90 to 90
AOA = math.clamp(math.deg(math.acos(dotProduct)) * sign, -90, 90)
else AOA = 0 end -- To avoid NaN AoAs
Sometimes we divide by 0 when our velocity is 0, and we get NaN AoA values, which breaks literally everything, so we have checks to see if we are above 0km/s. Velocity is a 3d vector pointing in the direction of travel the plane is moving in, and its MAGNITUDE is the speed it is traveling in that direction. When we say “if velocity.Magnitude > 0 then”, we are pretty much saying “only calculate the AoA when we are moving”. This way our physics functions that include AoA dont start crashing and printing errors.
Finally, in our AoA calculations, we are also outputting negative AoA. AoA is always say to be “the angle between the chord line of an airfoil (like an aircraft wing) and the direction of the relative wind”. Oncoming relative is wind is of course talking about the direction we are traveling. Its really an overcomplication that makes it sound so much more scary than it actually is, and its pretty much saying, oncoming wind is directly opposite to our direction of travel(velocity vector). The angle between the chordline(direction the nose points for simplicity), and the velocity vector is our angle of attack(on the pitch axis). In my AoA calculation, im just isolating that vertical pitch axis, and finding the angle between our velocity vector, and our lookvector(look vector is the direction our nose is pointing).
Used your lift equation and it works! But I’m afraid that it is not done, because I’ve moved onto the next problem: drag. I am concerned being unable to observe the 100% functionality of the lift as the drag turns out a warden.
Again, I used @Imperiector’s formula, which was obscure to me. At first, I thought it had something to do with liftPower, in which is baked into lift-induced drag. I removed that, and the problem occurs to be more frequent.
The drag force, the parallel of thrust, somewhat goes to tremendously large numbers. It seemed fine in the first 2-3 seconds, but it went the other way around after.
local CD = 0.01 -- Drag coefficient
local S = 2 -- "Any number"
local wingAR = 3 -- ¯\_(ツ)_/¯
local oswald = 0.7 -- "Generally less than 1"
local Q = airDensity * 0.5 * velocity.Magnitude^2 -- Dynamic pressure
function calculateDrag(pressure, CL, AoA)
local CLAoA = CL * AoA
local CD_i = CLAoA^2 / (math.pi * wingAR * oswald) -- Lift-induced drag
local drag = (CD * CD_i) * pressure * S
return drag
end
I would like for more assistance from @Imperiector, as I am unsure if either the formula was wrong, or something else.
Besides, the lift is currently perfect. Thank you for the correction @xPoIarity.
Your velocity is a constant number which is the issue.
For videogame purposes you can ignore all other constants other than velocity and end up with this, a simple model where a plane accelerates until it reaches terminal velocity.
This basically makes the assumption that your plane is a flying sphere with constant area, and assumes the air density is constant. You can ignore @Imperiector realism for this.
Ultimately all it does is it will prevent a plane from infinitely accelerating and allow the plane to deaccelerate.
To make a simple plane model from the above I would add angular velocity to turn the plane with roll that is inversely proportional to speed. (More speed harder to turn)
And an anti gravity forces that scales to body weight to simulate lift once it reaches a certain speed.
I’m certain that I’ve made a drag simulation with a fixed coefficient and it works fine.
I tried using your method, it works, but I can’t seem to adjust the speed limit. I tried putting a * CD, it caused infinite drag power. While being a simple formula, it is less realistic without Li drag.
No, it’s ran in a loop to keep it relative to time. Didn’t write like that.
Update: I don’t know what I’ve done with the modifications. I don’t know which formula to rely on, and now the lift itself is printing out huge values. I don’t know what’s causing this, lift, drag. Could be both. I’m lost right now.
function calculateLift(velocityMag, AoA)
AoA = math.deg(AoA)
local CL = math.clamp(math.sin(math.rad(3 * AoA)), -60, 60)
return 0.5 * velocityMag^2 * CL * liftPower, CL
end
function calculateDrag(velocity, pressure, CL, AoA)
local CLAoA = CL * AoA
local CD_i = CLAoA^2 / (math.pi * wingAR * oswald)
return (CD + CD_i) * pressure * S
end
local cF = pt.CFrame
local velocity = pt.AssemblyLinearVelocity
local velMag = velocity.Magnitude
if velocity.Magnitude == 0 then velMag = 0.001 end -- Prevent nan
local localVelocity = cF:VectorToObjectSpace(velocity)
local AoA = math.atan2(-localVelocity.Y, -localVelocity.Z)
local windex = cF * CFrame.Angles(-AoA, 0, 0) * CFrame.Angles(0, -AoS, 0)
local dir_lift = windex.UpVector
local dir_side = windex.RightVector
local dir_drag = -windex.LookVector
local pressure = airDensity * 0.5 * velMag^2
local lift, CL = calculateLift(velMag, AoA)
local drag = calculateDrag(velocity, pressure, CL, AoA)
pt.Lift.Force = dir_lift * lift
pt.Drag.Force = dir_drag * drag
My sticks collapsed.
Drag force is not opposite to thrust, its actually opposite to velocity(your direction of travel). The reason your lift is outputting huge values is most likely because your drag force is massive. This is most likely because your drag force is turning around, and facing the direction your moving, which means that it will propel you forward as you move, which the calculation would then add in(since we are using velocity^2) which will increase the same drag thats propelling your forward. Its a feedback loop that happens when your drag force isn’t facing the right way, causing your lift to become huge as well, since it incorportates v^2. Here’s my drag equation:
function Physics.calculateDrag(velocity, dragPower, altitude)
if velocity.Magnitude == 0 then return Vector3.zero end -- Dont return NaN drag
-- Drag = 0.5 * velocity^2 * airdensity * dragCoefficient
local dragCoefficient = dragPower * velocity.Magnitude
local airDensity = 1.2 * math.exp(-altitude / 25000) -- Simplified exponential decay
local dragForce = 0.5 * velocity.Magnitude^2 * airDensity * dragCoefficient
return dragForce/1000
end
Similar thing again, its just a simplified version of the realistic drag equation. You’ll see how im just considering our velocity.magnitude twice, once in the drag equation, and once in the coefficient. The coefficient of drag isn’t something thats fully understood in aviation, but its this extra variable thats measured in flight tests. In your simulation, its just a way to apply your drag power tuning variable until it feels right. You can actually use AoA to calculate the drag coefficient, which is slightly more realistic, and i actually did a while ago, but i gave that up for just a tuning variable(it was a bit problematic and messed with the drag direction). Again, our drag equation is derived from the real equation, but simplified. We ignore wing area, replaced with our dragPower tuning variable, increased to account for the drag coefficient(I found 0.001 to be good assuming you multiply it by velocity magnitude). Just dont forget to apply in the direction OPPOSITE TO VELOCITY(AssemblyLinearVelocity).
self.drag.Force = drag * -velocity.Unit -- The Drag force is opposite to Velocity
Also, check your AoA calculation.
Try getting a part to represent the direction of your velocity, and the direction of your nose to see if the AoA output is making sense. Your incorporting two axes (pitch AND yaw axes) into your AoA value, which might ruin things. It could also cause massive lift values if its wrong. Here’s mine, it works properly as far as i know:
-- Oncoming wind is opposite to the direction of the velocity vector
-- The AOA is calculated by getting the angle that the look vector deviates from the velocity vector
if velocity.Magnitude > 0 then
-- Project the velocity vector onto the plane's vertical plane
local projectedVelocity = velocity.Unit - CF.RightVector * velocity.Unit:Dot(CF.RightVector)
-- Calculate the angle between the projected velocity and look vector
local dotProduct = math.clamp(CF.LookVector:Dot(projectedVelocity.Unit), -1, 1)
local cross = CF.LookVector:Cross(projectedVelocity.Unit)
local sign = cross:Dot(CF.RightVector) > 0 and -1 or 1 -- Check if the aoa is pos/neg, if nose is above/below velocity vector
-- Convert to degrees and apply neg or pos, clamp from -90 to 90
AOA = math.clamp(math.deg(math.acos(dotProduct)) * sign, -90, 90)
else AOA = 0 end -- To avoid NaN AoAs
We are isolating the pitch axis from the yaw axis, and measuring the angle between. At the end, we are clamping to 90 and -90 AoA, and checking whether the plane’s look vector is below/above its direction of travel to see if its negative or positive AoA. Positive AoA is when the nose is above the Velocity Vector. Negative AoA is when the nose is below the Velocity vector. This way, our lift force will output NEGATIVE lift when we are pointing the nose below vel vec, and positive lift when we are pointing the nose above.
Also, your calculating a pressure variable which does not make sense. If your looking to incorporate some things @Imperiector is mentioning, make sure to get your basic forces working first so you dont get weird behavior that you cant explain. After that, you can add all the extra behavior you want.
I believe that windex.dir_drag is a modified version of -velocity.Unit that involves AoA.
Checked the AoA again, and it was the issue. After a takeoff, it repeatedly switched from positive to negative, which explained why it looked wobbly up-down before getting nullified.
I switched to your drag formula. It’s printing out huge numbers without the part even moving.
I went back to AoA calculation, which also uses your method, it does the same behavior. I notice that the wobble effect started from minuscule decimals, which gradually scales up and causes the large numbers.
Windex is using the cframe to find the relative airflow from the pitch AoA and Angle of Sideslip so you can apply drag in the opposite direction. Yes its a modified version, but it shouldn’t be causing the problem. If its happening regardless of the method you use to calculate AoA, that means something else is causing the weird AoA. What are you using as your plane? Is it a single mesh, or a rig with many parts? Also, how are you handling gravity? If you can, share a video of the wobble behavior.
I use a frictionless WedgePart, and my jet model with wheels and suspensions installed. Server-sided. This is how I set the constraints up for both models:
Thrust is relative to Attachment, while Drag and Lift to world. AlignOrientation is for testing AoA, and just how airplanes pitch up to lift.
WedgePart
Last time, it works for the first few seconds, where it manages to takeoff, then wobbles and disappear after. The values outputted large numbers. I used @Imperiector’s drag formula which worked for me.
Today, I gave another try with both drag models. Both WedgeParts disintegrated even without thrust. As how I remember Roblox physics is, there’s like a tiny amount of velocity on unanchored parts when the simulation starts.
I tried to print out both drag and lift value to check for large numbers. What’s weird is, there is no large numbers, other than decimals and decimals. It’s last print output when the WedgePart disappears is 0.
There was a Roblox update recently, and that’s when it started to happen even with @Imperiector’s drag formula. This is definitely something to do with their engine.
I cannot share you a clip of it’s wobbly motion, as the WedgePart itself disappears into thin air before doing anything.
Rigged Jet
Jet is pitched upwards 5 degrees.
Not far different, except it doesn’t immediately fling with @Imperiector’s formula.
I’ve tried with both suspensions enabled and disabled, they react the same way.
The worst of all, I did barely any modifications to the code and when I started to clip them, they don’t seem to react anymore. It’s my horrible part of programming when it comes to not knowing the root of an issue.
Latest version of my script:
local pt = script.Parent
local airDensity = 1.2
local liftPower = 100
local CD = 0.01
local S = 2 -- ¯\_(ツ)_/¯
local wingAR = 3
local oswald = 0.7
function calculateLift(velocity: Vector3, AoA)
AoA = math.deg(AoA)
print(AoA)
local CL = math.clamp(math.sin(math.rad(3 * AoA)), -60, 60)
return 0.5 * velocity.Magnitude^2 * CL * liftPower, CL
end
function calculateDrag(velocity: Vector3, pressure, CL, AoA)
local CLAoA = CL * AoA
local CD_i = CLAoA^2 / (3.14 * wingAR * oswald)
return (CD + CD_i) * pressure * S
end
function calculateAOA(velocity, CF)
local AoA
if velocity.Magnitude > 0 then
-- Project the velocity vector onto the plane's vertical plane
local projectedVelocity = velocity.Unit - CF.RightVector * velocity.Unit:Dot(CF.RightVector)
-- Calculate the angle between the projected velocity and look vector
local dotProduct = math.clamp(CF.LookVector:Dot(projectedVelocity.Unit), -1, 1)
local cross = CF.LookVector:Cross(projectedVelocity.Unit)
local sign = cross:Dot(CF.RightVector) > 0 and -1 or 1 -- Check if the aoa is pos/neg, if nose is above/below velocity vector
-- Convert to degrees and apply neg or pos, clamp from -90 to 90
AoA = math.clamp(math.deg(math.acos(dotProduct)) * sign, -90, 90)
else AoA = 0 end -- To avoid NaN AoAs
return math.rad(AoA)
end
game["Run Service"].Heartbeat:Connect(function(dT)
local cF = pt.CFrame
local velocity = pt.AssemblyLinearVelocity
if velocity.Magnitude == 0 then velocity = Vector3.new(0, 0.001, 0) end
local localVelocity = cF:VectorToObjectSpace(velocity)
local AoA = calculateAOA(velocity, cF)--math.atan2(-localVelocity.Y, -localVelocity.Z)
local AoS = math.asin(localVelocity.X / localVelocity.Magnitude)
local windex = cF * CFrame.Angles(-AoA, 0, 0) * CFrame.Angles(0, -AoS, 0)
local dir_lift = windex.UpVector
local dir_side = windex.RightVector
local dir_drag = -windex.LookVector
local pressure = airDensity * 0.5 * velocity.Magnitude^2
local lift, CL = calculateLift(velocity, AoA)
local drag = calculateDrag(localVelocity, pressure, CL, AoA)
pt.Lift.Force = dir_lift * lift
pt.Drag.Force = dir_drag * drag
end)
I am unable to determine what really causes the issue. But if I really have to, I’m saying it’s the Roblox engine itself.
Dont use align orientation. If your using constraints to get your plane to rotate, use angularVelocity. Handle inputs 60 times a second, and set the target angular velocity to be the current input on pitch/yaw:
function Controls.handleControls(flightControl, plane, stats, gun, velocity, AOA, deltaTime)
local rollInput = 0
local pitchInput = 0
local yawInput = 0
local degToRad = math.pi/180
-- Process control inputs
if UIS:IsKeyDown(Enum.KeyCode.LeftShift) then throttle = math.min(throttle + 0.0025, 1) end
if UIS:IsKeyDown(Enum.KeyCode.LeftControl) then throttle = math.max(throttle - 0.0025, 0) end
if UIS:IsKeyDown(Enum.KeyCode.W) then pitchInput = -stats.TurnRate * 0.5 end
if UIS:IsKeyDown(Enum.KeyCode.S) then pitchInput = stats.TurnRate end
if UIS:IsKeyDown(Enum.KeyCode.A) then rollInput = stats.RollRate end
if UIS:IsKeyDown(Enum.KeyCode.D) then rollInput = -stats.RollRate end
if UIS:IsKeyDown(Enum.KeyCode.Q) then yawInput = stats.YawRate end
if UIS:IsKeyDown(Enum.KeyCode.E) then yawInput = -stats.YawRate end
rollInput = rollInput + (yawInput * 1.75) -- Roll when the plane yaws
local angularVelocity = Vector3.new(pitchInput * degToRad, yawInput * degToRad, rollInput * degToRad) -- Calculate base angular vel
flightControl.AngularVelocity = angularVelocity
end
The max torque you set on the AngularVelocity constraint will be how quick the plane responds to rotational input. Align orientation is a weird way to handle it, kind of like setting cframe directly. Also, set thrust relative to WORLD
To mention that I did these server-sided. I thought it had something to do with the wobble behavior. I decided to try it on my client, and that’s when I couldn’t find out.
The jet doesn’t want to get past the speed of lifting off. I adjusted the liftPower, and the top speed is capped at when it tries to takeoff, noticed by a wobbly behavior.
It’s just a copy-pasted script, yet it works differently. This does not make sense.