Breaking the Laws of Physics

So we finally tried updating the Outer Wilds project to Unity 5 this week! After several thrilling hours of tweaking the entire code base to work with the new (admittedly much-improved) Unity API, the last compile error finally vanished and I eagerly pressed the play button.

This is what I saw.

Those who have played Outer Wilds before know that the game begins with the player character looking up at the sky. This is technically a screenshot of that scene, albeit with a few notable discrepancies. Let's ignore all of the weird graphical artifacts for a moment (those are to be expected when upgrading a project) and focus on the fact that the player character has fallen through the ground and is well on her way to the planet's core. If you haven't played Outer Wilds, I should note that this is not how the game typically starts.

A cursory glance at the error output window revealed the source of the issue.

The console contained 999+ identical errors reading "Non-convex MeshCollider with non-kinematic Rigidbody is no longer supported in Unity 5". Non-convex (or concave) refers to geometry featuring negative topology (valleys, caves, tunnels, etc), and non-kinematic rigidbodies are objects that can be moved by physical forces. This error essentially means that dynamic physics objects can no longer have negatively-curved geometry in Unity 5.

In most games this isn't a problem. The most common use for convex colliders is level/terrain geometry, which by definition is usually static. Objects that need to be simulated with physics tend to be simple enough that their shapes can be approximated by one or more convex colliders.

In Outer Wilds, literally everything in the game is moving at very high speeds due to real-time physical forces. Each planet is a non-kinematic rigidbody that is actually rotating about its axis as it zooms around the sun. Every planet also features a  terrain that relies on a non-convex mesh collider to prevent smaller physical objects (like the player) from falling through it. Likewise, your ship is a dynamic rigidbody that needs a non-convex collider so that the player can walk around inside the cabin while it's in-flight (fun fact: we have to apply a counter-force to the ship at its point of contact with the player, otherwise the player's weight would cause it to spin ever so slightly).

A quick google search revealed that the ability to marry non-convex mesh colliders with non-kinematic rigidbodies was discontinued by the physics engine itself. Unity 5 uses the latest version of Nvidia PhysX, which apparently no longer supports that feature (probably for performance reasons). In short, it's not something that's going to be fixed anytime soon.

That leaves us with a few options:

1. Replace every non-convex mesh collider in the game with a bunch of convex mesh colliders. This is almost definitely a terrible idea (imagine trying to create a tunnel out of convex shapes).
2. Secretly make every planet static...it only looks like they're moving. This is problematic because we'd lose all of the cool side-effects of actually simulating planetary motion (try jumping straight up on the moon and notice how you drift across the surface depending on your distance from the equator). Theoretically you wouldn't notice a difference if we correctly simulated Coriolis forces, but that is a massive "if".
3. Make every planet a kinematic rigidbody (instead of non-kinematic). Kinematic rigidbodies can still be moved manually, but they are not affected by forces. We'd have to write our own physics simulation to achieve planetary motion and crazier stuff like the islands on Giant's Deep. We'd also need to choose an integration method that closely approximates the one used by PhysX (the internet says it's probably this one: https://en.wikipedia.org/wiki/Semi-implicit_Euler_method).
4. Keep using Unity 4.
   

We're still weighing these options against each other, but right now we're leaning towards either 3 or 4. It just goes to show that when you make a game that blatantly ignores how its game engine is intended to be used, these types of problems simply come with the territory.

Then again, I suppose we wouldn't want it any other way.

--Alex