Over the past few weeks, we’ve been making some serious adjustments to how Liftoff works under the hood.
One of the largest changes –something we talked about in the previous blog post– is the physical correctness of the simulator. We looked at different setups of batteries, motors, props and ESCs and tested them against expansive data sheets. It took many hours of tweaking parameters, plotting graphs, looking up part specifications and hunting for mathematical functions that could give us better results. The hard work paid off. We can now say that the whole chain from stick to ESC to RPM to lift is correct. The result of this is a more realistic behavior, especially with regard to the effect of batteries and motors. A 3S battery feels like a 3S, a 4S like a 4S. A whole bunch of parameters is involved, so every drone setup should feel unique in its behavior. Naturally, there is still room for improvement, mostly regarding aerodynamics. This is behavior that we will keep on fine-tuning throughout the development of the game, so please keep sending feedback!
Newton to the rescue
With that out of the way, we had another look at the “floaty” gravity. To investigate issues like this, it’s good practice to assume all of one’s assumptions are incorrect (including this one). Therefore, before altering our own code, we figured we needed a sanity check. What if, we asked ourselves, the constant of gravity in our game engine from the very start produces results that are inconsistent with the gravity of our real Earth? There’s a surprisingly simple way to test this. In your game engine, create an object and… drop it. Create an identical object and write a bit of code that tells it to move downwards with an acceleration of 9.81 m/s. (That’s what happens in real life, for all of you who were asleep when your teacher did the whole Newton-and-the-apple routine). If the two hit the floor at the same time, your game engine can plead not guilty to breaking a fundamental law of nature.
We did a bunch of tests, dropping objects with all sorts of different drag, mass and size parameters. Our conclusion is… *drumroll* that gravity seems to be working as expected. That’s good. It means that the cause of the floaty behavior instead must lie somewhere in the fuzzy realm of aerodynamics. For now, the main issue is that our physics engine only offers us a single “drag” parameter, which means that the drag slowing us down when falling is the same drag that allows us to make controllable turns. We can’t alter it to increase realism in one aspect of the flight simulation without losing it in another. In the future, we’ll be looking at ways to uncouple this behavior.
Up, up and away
In other news, we’ve been investigating remarks of having to move the stick too far before a quad has liftoff. To remedy that, we’ve overhauled the way throttle response is handled by implementing a completely new throttle curve based on CleanFlight, with a configurable mid point and exponent. We’ve also been working on adding a configurable minimum throttle position, below which any throttle given will be considered zero. This ought to help those of you whose controllers never return complete zero, preventing you from arming the quad in-game and can also make for a more pleasant experience when using game controllers.
And another thing
Oh, and we changed the collision model of the drones a bit. They now have supports under the props – as they do in real life. To be perfectly honest, we’re not really sure why that wasn’t the case before… 😉