Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
August 24, 2019
arrowPress Releases







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Breaking the Laws of Physics

by Avimaan Syam on 07/16/15 01:40:00 pm   Featured Blogs

5 comments Share on Twitter    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

This post was orginally published on our blog by Creative Director Alex Beachum.

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.
Picture
 
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.
Picture
 
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.

Related Jobs

HB Studios
HB Studios — Lunenburg/Halifax, Nova Scotia, Canada
[08.23.19]

Experienced Software Engineer
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[08.23.19]

Experienced Game Developer
iGotcha Studios
iGotcha Studios — Stockholm, Sweden
[08.22.19]

(Senior) Unity Developer
Wizards of the Coast
Wizards of the Coast — Renton, Washington, United States
[08.21.19]

Lead Client Software Engineer





Loading Comments

loader image