It’s all a simulation!
Physics is at the core of the RoboCo experience. BUT physics in any game is just a simulation with inherent limitations and differences from the real world. Important trade-offs need to be made in terms of performance, fidelity, stability, and player expectations. We have just milliseconds to simulate all of the physics in a given scene per frame. Off the bat, that means that we are restricted in the number of iterations and how small of a time step the physics engine can process before we need to display its solution, limiting fidelity and stability. Too few iterations and too large a time step can lead to pass-through, as rigid bodies may have moved too far to detect any collisions, or joints can become too droopy and springy. Too many iterations can lead to frame rate drops and choppiness.
[Left: Lower iterations and larger time step. Right: Higher iterations and smaller time step.]
Fortunately, many players are somewhat accustomed to some of these trade-offs. We can even lean into it a bit with our art style. Being immersed in a totally photorealistic environment gives the player an expectation for totally realistic animations and physics. With a more cartoony style, more affordance is given. That being said (written), we still want to allow players to build things that function and work as expected as often as possible.
Physics freakout is mostly inevitable. We’ve all seen it. It can make for a great YouTube clip or it can ruin your playthrough of a level. The more constraints or joints in a scene, the more places physics can go awry. That’s why you are more likely to see a physics ragdoll twitching than some crates in an alley inexplicably bouncing.
Robots tend to require a lot of joints, meaning more constraints and thus more places for instabilities to arise. Other compounding factors include high mass ratios between joints and chains of joints such as arms. On top of all that, what a player builds is largely out of our hands.
New and Improved!
With all of this in mind, it becomes very important to have a physics solver that can, in fewer iterations, give a more accurate solution. This is where PhysX 4.1 comes in. We are building RoboCo with Unity and Unity offers built-in integration with PhysX. We have always been a bit disappointed with the droopiness of PhysX joints as this can limit what a player can functionally build. PhysX 4.1 offers a new solver that drastically improves just that.
[Top: Old solver. Bottom: New solver. They are both animated gifs with the same motor settings.]
Updating the version of your game engine mid project is always risky and almost always ill-advised; but, after extensive testing, analysis, and comparison of the old solver to the new, we couldn’t pass up the long wished-for improvements. Updating the engine also required rebalancing of physics settings, mass properties of parts and props, human behaviors, updating shaders for an updated render pipeline, and ensuring stability in the editor and builds.
[Left: Old solver. Right: New solver.]
We can’t guarantee that physics will never freakout or explode or be twitchy, but we are seeing an immense improvement to fidelity. The new solver still has many of the shortcomings that most real-time physics engines include, but players now will have a much higher ceiling to play under. We can more closely meet player expectations, and players can produce more varied and creative builds.