Name: プログラミングボール #2 円 V エッジ 衝突 C++ (Programming Balls #2 Circles V Edges Collisions C++)
Uploaded: 2021-01-14T10:13:53.000Z
Duration: 32 min 28 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

未来進行形

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.

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.

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.

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'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.

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.

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.

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.

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.

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.

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.

Remaining distance, equal speed times time.

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

字幕リスト動画再生

プログラミングボール #2 円 V エッジ衝突 C++ (Programming Balls #2 Circles V Edges Collisions C++)

arbitrary

structure

accurate

manipulate

プログラミングボール #2 円 V エッジ 衝突 C++ (Programming Balls #2 Circles V Edges Collisions C++)

arbitrary

structure

accurate

manipulate

プログラミングボール #2 円 V エッジ衝突 C++ (Programming Balls #2 Circles V Edges Collisions C++)