As I mentioned in a post a bit ago, I’m back for a “final project” of sorts. I got bored over break and decided I should come back and actually try to make a plane that flies correctly for once.
I’ve just faked the physics this whole time. Not anymore! Thankfully, NASA actually has some useful resources on calculating lift and drag. After a lot of work, I managed to create a good air foil system that utilizes those equations the best I could.
To test it out, I built a very simple aircraft that somewhat resembles an old WWI fighter biplane. I tweaked some numbers a bit, and it worked flawlessly. I’m really surprised by how well the thing flies. For instance, without enough power, I can’t even lift the nose up high enough to bring it to a stall; it just slides over (I forget what that’s called in fancy aeronautic terms).
Is it perfect? Not at all. But I’m happy with the results, so I thought I’d share. I did this project on ROBLOX instead of Unity because I felt the community here was so much better.
I’ll stick around for about another month until my classwork becomes too much. Then I’ll probably disappear again until I have some magical free time again (spring break perhaps?).
Here’s a bad-quality video of the work. I’ll post more as I polish it up:
Video demo:
How the lift and drag coefficients are being calculated:
function AirFoil:GetLiftCoefficient(angleOfAttack)
-- Somewhat matches a standard lift coefficient graph I found online:
local aoa = math.deg(angleOfAttack)
local cl = math.max(0, math.sin(math.rad((aoa + 5) * 4))) * self.LiftCoMultiplier
return cl
end
function AirFoil:GetDragCoefficient(angleOfAttack, cl)
local cd0 = self.DragAtZero
local e = self.DragEfficiency
local ar = self.AspectRatio
return cd0 + (cl * cl) / (PI * ar * e)
end
Really impressive!
One of the things I’d like to do in the near future is update the endorsed models to include better vehicles. (Better in this case would be to show endorsed results for some common searches like “Plane”, “Boat”, etc).
Any chance you’d be interested in sharing this in the endorsed model world? (There’s compensation involved as well )
I was playing with a plane model that used BodyForce’s to apply calculated values to the wings and tail based on the planes velocity (and I was using a free model that I think you made a long time ago but someone else re-uploaded, the script included with it had your name in it).
Is this something like what you’re doing here? Because it feels very much like what I was aiming for, even down to the control scheme (A&D for the rudder, mouse for ailerons and elevators).
Either way, great job! Do you think you might make it public at some point?
The big difference here is I’m using BodyThrust. With BodyForce, it didn’t simulate the parts correctly, but BodyThrust worked great. I literally just swapped out BodyForce for BodyThrust and then used vectorToObjectSpace on the applied force from the prior BodyForce.
I’d totally be down for making this open source once I polish it up more. I’m not a big math guy either, so I’m sure others could make much better improvements on it too.
@Crazyman32 I was actually using these exact NASA articles a few months ago. I never tweaked it enough but here it is. W and S for throttle, UHJK for steering. Green line = thrust, blue = lift, red = drag.
I think my issue was I didn’t simulate the tail as its own wing but im unsure.
I’ve updated the model quite a bit! The best part is that it is now multi-platform! You can fly it on PC, mobile, or console. You can also use a gamepad on PC.
Each platform (PC, mobile, and console) has separate UIs too, but are mostly consistent.
PC: Dynamic UI based on gamepad plugged in or not. If not, user can also switch controls between using the keyboard and mouse, OR just use the keyboard only. Controls are listed.
Mobile: UI is quite small, and allows a little slider for throttle control. Uses device’s accelerometer for maneuvering. No Yaw support yet.
Console: Locked to gamepad controls. UI is larger.
I’ve also updated the camera a considerable amount. It allows for three views: First-Person, Third-Person, and Landing Gear. Still to come: camera shake based on drag & camera rotation controls.
I can’t wait to try it out, but my big problem with using the accelerometer is that it’s not very commute friendly. There often isn’t very much room to move the phone around in, and the train’s acceleration/breaking can mess with things. I was thinking about using one thumb for the tail flaps and the other for wing flaps/throttle.
While in mouse mode, why does the throttle have to be constantly engaged? Why doesn’t it just increment and decrement like in keyboard?
With in mouse mode, I feel it may be useful to have a marker for the neutral position of the stick.
Why do the throttle and yaw bindings change between mouse and keyboard controls?
Yeah, yaw on mobile seems to be tricky. Any reason not to have a virtual joystick on the left for yaw? Then look could be the Roblox default of dragging anywhere on the screen that isn’t a control?
Overall I think you’ve done an excellent job. While I think propeller torque and trim would be cool, I guess not everyone is an airplane nerd.
Just played a bit more on PC and it’s seriously fun. Can you double the size of the terrain? It’d pretty small for a plane test thing. The other thing is that the post-processing effects are a bit too strong.
Just nit-picking but It’d make the test-game a lot more pleasant for me (I think I’m addicted).
Throttle is the same in mouse mode, but there’s a bug where it thinks some keys are pressed down to begin with. I’ll fix that soon.
Having a marker would be nice. I’ll try to see if I can implement something like that without it being in the way.
The key bindings change because I originally developed it only for mouse+keyboard. When I switched to allow for keyboard-only as an option, I wanted WASD controls for it. I can see if I can combine the two into a single binding schema. Didn’t really think about that to begin with, so that’s a good point you make.
Yaw on mobile should be the left-stick; you’re right. I don’t know why I didn’t implement touch-drag rotation instead. I’ll switch to that. This will probably be last on my list though, since it’s really tricky for me to test on mobile since I have Android devices.
I used the default terrain generator plugin to make the terrain and set it to its largest size. I guess I could edit the plugin myself and force a larger size. I don’t feel like hand-crafting anything larger
I decided to look into this for the next version of my plane system, but I can’t figure out two things:
How would I calculate/base the 3 constants used in the drag coefficient
What is the relationship for lift and drag? Does is drag subtracted from the speed before calculating lift, or do you subtract drag from lift directly?
This is basically the only thing holding me back from continuing the system. I would prefer not to have to go back to the original version that was used in your plane kits, and all of my other plane systems.
)
