Hello and welcome to chapter two of the Nature of Code, forces.

So I want to start with this discussion

by talking about Newton's laws of motion.

So by no means is anything I'm going

to do be a really accurate, robust physics simulation.

But at a minimum, I want to examine

what the basic laws of motion are, the basic principles

behind how things move, and just make sure

that the code I'm writing fits with that for the most part.

So let's start with those laws of motion.

Law number one.

This is how it is often referred to most informally--

an object at rest stays at rest.

However, a more accurate statement of this

might be, an object at rest stays at rest

and an object in motion stays in motion at a constant speed

and direction unless acted upon by an unbalanced force.

So that's a bit of a mouthful of stuff,

but let's unpack that for a moment.

Let's think about this in the context of our P5 canvas

and the object being a circle that I'm

drawing on that canvas.

If this circle is going to obey Newton's first law,

if it's not moving, there's no reason for it to start moving,

or if it is moving at a particular velocity vector,

there's no reason for that velocity vector

to ever change unless acted upon by a force.

The definition that I offered over here

uses the term unbalanced force.

So something that's very important about this concept

of staying at rest or staying at a constant velocity

is that it's not just whether the force is there or not,

but whether the net force, the sum

of all the forces in the environments,

add up to something non-zero.

For example, with my marker here, there's

a force of gravity pulling it down, presumably

towards the center of the earth, but there's also

some other forces that I'm applying to it to keep it up,

that are pushing it up.

And so if I try my best to balance the force--

balance the force-- then it won't move at all.

This diagram is another example of this.

So all of these forces balance themselves out,

and this object is at a state of equilibrium,

meaning it won't start moving, or if it

were, its velocity would remain constant.

And the reason I'm harping on this

so much is I really want to make sure

when I go to write the next bits of code

that I'm going to write, that the simulation obeys this law.

But in order for it to obey this law in the first place,

I have got to understand--

I'm using the term force all over the place.

It's really important that I think I take a moment now

to define what I mean by force.

A force is a vector that causes an object with mass

to accelerate.

That is the technical definition that I

am going to use for force.

Here's the good news.

Vector-- check.

We've got that.

I just did a whole section of videos about what is a vector,

so we can understand force as a vector.

Here's more good news for you.

Accelerate-- check.

I just did a video tutorial about how to apply acceleration

in a P5 sketch.

So if we can create a vector and somehow

have that vector affect the object's acceleration,

then we are implementing a force.

And if the way that we implement the force in our code

obeys this law, then we are golden.

One thing here-- mass is not something

that I have discussed, or used, or implemented

as a property of any of the things I've done so far.

So let's put a question mark there and return to that.

Which leads me to Newton's second law,

F equals M times A, or Force equals Mass times Acceleration.

I can also describe this law as a restatement

of the definition of force.

Force is a vector that causes an object with mass to accelerate.

We're turning back to the code for a moment.

I have these two lines of code--

vel.add(this.acc), pos.add(this.vel).

And in this example, everything starts with acceleration.

I'm calculating an acceleration based

on a vector that points from the object moving

to the mouse itself.

So if everything starts with acceleration,

maybe I need to rethink the way that I'm

describing this formula.

And a different way that I could consider it is acceleration

equals force divided by mass.

The idea being that if I introduce some force--

like let's say there is a wind force

with a magnitude and direction that I want

to put into this environment.

If I have that force, I could take that force, divide it

by this object's mass, and that would become the object's

acceleration, which would then affect its velocity, which

would then affect its position.

And this is the technique, the strategy by which everything

I do is going to be built upon.

I'm really ready to start implementing this in code.

But before I do so, there's a few things I want to address.

One is you might hear, when looking

at how physics engines are built, the term integration.

And this is actually one way of doing integration.

This specific way is referred to as Euler integration.

Why is it called integration?

I'm getting into the weeds here into the math aspect of this,

but it is important, and I think this will help you

as you move forward and do more of this stuff

when you see the lingo popping up here and there.

In calculus, there's the concept of a derivative.

And you might typically see this as written as like dx

over dt, the change in x with the change in time.

This is actually what velocity is doing.

Velocity is dx dt.

If x is position, velocity is the change

in position over time.

Acceleration is the change in velocity over time.

So velocity can be thought of as the derivative of position,

and acceleration can be thought of as the derivative

of velocity.

But I'm not going in that direction.

I'm not starting with position, and then

figuring out what's the velocity,

and then figuring out what's the acceleration.

I'm going in the other way.

I'm starting with what's the acceleration,

and then changing the velocity, and then taking the velocity

and changing the position.

So the other direction of doing the derivative

is integration, the integral.

So that's why this process is tied to calculus

and the concept of integration.

The big difference here is that calculus,

being the study, in a way, of infinitesimally small time

steps, these time steps are quite large.

This algorithm is just being applied 30 times per second.

But as I move my arm back and forth,

are you seeing this animation at 30 frames per second?

Maybe because you're watching a video, which

is then recording me and playing it back at 30 frames a second.

But the actual physical time space that I'm in

is very continuous.

The time step is infinitesimally small.

And if I were doing an accurate calculation of a physics

simulation, I would need to take that under consideration.

Instead, I'm using a technique called Euler integration, which

allows me to have fixed time steps, which are rather large,

and it's wildly inaccurate.

And I'll maybe back circle back to this

as I look in future videos about other integration techniques.

There's Berlet physics, and there's

Runge Kutta integration.

I probably didn't say that correctly.

And so maybe I could circle back when

we look at other physics libraries that

might have slightly more robust methodologies

underneath the hood.

But the reason why I like this methodology is, number one,

it works just fine.

I just want my particles to spiral around the screen

in pretty ways.

And two, it's really fast and really easy to implement.

So it has its advantages in terms

of the kinds of examples and demonstrations

that I want to show you.

Also, I know there's so much more to this.

Before you start typing your comments in the chat about

the theory of relativity, and space-time continuum,

and Planck time, and also "Plonk" time--

I don't even know how to say it--

my goal here is not to go in-depth

into the physics of this, and I'm

glad to include in this video's description

other resources that do, but to take

these ideas, these core classic concepts,

and then work out a way to implement them in code.

I should also mention there is Newton's third law, which

is often stated as, for every action,

there is an equal and opposite reaction.

That's a little bit misleading, and I've written

some thoughts about that here.

Another way of stating that law is,

forces always occur in pairs.

The two forces are of equal strength

but in opposite directions.

So to be honest, this law is not so meaningful to me right now.

Trust me, it's kind of important.

But in terms of the simulation that I want to start with,

I am not going to bother to simulate

every possible reaction and opposite

interaction of every force within the system.

But this will come up again, and I will look at this law

when, in a future video as part of this section,

I look at gravitational attraction

and how two bodies both attract each other,

and those forces are of equal strength

but in the opposite direction.

To get started implementing Newton's second law in code,

I want to build off of the example

that I finished with in the previous section on vectors.

So here, I have this mover object.

It starts at a position 200, 200,

and two functions are called, update() and show().

So if I run it, the acceleration is

being calculated as a vector pointing towards the mouse.

You could think of it as a force,

a gravitational attraction force pulling into the mouse.

It's not really that.

Of course, it's not really that.

It's just some pixels on a screen.

But I'm not even using the formula

for gravitational attraction.

So I'm going to circle back to that

and make some changes to this kind of idea later.

But right now, what I want to do is change the way the internals

of the mover object works because right now,

the acceleration is being calculated right here

in update(), and I don't want to do that.

Instead, I want to write a function that's

basically Newton's second law.

So I want to write a function--

I'm going to change its name in a moment--

that implements this particular law.

The law, again, is force equals mass times acceleration.

But I've rewritten it to acceleration equals

force divided by mass.

Guess what?

Let's just pretend for a moment that the world we live in,

the world that I'm programming in, there's no concept of mass.

In fact, everything in this entire universe

has a mass of 1.

So in that case, going back to this law of force

equals mass, which is 1, 1 times acceleration

is really just same as force equals acceleration

or acceleration equals force.

So these are the same concepts.

Meaning, I could just say this.acc = force.

There we go.

This is the simplified version of Newton's second law in code.