# Help with trampoline velocity

I’m almost finished with something new I’m working on. One problem I have though is with the velocity / possibly acceleration. I’m making something () that uses a trampoline, and what I planned to do with the object that touched the trampoline is quite simple. When the ball touches the trampoline, a variable takes its velocity, then the ball’s velocity is set to 0. Then, that variable is subtracted from the ball’s velocity, causing it to go upward. It works fine, but the ball bounces higher every time it hits the trampoline. I was assume, that it would bounce lower each time, since it should bounce at the same height, but gravity should be pulling it down at the same time. I am quite confused by this. Also, the equation I’m using for acceleration is something like:

float accelerationModifier = 0.03;

velocity += (velocity * accelerationModifier);

I know it’s not the best, because the results aren’t equal. I have tried the program without acceleration, and the same problem (the first one mentioned), so It is not an issue with the acceleration.

Thanks in advance, and everything you need is in simulationLogic()

1 Like

This is called restitution: when two objects collide, not all of their relative velocity is necessarily preserved. Try the following:

The acceleration modifier line is what’s causing the velocity to continually increase:

//velocity += (velocity * accelerationModifier);

Change the collision response to incorporate restitution:

//this->ball.yVelocity -= this->physics.bounceVelocity;
float RESTITUTION = 0.75f;
this->ball.yVelocity -= RESTITUTION * this->physics.bounceVelocity;

This makes the ball bounce back upwards but at a lower velocity, which will result in lower and lower bounces.

2 Likes

The acceleration line was meant for the ball, so that when falling, it doesn’t look like the ball is just floating. Do you think it would be possible (as in justifiable) to keep that but only when the ball is falling (i.e. the velocity is positive)?

Thanks! I did experiment with something like this but it always resulted in buggy physics. I’ll try this one.

If you mean the ball seems to fall too slowly, probably the way to solve this is to increase simulation speed (or gravity).

It also just occurred to me that you should resolve the collision as well: if the velocity correction is not enough to bring the ball back out of collision after the next simulation step, you’ll have another immediate collision, and it will look bad. The ball could even get stuck inside the trampoline.

To fix this, you could add something like this to the collision response:

this->ball.y = trampolineHitbox.y - this->ball.height;
1 Like

I can see why you think that, however…

The problem is that you are compounding the velocity.

If, for example, velocity is -1 then after velocity += (velocity * accelerationModifier) it will be -1 + -1 * 0.03, which is -1.03. Next frame it will be -1.03 + -1.03 * 0.03, which is -1.0609.

Every frame the velocity will increase, at first it will be a small increase but eventually the velocity becomes large enough that it hits a point where the gravity doesn’t do enough to counteract it and your ball just keeps flying into space.

The bottom line: you are constantly accelerating the ball and it never stops increasing.

If you take away the so-called ‘acceleration modifier’, the problem becomes worse because you’re going from doing what is effectively velocity *= 1.03 to velocity *= 2 (velocity += velocity is equivalent to velocity *= 2).

I think perhaps you misunderstand the point of acceleration, so it’s time for a little physics lesson to clear things up…

In the real world acceleration isn’t a constant force, acceleration is the result of a force acting on an object.

A force, such as gravity, is applied to an object and that causes the object to accelerate.

The acceleration increases the object’s velocity and the object’s velocity is what causes the object to move.

If there’s no force, there’s no acceleration or decceleration, as would be the case in a vacuum.

On earth you have forces like gravity, friction, and air resistance that force an object to gradually come to a halt by deccelerating them or causing them to accelerate towards the Earth’s core until they hit another solid object (typically the ground).

Properly speaking the way acceleration is supposed to work is more like:

// Calculate the acceleration as the sum
// of all the forces that are acting on the object,
// including gravity.
object.acceleration = calculate();
object.velocity += object.acceleration;
object.position += object.velocity;

Sometimes for game physics it’s alright to take shortcuts, like skipping over acceleration and just doing velocity, which is what I did in my Physix demo.

With that in mind, let’s look back at your code for a moment.

If you comment out the this->ball.yVelocity += (this->ball.yVelocity * this->physics.accelerationModifier); line, suddenly things become a lot more stable. It doesn’t achieve quite what you’re hoping for because it produces a system with no loss of energy, but it behaves more appropriately because the ball is no longer accelerating infinitely.

With that you’re almost there. However there’s another subtle bug in your code that causes the ball to gradually bounce higher. The fact you apply the gravity after moving the ball actually causes the physics to behave improperly. You might think it shouldn’t make a difference, but it actually causes the position and velocity to be unsynchronised, and that subtle difference is enough to cause the velocity to steadily increase instead of steadily decrease.

One way to think of it is that you end up applying an extra step of gravity before the bounce happens, so when the velocity inverts it ends up having more velocity than it should have.

Another way to think of it is that forces are a means of transferring energy, so by applying more gravity than should be being applied prior to the bounce you’re causing the bounce to provide more energy than it should have, which causes an imbalance.

Under real world conditions a bounce wouldn’t be a perfect inversion anyway, there should be some loss of energy as a result of the collision (the ‘restitution’ mentioned by @brow1067). Sometimes it’s fine to ignore this in games if you aren’t too worried about accuracy, as long as the end result still provides the same effect, which is the case after fixing the gravity bug.

Anyway, with the gravity fixed and the acceleration removed you end up with code that does more or less what you intend. It leaves you one more issue though, because of the way you’re handling the collision. You’re actually waiting for the ball to go through the trampoline before making it bounce when what you really want to do is to detect the collision before an intersection occurs.

To figure that out, I recommend having a look at the updateEntityPosition function from my Platformer Demo.

At any rate, hopefully this helps you see why your code is going so far awry:

• Your acceleration based on the velocity when it should be the other way around.
• You’re constantly applying velocity when it should only apply if there are forces (such as gravity and bounce) acting on the ball.
• Your application of gravity and updating of position are reversed, which ends up producing extra energy from nowhere.

It doesn’t matter if you do it accurately or simulate it in an inaccurate way, but the system still needs to follow the same general rules to achieve the same effect as real world physics.

There’s a few redundancies in your code that could be rectified, but I’ll leave that there for now because this has been a long comment and I think I should give you chance to take it all in, think it through, and formulate a response before I bombard you with anything else.

You can see the mentioned changes along with a simplification of your bounce code here:

Recommended reading/watching in regards to physics and vectors:

2 Likes