Difficulties with very basic floor with velocity verlet

[Thiamin]

Hi everyone.
I'm writing my first physics engine and have a basic spring / particle system working okay using velocity verlet integration (after reading some really helpful posts on this forum - many thanks, especially h4tt3n) and I am now trying to make a flat bouncy floor.

I want to make it as simple as possible, and I started by just checking whether Z is less than zero for each new particle position, and if it is then simply negating its Z value on position and velocity. (ignoring X and Y for now, just trying to get vertical bouncing working right first)

but I've realised now it's not actually this simple, and am having a hard time making it so the particles don't bounce higher each time, or if I add damping, they get near the floor then keep bouncing.

The difficulty is with the acceleration terms in the position and velocity calculation of the velocity verlet.
Because part of the timestep the particle is travelling downwards, and part of it upwards, and I'm getting confused trying to figure out the resulting change in vertical position and speed.

I can get the ratio between the distances travelled upwards and downwards during the timestep with the bounce in it.
I think I know how to get the average velocity, but am stuck on the acceleration.

Any pointers ?

[bone]

I think I know how to get the average velocity, but am stuck on the acceleration.

Any pointers ?

My opinion is that the acceleration is always the same - that of gravity. Even during a bounce! You are currently affecting the velocity on the bounce through an impulse (switching the sign of the vertical velocity is equivalent to a collision impulse with a restitution of 1.0), which is an instantaneous change in velocity rather than one that happens over time due to acceleration.

BTW, I maintain that Velocity Verlet is identical to Symplectic Euler in long-term results (I've got a spreadsheet that proves it), but the latter is easier to implement and understand, especially with a problem such as yours. Plus it's slightly faster.

[Thiamin]

Thanks for the reply.
I'm still confused though.
I agree that the acceleration due to gravity is always the same in real life of course -
but if I mirror the position, then effectively I am reversing the velocity for part of the timestep.

so for part of the timestep gravity is in the same direction as the motion, and for part of it opposed to it.
If acceleration is applied as normal over the whole timestep, then the position is flipped, surely I get something like the red curve in this image:

rather than the blue curve which is what I want.
It is not a huge difference if the timestep is small, but over several bounces it adds up, and as the bounces get tiny it becomes more significant.

It's interesting that what I was trying was equivalent to an impulse method. I guess I'll have to read up on this approach a bit more.
I thought at first that in this simple situation I could use a method so basic that I avoided having to study that, but it seems it is not so.

As for what you say about Velocity Verlet giving the same long term results as Symplectic Euler - this is incredibly confusing for a beginner ! If what you say is true, then why does anyone use velocity verlet at all ?
It seems many people say different things about this, and it doesn't help that there are so many names for each that sometimes seem to get mixed up.
I'd love to know for sure which of the following are actually effectively the same thing:
Verlet, Newton-Stormer-Verlet, Symplectic-Euler, semi-implicit Euler
Velocity-verlet, Leapfrog

[bone]

Sorry, I didn't mean to confuse you. Never mind the integration methods and impulses for a moment.

I think I see the real issue here (but note that this is without sitting down and actually trying it). Try starting your simulation with the particle position at Z=0. In the ideal simulation, it would just sit there. In yours, however, I believe that gravity will cause a velocity into the ground. The particle will fall below the ground, and you'll detect this (probably at the next time step). When you reverse the position, you're now putting the particle above the ground - giving it potential energy that it didn't have at the start of the simulation.

While there's a couple of possible strategies here, I don't think any of them would include moving the particle above the ground - at most you would move it simply to the surface.

[Thiamin]

Yes, I tried it and you're right - even particles starting at z=0 bounce up a little bit.
I'll try just moving it back to 0 rather than reversing it and see how that goes.

I just really want to get that
boing...boing..boing.boing-boing-boi-b-b-bbbboooooing!!

[Thiamin]

Yes, that works thanks.

Even with no damping they don't bounce quite to back their original height now, though that's not really a problem.

They also sometimes look very slightly sticky as they bounce (I guess it sometimes ends up with 2 frames of the particle almost exactly in the same place). Are there any ways round this issue?

[bone]

One idea would be to get really analytic about this particular scenario, and predict the collision in advance. For example, given the position, velocity, and the acceleration of gravity, you might know that you will hit the ground within the next timestep, so you work out exactly when and what the result will be.

A somewhat similar way of looking at this is to back up to the exact (or roughly exact) time of collision, and then continuing from there with your exactly reversed velocity (for the restitution = 1.0 case). This basically breaks your time step up into two or more steps.

I think both cases run into a problem, though, with restitution less than 1.0 - the bounces will eventually become very quick, so that you have multiples bounces per time step. Without some strategy to deal with this, you'll quickly be spending a lot of time moving from one bounce to the next.

[Thiamin]

Thanks, that sounds like an approach worth exploring.

The other problem I noticed with simply setting the position to 0 if negative is that objects sort of skid as they bounce, which looks very unrealistic in the case of something like a box bouncing on its corner then coming to rest.

It's going to take some puzzling to figure out how finding the collision time fits together with the half-timestep velocity updates, but I'll give it a go.

As for when the bounces get faster than the timestep, I think it would be good to try and detect this and set position and velocity to zero.