Does The "Fixed Update" Unit Operate At The Same Frequency On Every Platform?

Many games utilise physics engines to drive the way things movement and react. Using a physics engine can add immersion, eye candy, and, best of all, emergent gameplay, simply can also, if used incorrectly, lead to unrealistic results or game-breaking problems. In this post, I'll explain how to identify and fix common bug seen in games of today.

We will examine and solve these issues as seen in Unity, focusing on the built-in 3D physics engine Nvidia PhysX, merely the core principles tin be practical to whatsoever other platform and physics engine.

Note: You can find a wide selection of 3D models to get you lot started over on Envato Market.

Demo

This demo shows most mistakes mentioned in this article in both a incorrect or cleaved state, and in a fixed country:

Normal Scale

This is a simple scene with a brawl that hits into a stack of barrels. The alternate version Incorrect Scale (10x) shows how the scene changes at 10x scale (run into the scale markings on the floor of the demo). Notice how it appears to be in slow-motility, but this effect is simply caused by the scale of the scene.

Character Controller

This shows a simple side-scroller game working as intended. The "bad" alternative; Rigidbody & Character Controller Together shows the aforementioned game, but with a Rigidbody component attached to the grapheme. Observe how the Rigidbody breaks the behavior of the Graphic symbol Controller.

Objects With Bounciness

Barrels are shot from the side of the scene and are hurled into the air. As they come up crashing down, they bounce off the ground and movement in elementary but majestic ways. The broken version shows the aforementioned scene without bounciness, and it looks so much more boring in comparison.

Non Directly Modifying a Rigidbody'due south Transform

In this scenario, a heavy ball is pushed up a ramp using Rigidbody.AddForce(). In the 2d scenario, instead of using Rigidbody.AddForce() to movement the brawl up the ramp, Transform.position is used. The effect of using Transform.position is that the ball rolls dorsum down, due to the fact that the rigidbody isn't properly taking into account the rigidbody'due south velocity modify, but then the position modification causes the ball to jitter up and downward the ramp.

Common Mistakes

Incorrect Scale

In near games, players would assume that the calibration of the world is relatable to World's scale. They would expect, for instance, an enemy falling from a watch tower to autumn at the same rate you would perceive on Earth. If the enemy falls too slowly or too quickly, it can detract from the immersion—specially if the enemy is human being-sized!

Nvidia PhysX in Unity is set up up to utilise 1 unit per meter. You tin can apply this trait to cheque whether the scale of your objects are correct by simply adding in a Unity primitive cube. The archaic cube is exactly one cubic meter. If yous find, for example, that a oil barrel in your scene is 2x bigger than the the cube, that ways your oil butt is two meters alpine (half dozen.56 feet)!

Fixing the calibration is equally easy as scaling every object in the scene. Simply select all the objects in your scene and utilize the Calibration tool to make them bigger or smaller. If you observe your objects are moving too quickly, make the objects larger. If y'all notice the opposite—that the objects motion too slowly—you should scale the objects downward.

You can scale your objects with more precision past grouping them into 1 null object, and scaling that one object. For instance, setting the scale of the parent object to 1.2 on each centrality volition increment the size of every object inside the object past xx%. You can as well calibration the objects in increments using the calibration tool by holding down Ctrl-LMB (Windows) or Cmd-LMB (Os X).

Using a Rigidbody and a Character Controller Together

I've seen this happen a few times, and it really makes sense how often this occurs. The developer assumes that a Character Controller is necessary to control their avatar, but they want the avatar to exist affected by gravity and other objects in the surround.

The problem is that aCharacter Controller is designed for more than classical controls, similar those typically constitute in a platformer or kickoff person shooter. ARigidbodyis simply a non-deformable object that is afflicted by gravity and other concrete forces (such as other objects colliding with it). These are two very dissever components, with unlike intended uses.

Choose just a Character Controller when y'all want to consummate control over how the player moves. On the other hand, if you want your character to be driven past the physics engine, use a Rigidbody. In adding a Rigidbody to a grapheme, you lot volition probably want to constrain rotation so that the actor doesn't topple over.

Directly Modifying a Rigidbody'southward Transform

Unlike a Character Controller, information technology'south non good practice to set the position or rotation of a rigidbody, or calibration a rigidbody object constantly (for histrion command and such). Instead, you lot should employ the AddForce() and AddTorque() methods plant in the Rigidbody grade. Information technology is okay to direct gear up the position and rotation of a Rigidbody if, for example, you're spawning in the object for the first time, or resetting the scene. In that state of affairs it will be fine, as long as the Rigidbody is not intersecting other objects.

This matters considering, when a rigidbody is moved to an exact position or rotational state, it could pass through an object. The physics engine then has to correct this issue, and most of the fourth dimension the physics engine does not run at the same time Unity's Update() message does. The end upshot is jittery behaviour whenever there's an intersection, and information technology's possible that the rigidbody may pass through objects entirely.

Another bad side upshot that can occur when, say, moving a rigidbody along an axis for player movement is that internally the rigidbody is simulated and then it applies it's position. Updating the position then moves the rigidbody without taking into account the velocity change and such. If the rigidbody is rolling back down a slope, it will exist moving the rigidbody backwards while your position altering code is moving the rigidbody support the slope.

Objects Rolling Forever

Let's say you're developing a golf game. In that location is a problem with how the golf ball does non stop rolling, and somehow manages to continue rolling on forever every bit long as there isn't any kind of pigsty or ditch in its path. The reason why this happens is considering in real life, the brawl would be slowed downwards by the grass it runs over (amid other things), since information technology has to push the tiny grass blades down, the grass essentially is like a constant ramp. This is chosenrolling resistance. Unity cannot simulate this behaviour accurately, so instead bogus stopping forces must exist used.

In Unity the best force to utilise to end an object from rolling forever is "angular drag". Changing the angular elevate on the golf brawl is the way to fix this outcome. The exact value really depends on the behaviour you're looking for, however you may notice that a value of 1.0 angular drag may non even be plenty in some cases.

Objects Without Bounce

Almost every object in the globe bounces later on an touch. Unity'due south internal, default physics fabric has no bounce at all. Pregnant every object will non bounce unless your override the default physics material or apply a physics material to the objects in your scene with a bounce value higher than 0.

I of the best ways on fixing this event is by creating a creating your ain default physics material and assigning information technology in thePhysics Managing director constitute by clicking Edit > Projection Settings > Physics.

Rigidbodies Partially Sinking Into Geometry

Almost physics engines take some kind of parameter dictating how much 2 objects can be interpenetrating or intersecting until they are pushed away from one some other. This parameter is called Min Penetration For Penalisation in Unity. By default this value is 0.01 (meters), pregnant that, by default, objects can be intersecting up to ane centimeter (almost 0.4 inches) before beingness pushed apart.

You should fixMin Penetration For Penaltyto a value where it is barely noticeable that objects are intersecting. Setting the value to something tiny, such as 0.0001, may result in jittery rigidbodies.

How to Prevent Mistakes

Writing Code for Rigidbodies (for Programmers)

If you aren't a programmer, you don't have to worry most the post-obit scenario. When writing code that moves, rotates, or scales rigidbodies, information technology is important to go on this in the FixedUpdate loop. Writing this code in the Update loop volition potentially pb to unstable results, since the Update function may be chosen at 1000 Hz, while the physics engine and the FixedUpdate part are each called at 50 Hz by default.

You can change the frequency on physics steps by changing the parameterFixed Timestep, found inEdit > Project Settings > Fourth dimension. The value determines how much fourth dimension is waited, in seconds, between each physics update or step. Yous tin can work out the frequency in Hertz by dividing 1 by the value (for example, a 0.01 second await ways 1 / 0.01 = 100 Hz). The more than frequent the steps, the more accurate and stable the simulation will be. All the same, setting the frequency higher than the CPU can handle volition outcome in a very unstable simulation. Endeavor to keep the Fixed Update frequency between 30 Hz and 100 Hz.

While working on a destructible brick wall, I ran into an issue caused by Instantiating bricks after a chunk of the wall had been destroyed. I fixed this issue by placing the problematic lawmaking into a Coroutine, and placing the following line earlier Destroying the object:

// Wait a frame yield return nothing; // C#  yield; // UnityScript

In waiting for a frame, it would guarantee that the logic was synced upwardly in Update time, rather than FixedUpdate fourth dimension. This seems to mean that the Destroy office is executed in sync with the Update loop.

Bonus Unity Tip: Don't Use The Standard Assets Physics Materials!

The Physics Materials package, which comes equally part of the Unity Standard Assets, is actually almost completely useless. There are five physics materials independent in the package, and all of them are unrealistic in some manner.

Each material has identical static and dynamic friction. In the real world, objects that are continuing still have slightly more than friction then when they are moving. The Rubber textile's coefficient of friction is ane.0, which is not like to any rubber found in the real earth. And if that doesn't sound silly enough, every material has 0 "bounciness" (excluding the "Bouncy" fabric). This all means that the materials not even a shut representation of their real life counterpart.

It is best to create your own physics materials when necessary. At that place are a lot of websites around that share concrete properties of materials—the important ones beingness dynamic friction, static friction, and restitution or bounce.

Conclusion

Very few physics related problems are actually that difficult to ready. If there is whatever kind of physics-related bug that seems difficult to runway down, try slowing down time to see what'southward going on. If you notice that the issue starts around a certain line of code, you can apply Debug.Interruption to pause the editor and inspect what's going on. Feel gratuitous to annotate here if y'all have whatsoever questions or need assistance.

Did you observe this post useful?

Jesse Stiller

I'1000 an Australian indie game developer currently in the early stages of developing a new game on my own. I seemingly gravitate towards games that have a lot of dynamic move and interaction.