Welcome to programming balls, Part two.

And in this video, we're going to be looking at extending the circle versus circle engine we developed in part one to deal with circle versus edges on.

What we'll see in this video is that's actually not a big leap.

In fact, we're going to come up with a way of treating edges as if there were circles, and I'll also be looking at changing the timing method of the simulation to make it more accurate.

So just in case you haven't seen part one, and I really recommend that you do, because I'm not going to cover all of this code again, we ended up with a program that looked like this on.

We could pick up a ball and we can see it deals with what are called static collisions.

Static resolution is where the ball's push each other out the way so they don't interfere with each other on.

We also implemented a Q, where we could give the ball some velocity on, watch them all interact with each other, and this was the dynamic resolution.

And so this video is just going to modify the code that we already have developed.

And just before we jump straight into the maths, I thought would be interesting to show what we're going to be developing today.

And as we can see, we've got balls again interacting on.

We've also got the ability to drag and drop these edges, and we can start to see interesting behaviors off the entities as they flow around the screen.

I'll just let these wants through from the top.

There we go.

So we've got balls of different sizes.

We've got edges at arbitrary angles on.

We've got interactions between all of the above on.

We've still got the queue action as well, so I can give the ball some velocity and we can see it bounce across the edges, as it needs to do is try and aim one at here.

There we go in.

It deflects around the scene in a realistic manner.

And of course this has applications in lots of games, mainly public sports games.

But I'm sure there's some creative types out there who can come up with all kinds of simulations where this might be useful.

So I wanted to start by talking about making the timing of the simulation a little more accurate on in the previous video, we had a ball which had an origin point on its velocity, moved it to a new position on this was over a fixed time step T That's all very well and good, because we know that speed equals distance over time and therefore distance equals speed times time.

But there was one problem with this approach.

Let's say two circles collide with each other.

The way we resolved this was to find the midpoint of the overlap between the collision and then displaced both balls in the opposite direction by the same amount as half of the overlap on.

On the surface that worked very well, but it's quite inaccurate simply because this collision must have occurred before the end of this iPAQ of time.

So if we momentarily treats our velocity vector as a timeline, we know that actually the collision happened about here, which is not a complete iPAQ of time, and this means we can split the park into two different sections.

We've got the before collision and we've got the after collision.

And of course, during this after collision we have some sort of dynamic response where the Balkan move a bit more.

And so by sticking to a rigid timing framework, as we have done in the first video, the bulls are individually breaking the laws of physics.

They're not traveling as far as they need to in the time that we told them to be simulated.

Now the second problem involves the length of the iPAQ itself.

Now, in the first video, one epoch was governed by F elapsed time.

AII the time between successive frames.

And so if the frame rate was high, the distance the ball could travel was much shorter.

This would lead to, well, more accurate simulation.

However, if the frame rate was low, then potentially, the park is considerably larger, and we risk a situation.

We're here.

We've got one ball after its position has actually gone through the object that is trying to collide with and so doesn't get registered.

And it's not.

Ideals have a physics engine where objects can pass through each other.

Now there's an easy way on a hard way to deal with this on the easy way is still an approximation, and it simply says that we break up the park into smaller simulation steps, and we choose a simulation step size which we know is suitable to the rest of the game engine that we're implementing.

The harder on yet more accurate way is to cast a ray along the velocity vector of the object.

But we're checking on DWI perform into section tests with all of the objects into the in the scene to see if they collide with that ray.

And of course, there may be several objects for one epoch here.

We would solve the objects to find the object which is struck first and then deal with the collision accordingly.

There is no doubt that this approach is more complicated and potentially more computational, expensive to aunt.

To keep this video in line with the video one on most of this channel, I'm just going to keep it simple.

I'm going to break up the park into smaller steps, so we're going to do two things.

Firstly, we're going to break up the park on then we're also going to deal with making sure that the object does all of the physics it needs to do within that iPod.

Now you we don't cut it short so continuing directly from the code last time, Let's get started could create a variable and interview called M simulation updates, which is how many times you want to subdivide the park.

And I'm going to start with the value for So this effectively means that for each frame update, we're going to run the physics simulation four times now.

Of course, we don't want to use F elapsed time anymore as the time step for our simulation.

We want to use some smaller version off it, so I'm going to create F Sim elapsed time, which is going to be equal to F elapsed time divided by the number of simulation updates.

And so each of the physics updates in this case is going to take 1/4 off the F elapsed time, and it really is a case of just taking all of the physics code and sticking it inside a loop.

We got static collisions, dynamic collisions and before we get to the drawing code, that's where we end our loop.

So we're going to do all of the physics four times over now.

The only bit that we need to change inside is we're no longer using F elapsed time.

We're going to be using F simulation elapsed time, so we need to change these variables and we'll just have a quick run to see what happens.

And hopefully absolutely nothing has changed.

Everything is as it was before.

Our epoch is no defined as F sim elapsed time, but we need to break this up even further into the time before the collision on after the collision and in fact, in one e pockets possible toe have multiple collisions, all of which take their own duration.

Now, given how many interactions each ball may face, it's going to need to keep track of its own time.

So I'm going to add to the ball structure a floating point variable f sim time remaining on Before we do any physics updates, I'm going to set the F same time remaining for every ball.

So for this frame, we're going to simulate four e pox on beach ball is going to keep track of how much time it's got left in that epoch as it's bouncing around now.

Currently, in any park, we update the ball's position.

We check for static collisions on we resolve the dynamic collisions, and that's it.

So that really means we can only deal with one collision per epoch.

Now that we're handling physics on fractions of any park, we need to check for more collisions on resolve them per bowl per epoch.

So I'm going to add another interview variable, which is Max Simulation steps on.

This really sort of suggests how many times in one epoch can we update the position, resolve the static and resolve the dynamic collisions and so internally to the simulation updates on.

After we've sent the E Park time for the ball, I'm going to again wrapped the code up in a four loop that's executes the simulation the correct number of times.

I appreciate that right now.

This actually might be a little difficult to comprehend, but as we start filling in a bit more code, it should reveal itself.

So let's firstly update the ball position routine.

Here we go through all of the balls on we update the velocity vector, the acceleration director, and we wrap them around the screen on.

We clamp them if they're near zero, but we only want to do any change to the ball's position.

If there is any simulation time remaining for this ball on this epoch?

So we'll capture all that in an if statement and instead, off Sim elapsed time.

Now we only want to update the cinematics on a time step equal to how much time the ball has remaining.

So how do we go about working out?

How much to reduce the same time remaining variable for the ball?

If nothing has happened to the ball on its journey, then same time remaining can be reduced by the time for this epoch, the ball is simply just relocated.

Everything's fine.

But if there is a static collision of any sort, then the park has been shortened.

So we'll look at how much to reduce same time remaining as part of our check for static collisions.

Now, as with all of these things, this again is only approximation.

But it is a theoretically accurate approximation and so helps his own on the whole with the overall accuracy.

Firstly, we need to work out what the intended speed of the object Waas.

And this, of course, is just the magnitude off its velocity vector.

No, forget speed is a scaler quantity.

And if we know the scaler speed of the ball on.

We know how much time the ball had to move in.

We can work out what the intended distance waas for the ball.

It's simply the speed.

Times the time.

Remaining distance, equal speed times time.

Now we know if there's been a collision, it will never have reached the intended distance.

And so we want to calculate the actual distance.

On the actual distance is where the ball currently is.

Now we've just displaced it.

We can see appear.

We've got some balled up PX and balled up P Y calculations.

But what we don't have is a record of where the ball started, so I'm going to add to the ball structure to more variables.

Old ex on old wife On in the Kinnah Matic section, where we update the ball's position, I'm just going to record the Were The ball is at the start.

I'm going to store those in the old X and Y values before we go and change them, and this makes calculating the actual distance very trivial indeed.

Now it is just the magnitude off the vector between the original point on the current point for the ball.

So even though it's a long line of code, it's just Pythagoras theorem.

Now, if we rearrange, speed equals distance over time to make time the subject.

We can say that the actual time taken to cover the actual distance is time equals distance divided by the intended speed, and so that we know that the actual time taken before the collision before the static collision has happened is where we're going to divide our epoch.

So the Bulls personal track of how much simulation time remaining it has is just reduced by the actual time before the collision.

So let's just double check.

Make sure all that works.

It should look and feel exactly as it did before.

But we can now operate safe in the knowledge that our physics simulation is considerably more accurate than it was before were effectively subdividing the time between frames as necessary.

So fur ball has lots of collisions.

It gets a lot more attention, as opposed to a ball that has no collisions.

It just simply updates his position and gets on with it.

So let's have a think about adding edges into the mix.

Here.

I have an edge, and here I have a bowl moving towards the edge.

And, of course, what I want to happen.

Is it The bull deflects off the edge of the appropriate angle on, Of course, no surprises here.

It's a reflection.

But before we get stuck into the physics, let's handsome coat out edges to our program.

And in fact, I'm not going to use edges.

I'm going to use capsules, and a capsule is like a line segment that has a radius attached to it.

So I'll draw in red here on the outer shape off a capsule with some radius about it.

And what we'll see is it gives the line some thickness.

Obviously, I'm not very good at drawing.

That should be central.

But when you get to the edges, they become circular.

And this is great enough physics engine because we know we can do circle versus circle collisions already, so this radius is consistent around all points.

Now I'm going to define my line segment as simply being to coordinates start X and why andan end X and Y on a radius, in which the same way that we manipulate the bull structure I'm going to create a line segment structure.

We're going to consist of coordinates for the starting point SX and S y coordinates for the end e x n e y Onda radius.

In fact, I'm going to do things very similar.

Well, we've got a vector to store the ball objects.

I'm going to create a vector to stall the line objects.

And I know I'm also going to want to select and manipulate the lines on the screen at some point.

So I'm going to steel list from here, change this to a line segment and instead of selected ball, will have selected light in our own user.

Create function We were defining the wife frame model of a circle on adding some balls to the simulation will add a line to the simulation, too.

So I'm just going to create a variable, which is the line Radius Could will probably want to add several lines at some point.

I'm just going to set that to four for now, Aunt, to add lines to the vector.

I'm just going to push the initialize a list to the back of the vector because it's a simple structure.

We know the order of these already.

It's the starting X and starting.

Why positions?

So I'm just going to pull some numbers out of thin air walls.

Put this one at 30 in the X, and we'll put it at 30 down the screen.

We wanted to be quite long, so I'm going to set this 1 200 We'll keep it horizontal to start with.

Sore set that y 2 30 and then we have the radius.

Now let's have the code to draw the lines on the screen.