Technical ramblings

Technical ramblings

Over the past few weeks, we’ve been making some serious adjustments to how Liftoff works under the hood.

Number crunching

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… 😉


  1. Jan Pratcher

    thanks guys keep it up, much love from the diesel guys

  2. Aaron Camus

    Loving the sim, guys. I fly 250’s and smaller self-built quads, but my buddy has a vortex, and I can attest to the closeness in feel and response. This simulator is making me a better pilot, and I’m saving tons on props! Kudos, and keep it going! This could end up being WAY cooler than Tony Hawk’s skate games EVER were.

  3. Michele Sciacca

    very nice idea! I’m a very bad pilot, I’ll probably buy the game to improve without crashing anything 🙂
    Concerning the modelling of the quadcopter physics, I see you’re having some troubles and I think I know why.
    I don’t want to sound arrogant, by no means I think I’m better than you guys 🙂

    I understand that you use drag for angular stabilisation (i. e., a given stick deflection will achieve a constant angular rate after a transient response). My first (and probably dumb) question is why aren’t you using the angularDrag rigid body parameter in Unity? This will decouple linear stability from angular stability.

    In the real quadcopters this stabilisation is actually achieved via the flight controller; did you consider simulating more accurately the physics of the quadcopter alongside with coupling it with a simple flight controller? This would have twofold advantage: enabling a more accurate physical model, easy to tune based on pilot feedbacks, and also it will be possible to customise more the different flying machines, it would be possible to see more in reality the effect of changing the flight controller tuning or the engines/propellers.

    I have some experience in aircraft physics modelling, also did a quadcopter simulator in MatLab some years ago, so if you want some help feel free to ask 🙂

    1. Lugus Tom

      Hi Michele,

      Thanks for your feedback!

      I’m not sure why you think that we use drag for angular stability, though? We’re using a flight controller for this. Your argumentation is exactly why we decided to take this approach.

      The issue we were having with drag is that drag in unity does not take into account the orientation of objects and that the drag characteristics of a drone change depending on whether propellers are spinning or not (and which way the props are pointing in regard to the travel direction).

      Using just one value for “air drag” forced us to make a choice between realistic cornering or realistic falling. We’re working changing the drag on the drone depending on a number of parameters.