What it means to hand an object to the physics solver: the Rigidbody, the four ForceModes and the numbers they produce, why physics runs on its own clock, and why writing transform.position sends objects through walls.
Subject: Unity Game Engine · 61 slides · code lesson
Open the interactive version of this deck · Homework for this lesson
Title
Unity - Lesson 3
Handing an object to the solver - and then not fighting it.
Objectives
This was the lowest score in the diagnostic: 0 out of 3, with an 'I don't know' on FixedUpdate. Nothing here is hard, but all of it is invisible until someone shows you the numbers.
FixedUpdate and input in Updatetransform.position will send an object through a wallWarm-up
From memory, before the deck says anything.
Discussion prompt
A cube with a Box Collider sits in the air and does not fall. Write down every explanation you can think of, then say which one you would check first.
Hint: One of your explanations is probably about gravity being off. What would have to exist for gravity to be off?
Answer:
The answer is almost always: there is no Rigidbody. Not 'gravity is disabled' - there is nothing there to disable it on.
Use Gravity is a checkbox on the Rigidbody. No Rigidbody, no checkbox, no simulation, no falling. The Collider is a shape, and a shape does not fall.
Section
Part 1
Concept
Adding a Rigidbody says: from now on, the physics solver decides where this object is. Gravity, forces, collisions and momentum all become its business rather than yours.
Rigidbody — The component that puts an object into the physics simulation. It owns the object's position and rotation from the moment it is added.
That is the whole idea, and every rule in this lesson follows from it. Once the solver owns the position, your job is to ask rather than to set.
Intuition
Adding a Rigidbody is like handing the wheel to a driving instructor. From then on, grabbing the wheel yourself does not help - you fight each other, and the car goes somewhere neither of you intended.
The instructor is very good. Tell them where to go - 'accelerate', 'turn' - and they handle the road, the other cars, and stopping when something is in the way.
Grabbing the wheel is transform.position = .... Telling them where to go is AddForce, setting the velocity, or MovePosition. Both move the car. Only one of them notices the wall.
Concept
A Collider is a shape used for contact tests. A Rigidbody is being simulated. Every combination of the two is a real, useful object.
| Collider | Rigidbody | what you get | typical use |
|---|---|---|---|
| yes | no | a solid shape that never moves | walls, floors, scenery |
| yes | yes | falls, is pushed, is stopped | crates, balls, ragdolls |
| no | yes | falls through everything | almost always a mistake |
| no | no | a position with a mesh | decorations, empty parents |
The first row is most of a level. Realising that most objects want a Collider and no Rigidbody is what stops the habit of adding one to everything.
Prediction
A wall made of a cube with a Box Collider, holding up a level. Someone adds a Rigidbody to it 'so it can collide properly'.
Predict first
What happens when you press Play?
Correct: The wall falls, and probably tips over.
Why: A Rigidbody does not mean 'collides better' - it means 'is simulated', and a simulated object with nothing under it falls. Static scenery is solid because of its Collider, and it stays put precisely because it has no Rigidbody.
Sorting
Sort these game objects by whether they need one.
Sort into buckets
Which need a Rigidbody?
Worked example
Five fields on the component decide almost everything. Here they are set from code so the names are visible.
Rigidbody body = GetComponent<Rigidbody>();
body.mass = 1f; // kilograms; matters for Force and Impulse
body.useGravity = true; // the checkbox people look for on the Collider
body.isKinematic = false; // true = "I drive, physics does not push me"
body.collisionDetectionMode = CollisionDetectionMode.ContinuousDynamic;| field | means | when to change it |
|---|---|---|
mass | how hard it is to accelerate | relative sizes matter; absolute values rarely do |
useGravity | is it pulled down | off for projectiles with their own arc, top-down games |
isKinematic | physics does not move it, but it is still a physics object | moving platforms, lifts, scripted doors |
collisionDetectionMode | discrete check vs swept check | anything fast - the fix for tunnelling |
linearDamping / drag | how quickly it slows on its own | to stop things sliding forever |
Explain it to yourself
Discussion prompt
A kinematic Rigidbody is not pushed by forces and ignores gravity. So why add one at all - why not just have no Rigidbody?
Hint: Think about a lift carrying a crate, and about what the crate needs to know.
Answer:
Because it is still in the simulation. Other bodies collide with it correctly, it can push them, and it fires trigger callbacks - all of which a plain static collider does far less well when it moves.
A moving platform with no Rigidbody is a static collider that teleports every frame: things standing on it fall through, and the solver has to rebuild its static structures constantly. A kinematic Rigidbody moved with MovePosition is the supported way to say 'this moves, but I decide how'.
Section
Part 2
Concept
AddForce does not move anything. It adds to the forces acting on the body this physics step; the solver then works out the resulting velocity and position.
void FixedUpdate()
{
body.AddForce(Vector3.forward * 10f, ForceMode.Force);
}| you call | the solver does |
|---|---|
AddForce(f, Force) | acceleration = f / mass, applied for this 0.02s step |
| nothing else | integrates velocity, then position |
| nothing else | checks what is in the way, resolves contacts |
| nothing else | writes the new transform, once, at the end |
Unity Scripting API - Rigidbody.AddForce Rigidbody.AddForce
Concept
The four ForceModes are not four strengths. They are the four answers to two independent yes/no questions.
| ForceMode | spread over time? | divided by mass? | think of it as |
|---|---|---|---|
Force | yes | yes | an engine pushing |
Acceleration | yes | no | gravity - same for everything |
Impulse | no | yes | a hammer blow |
VelocityChange | no | no | 'be going this fast, now' |
Unity Scripting API - ForceMode ForceMode
Prediction
Mass 1, fixed timestep 0.02s, AddForce(Vector3.forward * 10, ForceMode.Force) every FixedUpdate.
Predict first
What is the sphere's speed after the FIRST physics step?
Correct: 0.2 m/s.
Why: Force means 'this many newtons, applied continuously'. Acceleration is force over mass: 10 / 1 = 10 m/s squared. One step is 0.02s, so the speed gained is 10 x 0.02 = 0.2 m/s. It keeps gaining 0.2 every step for as long as you keep pushing.
Worked example
This is the lab's output, with four spheres pushed by 10 units in each of the four modes.
void FixedUpdate()
{
if (continuous) // Force, Acceleration
body.AddForce(Vector3.forward * pushStrength, mode);
else if (!fired) // Impulse, VelocityChange
{
fired = true;
body.AddForce(Vector3.forward * pushStrength, mode);
}
}| fixed step | Force | Acceleration | Impulse | VelocityChange |
|---|---|---|---|---|
| 1 | 0.20 | 0.20 | 10.00 | 10.00 |
| 2 | 0.40 | 0.40 | 10.00 | 10.00 |
| 3 | 0.60 | 0.60 | 10.00 | 10.00 |
| 4 | 0.80 | 0.80 | 10.00 | 10.00 |
| 5 | 1.00 | 1.00 | 10.00 | 10.00 |
| 6 | 1.20 | 1.20 | 10.00 | 10.00 |
Read the columns in pairs
Why: Force and Acceleration climb because they are applied every step. Impulse and VelocityChange jump once and then flatten, because they were applied once.
With mass 1 the left pair and the right pair look identical. The next slide is where they separate.
Invariant
Same four spheres, same push of 10, but mass = 2. Step through and find the two columns that did not change.
Step through it
Two of these four are unchanged by doubling the mass. Which, and what does that tell you?
Acceleration and VelocityChange ignore mass. They describe the result you want. Force and Impulse describe the push you are making, and a heavier object does less with the same push - which is Newton, not Unity.
Discrimination
For each requirement, choose which of the two families it belongs to. Do not work out numbers.
Sort into buckets
Continuous push, or one-shot?
Trap
Everything else is multiplied by delta time, so a force should be too.
void FixedUpdate()
{
body.AddForce(direction * speed * Time.fixedDeltaTime, ForceMode.Force);
}The result is a push 50 times weaker than intended, so you compensate by raising speed to 500, and now nothing in the Inspector means anything.
ForceMode.Force and ForceMode.Acceleration are already per-second quantities. The solver multiplies by the timestep for you.
void FixedUpdate()
{
body.AddForce(direction * speed, ForceMode.Force); // no deltaTime
}| what you are writing | multiply by deltaTime? |
|---|---|
AddForce with Force or Acceleration | no - the solver does it |
AddForce with Impulse or VelocityChange | no - they are instantaneous by definition |
transform.position += in Update | yes - always |
transform.Rotate in Update | yes - always |
Fill the middle
A jump: one upward push, only when grounded, in the right callback.
Fill in the blanks
void Update()
FixedUpdate
void Impulse()
___});
}
}
Why: Input is read in Update because a key press can happen on any frame and would be missed between physics steps; the force is applied in FixedUpdate because that is where the solver is listening. Impulse is the one-shot that respects mass, which is what you want if a heavy character should not leap as high; VelocityChange is defensible when every character should jump identically regardless of mass.
Section
Part 3
Concept
Figure (svg): Two timelines: an irregular Update timeline above a perfectly regular FixedUpdate timeline
Update is called once per rendered frame - as often as the machine manages, and never the same number of times twice. FixedUpdate is called on the physics clock: a fixed slice of simulated time, by default 0.02 seconds, 50 times per simulated second.
Unity Manual - Order of execution for event functions Order of execution
Worked example
The lab counts each callback over a fixed window and prints the rates.
void Update() { updateCalls++; }
void FixedUpdate() { fixedCalls++; }
// after 2 seconds:
// Update ran 287 times (144 per second)
// FixedUpdate ran 100 times (50 per second)| machine | Update per second | FixedUpdate per second | physics stays correct? |
|---|---|---|---|
| gaming PC | 144 | 50 | yes |
| laptop | 60 | 50 | yes |
| struggling build | 20 | 50 | yes - 2-3 steps per frame |
| paused (timeScale 0) | still runs | 0 | n/a - the simulation is stopped |
The third row is the one that matters. At 20 fps, FixedUpdate runs two or three times per frame - so code in Update that pushes 'once per frame' pushes at a third of the rate it did at 60 fps.
Prediction
A developer puts AddForce(forward * 10, ForceMode.Force) in Update instead of FixedUpdate. It feels right on their machine.
Predict first
What does a player on a 30 fps machine experience?
Correct: Roughly half the acceleration - the object accelerates faster on faster machines.
Why: The force is applied once per Update call, so half the frames means half the pushes. This is the bug that gets reported as 'the game is too hard on my laptop', is not reproducible on the developer's machine, and is invisible in code review unless you know to look at which callback it sits in.
Trap
Everything else is in Update, so this is too.
void Update()
{
if (Input.GetKey(KeyCode.W))
body.AddForce(transform.forward * speed, ForceMode.Force);
}| frame rate | pushes per second | resulting speed |
|---|---|---|
| 144 fps | 144 | fast |
| 60 fps | 60 | the tuned speed |
| 30 fps | 30 | sluggish |
Read input where input happens; apply force where the solver is listening. The flag is the bridge.
bool thrusting;
void Update() // every frame: never miss a key
{
thrusting = Input.GetKey(KeyCode.W);
}
void FixedUpdate() // every physics step: exactly 50 a second
{
if (thrusting)
body.AddForce(transform.forward * speed, ForceMode.Force);
}| read in Update | act in FixedUpdate |
|---|---|
Input.GetKeyDown (one frame only) | set a bool, clear it after acting |
Input.GetKey (held) | read the bool each step |
| mouse position, aim direction | apply torque or rotate the body |
Error analysis
Three lines, one of which behaves differently on different machines.
Annotate
Inside FixedUpdate, Time.deltaTime actually returns fixedDeltaTime in current Unity versions - but writing it that way still reads as a mistake and breaks the moment the code is moved. Use the clock that matches the callback.
Comparison
Complete it from what you have seen.
Comparison matrix
| Called | Use which delta | What goes here | |
|---|---|---|---|
| Update | once per frame | Time.deltaTime | input, timers, non-physics motion |
| FixedUpdate | 50 times a second | Time.fixedDeltaTime | forces, velocity, MovePosition |
| LateUpdate | after every Update | Time.deltaTime | camera follow |
Socratic
Discussion prompt
Unity could simulate physics once per frame with whatever time has passed. Why is a fixed step worth the complexity of a second clock?
Answer:
Because a simulation with a varying step gives different answers on different machines - stacked boxes settle differently, a jump reaches a different height, a replay diverges. Fixed steps make the simulation deterministic given the same inputs.
It also keeps the solver stable: very large steps make springs and stacks explode, and the fixed step puts a ceiling on how large a step can be, no matter how badly the frame rate drops.
Section
Part 4
Concept
Figure (svg): Two spheres approaching a thin wall: one teleporting past it in discrete jumps, one stopped at it
Setting the position does not move the object through anywhere. It puts it somewhere new. Nothing is swept, nothing is tested, and no contact is generated.
At 15 m/s a 60 fps game moves an object 0.25 units per frame. If the wall is 0.2 thick, then on one frame the object is in front of it and on the next it is behind it - and no collision ever existed.
Unity Scripting API - Rigidbody.MovePosition Rigidbody.MovePosition
Prediction
Two spheres, both with Rigidbodies, both at 15 m/s toward the same 0.2-thick wall. Sphere A moves with transform.position +=; sphere B has its velocity set each FixedUpdate.
Predict first
Where does each end up?
Correct: A passes through with zero collision callbacks; B stops at the wall.
Why: A is not moving fast enough to 'break' physics - it never asked physics anything. B hands the movement to the solver, which sweeps the shape between steps, finds the wall and stops there. Same speed, same wall, same frame rate: the only difference is who computed the move.
Worked example
One script, one enum, two behaviours. This is the whole experiment.
void Update() // style A: teleport
{
if (style != MoveStyle.TeleportByTransform) return;
transform.position += Vector3.forward * (speed * Time.deltaTime);
}
void FixedUpdate() // style B: ask the solver
{
if (style == MoveStyle.VelocityByPhysics)
PhysicsCompat.SetVelocity(body, Vector3.forward * speed);
}| sphere | how it moved | final z | collision callbacks |
|---|---|---|---|
| A | transform.position += | 8.50 - past the wall | 0 |
| B | velocity, solver moves it | 3.40 - at the wall | 1 |
Both spheres have ContinuousDynamic collision detection
Why: That is deliberate: A still goes through. The setting cannot help a move the solver was never told about.
Concept
Which one you use depends on what kind of body it is - and there is exactly one right answer for each.
| the object is | move it with | why |
|---|---|---|
| dynamic (physics drives it) | AddForce, or set the velocity | the solver integrates it and handles contacts |
| kinematic (you drive it) | MovePosition / MoveRotation in FixedUpdate | swept, so riders and contacts behave |
| no Rigidbody at all | transform.position in Update | there is no solver to bypass - this is correct here |
The third row is worth saying out loud: transform.position is not forbidden. It is the right tool for objects with no Rigidbody, which is most of a UI, most scenery, and every camera.
Discrimination
Sort each by the correct way to move it.
Sort into buckets
How should each of these be moved?
Trap
The object is a physics object, so surely physics keeps track of wherever I put it.
void Update()
{
// a dynamic Rigidbody, moved by hand
transform.position += input * speed * Time.deltaTime;
}Move it the way its body type expects. For a dynamic body that is a velocity or a force; for a kinematic one, MovePosition.
void FixedUpdate()
{
// dynamic: hand the intent to the solver
PhysicsCompat.SetVelocity(body, input * speed);
// kinematic alternative: swept move, still collision-aware for riders
// body.MovePosition(body.position + input * speed * Time.fixedDeltaTime);
}| symptom | what it usually means |
|---|---|
| passes through walls at speed | the transform is being written |
| jitters against a wall | transform writes fighting the solver each step |
| riders fall off a platform | the platform teleports instead of sweeping |
| stops dead, then lurches | velocity was never part of the movement |
Scale up
Sphere B is moved correctly, with Discrete collision detection. Step the speed up and watch when even the correct method fails.
Step through it
At what point does a correctly-moved body start tunnelling, and what fixes it?
So there are two separate causes of things going through walls: bypassing the solver (lesson's main point, unfixable by any setting) and sampling too coarsely (fixed by Continuous detection, or a smaller fixed timestep).
Section
Build
Concept
A physics bench: four spheres printing their own velocity trace, two spheres racing the same wall by different means, and a counter proving the two clocks are different.
Files: unity-labs/Assets/NaruhodoLabs/Lesson03_Physics/.
Step zero
Discussion prompt
What is the smallest scene that proves writing transform.position skips collision detection? Name what must be true of the wall and of the speed, and why.
Hint: How far does the object move between two checks, compared with how thick the wall is?
Answer:
That last one is the difference between a demo and an experiment.
Worked example
Four spheres, one per mode, all pushed by 10, all mass 1, gravity off so the Z numbers stay clean.
public class ForceLab : MonoBehaviour
{
public float pushStrength = 10f;
public ForceMode mode = ForceMode.Force;
Rigidbody body;
void Awake() { body = GetComponent<Rigidbody>(); }
void FixedUpdate()
{
body.AddForce(Vector3.forward * pushStrength, mode);
}
}Cache the Rigidbody in Awake, line 7
Why: GetComponent every physics step would be 50 lookups a second per object, for a value that never changes. Lesson 5 measures the cost.
| Inspector setting | value | why |
|---|---|---|
| Mass | 1 | makes the arithmetic checkable by hand |
| Use Gravity | off | keeps the trace to one axis |
| Push Strength | 10 | 0.20 per step under Force - a round number |
| Mode | one per sphere | the whole comparison |
Hypothesis
Mass 2 this time, push 10, six steps, ForceMode.Impulse.
Predict first
What speed will the sphere be doing after step 6?
Correct: 5 m/s.
Why: Impulse fires once and is divided by mass: 10 / 2 = 5 m/s, and nothing after step 1 changes it because the push is not repeated. Getting this right means the two questions - spread over time, divided by mass - have become a tool rather than a table you remember.
Worked example
A thin wall and two spheres. Watch the Console, not just the Game view.
// the judgement the lab makes after 1.5 seconds
bool pastWall = transform.position.z > wallZ + 0.3f;
LabLog.Check(L, pastWall && collisionCount == 0,
"the teleported sphere passed through and fired 0 collision callbacks");| Inspector setting | sphere A | sphere B |
|---|---|---|
| Style | TeleportByTransform | VelocityByPhysics |
| Speed | 15 | 15 |
| Rigidbody | yes, gravity off | yes, gravity off |
| Collision Detection | ContinuousDynamic | ContinuousDynamic |
| result | z = 8.5, 0 callbacks | z = 3.4, 1 callback |
Identical in every row but the first. That is what makes it an experiment rather than a demonstration.
Real world
Discussion prompt
A player reports that their character sometimes falls through the floor when running down a slope, but only on their machine. You have not been able to reproduce it. What do you check, in order?
Answer:
Note that all four are the same root cause seen from different angles: the distance travelled between two collision tests got bigger than the thing being tested against.
Explain it
Discussion prompt
Explain to a teammate why their bullet goes through walls, without using the words 'tunnelling' or 'sweep'.
Answer:
Model answer: 'Your bullet is being put in a new place each frame rather than being moved there, so nothing ever checks what was in between.'
'At its speed, one of those jumps starts in front of the wall and ends behind it. Give the bullet a velocity and let physics carry it, and the wall gets found.'
Concept
Six experiments, each under a minute, from the lab's SETUP.md.
| change | what happens |
|---|---|
| Move AddForce into Update and cap the frame rate to 20 | the same code produces a different speed |
| Delete the Rigidbody from a force sphere | GetComponent<Rigidbody>() is null and the next line throws |
| Give the wall a Rigidbody | the wall falls over |
| Tick Is Kinematic on sphere B | it drives through the wall - kinematic bodies are not stopped by static geometry |
| Make the wall 2 thick and re-run sphere A | it is stopped - which is how this bug hides in a prototype |
| Set sphere B to Discrete and speed 60 | even the correct method tunnels |
Notation
The lab prints one line per fixed step. Every field on it is worth being able to read at a glance.
Annotate
Matching
Four physics symptoms you will meet. Each has one usual cause.
Match the pairs
Match the symptom to what is almost always behind it.
Why: Three of these four are the same root cause wearing different clothes: something other than the solver is deciding where the object is. Being able to go from symptom to cause without opening the code is most of what physics debugging in Unity looks like.
Ranking
Put the events of a single FixedUpdate step in the order Unity performs them.
Put in order
Earliest first.
Why: Your code runs FIRST in the step, before anything is simulated - which is why AddForce is a request for what is about to happen rather than a report of what did. The callbacks arrive at the end, so by the time OnCollisionEnter runs the positions have already been resolved and the bodies are no longer overlapping.
Missing information
Discussion prompt
A designer says: 'make the crate feel heavier'. Before touching anything, what do you need to know? Name at least three things, and say which Inspector field each would point you at.
Hint: 'Heavier' can mean four different things that need four different fields.
Answer:
mass. A bigger mass means the same Force produces less acceleration.linearDamping (Drag). Mass alone will not stop it sliding forever.mass, relative to the player's mass. Only the ratio matters.The fourth line is the general lesson: physics values are meaningless in isolation. A mass of 500 means nothing until you know what it is standing next to.
Two truths and a lie
One statement is false. Rule it out.
Eliminate the wrong options
Which claim about Rigidbodies is false?
Survives elimination: B
Why: Two static colliders never report a collision and never stop each other - the engine does not even test that pair, which is a deliberate performance decision. Lesson 8 turns this into a full matrix, and it is the row that costs people the most time.
Pattern
Four questions, asked in this order, decide the correct movement code every time.
transform.position in Update, with Time.deltaTime. Done.MovePosition / MoveRotation in FixedUpdate.AddForce for a push, or set the velocity for direct control. In FixedUpdate.And one rule that spans all four: read input in Update, act in FixedUpdate. A key press that happens between two physics steps is missed if you only look on the physics clock.
Check
Answer before you click.
Check your understanding
What does adding a Rigidbody to a GameObject actually change?
Answer: B
Why: A Rigidbody puts the object into the simulation. From then on the solver decides where it is - which is why you ask it to move (forces, velocity, MovePosition) rather than writing the transform yourself.
Check
The callback question the diagnostic left blank.
Check your understanding
Why should AddForce be called from FixedUpdate rather than Update?
Answer: B
Why: The physics clock is fixed at 50 steps a second regardless of frame rate. A force applied in Update lands once per frame, which is a different number of times on every machine, so the resulting speed depends on the player's hardware.
Elimination
A crate with a dynamic Rigidbody jitters violently when the player pushes it against a wall.
Eliminate the wrong options
Which is the most likely cause?
Survives elimination: A
Why: Jitter is the signature of two authorities writing the same position: your code puts the crate inside the wall, the solver pushes it out, and next frame your code puts it back. Passing through is the signature of bypassing the solver at speed; jittering is the signature of fighting it at close range.
Check
The last one.
Check your understanding
A sphere with a Rigidbody is moved by transform.position += forward * 15f * Time.deltaTime in Update. It passes through a thin wall. What is the fix?
Answer: C
Why: Writing the position bypasses collision detection entirely: the object is placed at a new location and nothing checks the path. Handing the movement to the solver is what makes the wall exist as far as this object is concerned.
Estimation
A bullet travels at 100 m/s. The fixed timestep is 0.02s.
Predict first
How far does it move between two physics steps?
Correct: 2 metres.
Why: 100 x 0.02 = 2 metres per step. Any wall thinner than 2 metres can be skipped by a discrete check, which is why fast projectiles are usually done with a raycast along the path rather than by moving a collider at all - and why 'my bullets go through walls' is the single most common physics question a beginner asks.
Concept
Lesson 8 is the other half of this one: you now know what makes an object physical, and lesson 8 is about which pairs of physical objects actually report contact.
| you now have | what it enables |
|---|---|
| Rigidbody as 'the solver owns it' | predicting whether something will move |
| the four ForceModes | jumps, thrust, hits and recoil that feel right |
| the two clocks | movement that behaves the same on every machine |
| the tunnelling model | diagnosing pass-through bugs from a description |
Analogy
The two-clock split exists outside games too.
Match the pairs
Match each Unity idea to its cousin elsewhere.
Why: The third pairing is the one to keep: writing the transform behind the solver is exactly editing the file under a running database, and the failure mode is the same - it appears to work, and the corruption shows up later somewhere unrelated.
Connect it up
Draw it
Draw the movement decision as a flow chart: 'Does it have a Rigidbody?' at the top, branching to no / kinematic / dynamic, with the correct call written at the end of each branch and which callback it belongs in.
Exit ticket
Predict first
Which is still shakiest?
Correct: Whichever you picked - open the lab scene and run the experiment for that one.
Why: This was 0 out of 3 in the diagnostic, so every one of these is new rather than shaky, and expecting to have all four solid after one pass is unrealistic. Pick the weakest, run its experiment in the lab, and bring the numbers you got to the next session.
Recap
You can predict whether an object will move, how fast, and whether it will notice a wall.
transform.position on a physics body skips collision detection entirely, and no setting can fix thatLab: unity-labs/Assets/NaruhodoLabs/Lesson03_Physics/SETUP.md. Reproduce the force trace by hand before you move on.
Want this taught 1-on-1? Alexander tutors Unity Game Engine — $55/session, free consultation.