Simulations are funny creatures. On the one hand, the creation of a realistic simulation involves tracking down a ton of (hidden) variables that have to be approximated to an acceptable degree. On the other hand, it’s also easy to emulate a complex process too ideally, lacking all the microscopic cause-and-effects that make reality into an incalculable chaos.
The much-maligned “stickiness” many Liftoff players experienced when flying their quad head-first into a wall, gate, or tree falls into the latter category. Let’s paint a picture: you’re seconds away from placing a top time on your favorite Liftoff track, only to have one of your props catch on the last gate. You’d expect to be flung off course, crash to the floor, or cut a hole right through that gate, but instead you just kind of … hang there, motionless. In one of the coming updates, you can expect a solution to this odd problem. It’s more than a bit frustrating for pilots, and we’ve wanted to get to the bottom of it for a long time. As is often the case, that proverbial bottom was a bit further down than expected.
Throw things at the wall and see what sticks
Our first approach was a pretty straightforward one. While our simulation of flight behavior is quite advanced and accounts for a great many mechanical, electrical and physical factors, the simulation of physics not directly relevant for flying was not yet very detailed. For instance, when your drone crashes into a concrete wall, Liftoff knows you hit something that was made out of concrete, plays the corresponding sound, damages your props accordingly and shows some appropriate crash effect. However, the game didn’t have an idea about what effect said material should have on the movement of your crashing drone. Evidently, if you take your quad and throw it full force at a wall (let’s say you have money to burn), you’d expect it to bounce off differently, depending on whether that wall was made of wood, concrete, steel or rubber.
This is not what happened in Liftoff. Without access to such physical properties, the collision simulation defaulted to a rather bizarre behavior where any material completed absorbed the energy of incoming projectiles. In non-technical terms: whatever you would throw at that wall, it would come to an instant dead stop. As a developer, that’s a smoking gun: we’re investigating a problem that makes stuff stick to walls and apparently, the default behavior is for things to, well, stick to walls. Making sure our objects had an idea of how to throw drones around was an obvious first step.
Up until this point, Liftoff distinguished some 30 different material types, such as“rough metal”, “tree leaves” and “rubber”. A first step was to define how “bouncy” these materials are. Bounciness is kind of a mixed bag of loosely related physical properties, but it will suffice for our purposes. Incidentally, defining per-material physical properties also allowed us to provide some other features that while not directly addressing the “sticky problem” did increase overall realism. Liftoff can now also account for the friction of a given material, meaning that your quad can skid realistically over polished concrete floors, whereas it will stutter and snag on uneven grass.
We hoped that adding these physical properties would be enough to remedy the issue of drones sticking to walls. It was not. After all, the more astute among you may have figured out that walls absorbing all incoming energy account for stopping drones in their tracks, but doesn’t really explain why they stay put afterwards, instead of plummeting to the floor like a 400 dollar hacky sack. There’s two conclusions to be made here :
- There has to be some kind of force keeping the drone where it is.
- Wait, this thing casually glued against the wall is actually a 20 000 rpm blender.
We’ll tackle both of these in turn.
Actually, don’t use the force
This mysterious power keeping your quad mounted against the scenery turned out to be hiding in plain sight: the quad’s thrust itself. After all, in a simulation, a drone essentially has no notion of the world around it. All your virtual flight controller knows is that it was told to move the drone so and so and it couldn’t really give a prop that there is a wall preventing it from achieving just that. For our virtual drones, there was no meaningful distinction between being vertical in mid-air or vertical against a surface. Regardless of what your propellers are trying to achieve, they could only push you further into the wall.
To fix this, we implemented a system where props provide significantly less thrust once they are in very close proximity to a surface. Simplifying things a little, we could say propellers work by “scooping” air above them. Therefore, if there is little air to be found above a propeller, we’d also expect it to work less well.
This had the desired effect: once stuck parallel to a surface, propellers now provided far less thrust, allowing the drone to fall and break free.
Think outside the box
Once we had fixed the mysterious adhesive force, another problem came to light. Up until this point, from a physics point of view propellers had been defined as squarish box shapes of roughly correct dimensions. This gave us a decent enough idea of when propellers came into contact with other objects and allowed us to toss the drone around a bit and apply some damage. Unfortunately, this approach also had some major downsides, the foremost of which being that it treated propellers as solid objects with right angles and flat surfaces. Under ideal circumstances, you’d even be able to balance a drone on them. However, as many of you are aware, real-life spinning propellers in fact behave more like little tornadoes of finger-eating fury. If something gets in their way, both that something and the propeller itself are going to feel it.
That’s why we decided to get rid of these box shapes and implement something new of our own. (In fact, removing these boxes around the propellers threw the weight distribution of our drones completely out of whack, but the solution to that problem involved weird workarounds and scary mathematical terminology, so I’ll spare you.) In our new system, each propeller is constantly making quick, circular sweeps around its center point to detect collisions. If it encounters an obstacle along the way, now we do not only know with great accuracy that the propeller is hitting something, but we also have access to a variety of other circumstantial factors that can help make the result more lifelike. Hitting something with your propeller should have a more realistic effect that is calculated from variables such as as velocity, glancing angle, throttle and motor power.
Those of you brave or foolhardy enough to play without god mode will notice the damage detection on propellers also takes these new elements into account. Together with the newly added material properties, this should make for some interesting collision behavior, ranging from an almost imperceptible tap against a straw bale to a catastrophic crash into a brick wall.
As always, we’re aware that no plan survives contact with the enemy. We think we’ve made some good progress on how drones should behave when colliding with other objects, but feel free to send us much-needed feedback!