Trajectory prediction with Unity Physics
In some recent prototyping work, we needed to display a prediction for a projectile trajectory in the game. You’ve probably seen something similar in many games before, such as Angry Birds:
Our prototype game was in Unity, and the projectile was set up using Unity’s physics engine. We had several requirements for the prediction:
- Immediate. Player input can change from frame to frame, and the prediction needs to stay in sync with it.
- Accurate. The time of flight could be several seconds, and any small error will accumulate to product significantly incorrect results.
- Simulates drag. We’re using drag on our rigidbody, which many solutions do not account for.
I assumed this sort of problem came up often and searched online to see what popular implementations were out there. They generally fell into three groups:
- Accurate, but slow. These solutions introduce an invisible projectile clone into the world and launch it along the flight path, recording its motion over time. As there’s no way to step the Unity physics simulation along yourself, you have to wait for this prediction in real time. This means that a three-second flight takes three seconds to fully predict. This is far too slow — the prediction would constantly lag behind the player’s changing inputs.
- Doesn’t include drag. There are some good, accurate solutions, but most will specifically rule out drag.
- Inaccurate. Some combination of incorrect equations, assumptions, and approximations meant that with longer flight times and more drag (or different gravity) the prediction would be wrong.
Perhaps the perfect solution for us is out there, but I hadn’t found it. By combining existing solutions and running some tests, I came up with my own implementation, which is presented below.
This function plots the trajectory of a rigidbody under the effect of Unity’s physics by simulating some FixedUpdate iterations and returning the positions of the projectile at each iteration. It uses the global Physics2D.gravity setting, and takes into account rigidbody drag and gravityScale. Note that the mass of the rigidbody is irrelevant.
float timestep = Time.fixedDeltaTime / Physics2D.velocityIterations;The code attempts to produce the same results as running the normal Unity physics iterations. To do this, it must also run as an iterative solution. A common error here is to assume that one iteration is run every FixedUpdate(). Instead, the number of iterations to be performed is accessible and tweakable — it’s Physics2D.velocityIterations. This helps us compute the timestep.
Vector2 gravityAccel = Physics2D.gravity * rigidbody.gravityScale * timestep * timestep;We take into account the rigidbody’s gravityScale property when computing the effect of gravity. We found that we wanted a different amount of gravity and drag on each object, so this per-body setting was really helpful.
float drag = 1f - timestep * rigidbody.drag;Drag acts as a reduction on moveStep in each iteration. We can compute it upfront and then apply it to each step of the iteration, producing a cumulative effect.
for (int i = 0; i < steps; ++i)
{
moveStep += gravityAccel;
moveStep *= drag;
pos += moveStep;
results[i] = pos;
}Finally, the main loop. Each iteration, you’ll move due to gravity, reduce the movement due to drag, and then accumulate and store the new position in the results.
This solution worked well for us. While not exhaustively tested, we used it for projectiles that had lots of different velocities and drags, and it proved accurate each time, even after 4–5 seconds of flight.
Drawbacks
There’s a lot of computation involved for long trajectories. With default settings, you have to run the loop 400 times for each second of flight you want to predict. We only have one projectile to predict in our prototype, so we’re just running one prediction, which doesn’t cost very much. If you used this to predict lots of projectiles for lots of different launchers in a large scale game, perhaps this would begin to be a problem for you.
Also, it’s only simulating the trajectory, and not actually running the physics engine or simulating anything else in the game. This means it doesn’t predict collisions or collision resolution. If you render this path as-is, it’ll just clip through walls or other obstacles in the world, which obviously isn’t actually what will happen when the projectile is launched.
These drawbacks weren’t a problem for our prototype, so it turned out to be pretty useful code. We share this now in the hope that someone else out there is faced with the same requirements and finds it useful too.
Possible Future Upgrades
I have some ideas around the drawbacks of this method. This is the main area for improvement, as the actual functionality is fine.
For performance, no profiling or optimisation work has been performed. I’ve just laid things out in the way that made sense to me. It’s hard to guess at optimisations, but perhaps a little profiling would reveal some simple speedups. The bigger step would be to push this code out to a native dll and get down to nitty-gritty c++ optimisation — perhaps with SIMD instructions. You can’t parallelise the steps (each iteration of the loop depends on the result of the previous) but you could parallelise multiple projectile predictions — e.g. if you have many projectiles, run 4 or 8 predictions in parallel.
The other big upgrade is around prediction. For some games a true prediction would be really valuable — for example, visualising the outcome of collisions and reactions in a pool table game. You’d want to see the predicted path of the ball, even after several bounces. This isn’t going to happen with any simple model if you have any in-depth physics properties. You’d need a big shift in your approach — to run the physics engine yourself. I’d find an appropriate existing physics engine and build it into the game/Unity, which is a shame as it’s duplicating the work that Unity’s already done. But after doing that, you’d have control over the physics simulation and how you update it.
You’d try for a setup where you’d be able to clone the existing simulation and run some update ticks — to, essentially, look into the future — you’ll be tracking the future state of the simulation, assuming no inputs change. This would have to be a separate simulation, as you wouldn’t want the actual state of the pool table to change — just to compute the predicted future state. This will be even more expensive that just running the basic prediction code we had above — it’s the full physics simulation.
Originally published at tech.spaceapegames.com on July 5, 2016.
