When you say dampening the velocity, you should be really be applying a constant force in the opposite direction of travel. Realize that we're dealing with a force, not an acceleration because we're dampening the velocity with respect to the mass. Therefore...
dtp = (dt for the last frame)
dt = 1 / FramesPerSecond
x' = x + (x - xo) * (dt / dtp) + a * dt * dt
And if all works out, your verlet integration should work at any framerate.
[Edited by - y0y on January 21, 2005 10:21:05 PM]
Verlet Physics: Help!
Author
I've noticed in my tests that this drift problem is quite severe. The more the force applied, the more the displacement of the particles, and the more the drift.
For e.g. in the my simple test application which I described above, when the gravity force is little, the drift is very small and almost not noticeable. But as I increase the magnitude of the gravity force, the drift increases drastically.
I feel that this error is caused by the fact that we satisfy each constraint one after the other, instead of satisfying all the constraints at once. This seems to be the key.
What do y'all think?
Francis Xavier
For e.g. in the my simple test application which I described above, when the gravity force is little, the drift is very small and almost not noticeable. But as I increase the magnitude of the gravity force, the drift increases drastically.
I feel that this error is caused by the fact that we satisfy each constraint one after the other, instead of satisfying all the constraints at once. This seems to be the key.
What do y'all think?
Francis Xavier
that introduces drift. A quick bodge would be to satisfy constraints one way going up the list, and then next time the other way, going down the list.
I tried that, it reduces the drift a fair amount, but it's just a hack really. Resting the object properly would be the way to go.
I tried that, it reduces the drift a fair amount, but it's just a hack really. Resting the object properly would be the way to go.
Author
Thanks for the replies.
To Rompa & y0y:
Thanks for the info. I'm using a fixed timestep and plan on continuing to do so. I find that it's less troublesome and the results are deterministic.
To oliii:
I checked out your code samples and noticed that you do that. That's a pretty clever trick. I was thinking of doing it another way. Building a few random index lists and then satisfying the constraints by using a different list each time. However there would be quite some overhead if constraints were to be frequently added/removed.
Btw, your verlet examples are pretty impressive, good work and thanks for making the source available.
Francis Xavier
To Rompa & y0y:
Thanks for the info. I'm using a fixed timestep and plan on continuing to do so. I find that it's less troublesome and the results are deterministic.
To oliii:
I checked out your code samples and noticed that you do that. That's a pretty clever trick. I was thinking of doing it another way. Building a few random index lists and then satisfying the constraints by using a different list each time. However there would be quite some overhead if constraints were to be frequently added/removed.
Btw, your verlet examples are pretty impressive, good work and thanks for making the source available.
Francis Xavier
no problemo [grin]
YOu have to be carefuil with verlet and variable frame rates. Verlet works only with fixed time steps. I haven't found a good way of making the plain verlet work with variable framerate, and I don;t know if it is possible.
something like
void Integrate(float dt)
{
tempx = x;
x += (x - prevx) + a * dt*dt;
prevx = x;
}
so basically, (x - prevx) represents the displacement the previous frame. to keep the velocity the same with a new timestep, it 'should' be
void Integrate(float dt)
{
temp_x = x;
x += (x - prev_x) * (dt / prev_dt) + a * dt*dt;
prev_x = temp_x;
prev_dt = dt;
}
but I might be totally wrong.
YOu have to be carefuil with verlet and variable frame rates. Verlet works only with fixed time steps. I haven't found a good way of making the plain verlet work with variable framerate, and I don;t know if it is possible.
something like
void Integrate(float dt)
{
tempx = x;
x += (x - prevx) + a * dt*dt;
prevx = x;
}
so basically, (x - prevx) represents the displacement the previous frame. to keep the velocity the same with a new timestep, it 'should' be
void Integrate(float dt)
{
temp_x = x;
x += (x - prev_x) * (dt / prev_dt) + a * dt*dt;
prev_x = temp_x;
prev_dt = dt;
}
but I might be totally wrong.
Author
Thanks for the info. However, I think that using a variable time step isn't going to cut it if we need the results to be deterministic (am I using the right word here??).
The results should be the same no matter when/where the simulation is run. For a network based game, or if we need to provide some kind of playback mechanism, given some initial state, we'll need the outcome to be the same at all times. I don't know if this is possible with a variable time-step approach. With a fixed time-step this works fine and it's also easier to understand and implement IMHO.
Francis Xavier
The results should be the same no matter when/where the simulation is run. For a network based game, or if we need to provide some kind of playback mechanism, given some initial state, we'll need the outcome to be the same at all times. I don't know if this is possible with a variable time-step approach. With a fixed time-step this works fine and it's also easier to understand and implement IMHO.
Francis Xavier
it's certainly easier with fixed time steps for playback systems. You can always record the frame timestep as an input in your playback system. But then, it can get jittery (since the playback time step maybe different from the recorded timestep forthat frame), and then you'll have to de-sync the physics update with the render update. And in network games, I haven't tought about it, but a fixed time step seems a lot less painful.
Author
Quote:Original post by oliii
and then you'll have to de-sync the physics update with the render update
But I thought that this was what everyone does. I've read that Doom 3's physics runs at about 60 Hz. And other games must be doing the same, right?
Btw, what does everyone recommend as the best way to do physics? I mean, verlet or traditional rigid body physics? With both ways I currently have a problem with simulating resting contacts. Mr. sbroumley has adviced me to put the body to sleep. And I've noticed that many do the same. Mr. Rowl also puts his rigid bodies (traditional rigid body physics) to sleep I think. But I somehow feel that this is not exactly the absolutely right way to do it. So I'm still experimenting.
Thanks for the replies. Ideas and suggestions are always welcome.
Francis Xavier
Author
Quote:Original post by oliii
A quick bodge would be to satisfy constraints one way going up the list, and then next time the other way, going down the list. I tried that, it reduces the drift a fair amount, but it's just a hack really. Resting the object properly would be the way to go.
Actually I tried it and it works like a charm. Better than the method I suggested which satisfies the constraints using a randomized index list. I think this is because of the fact that the randomized list will introduce random drifts which may / may not cancel each other out. So the net result is a slight drift. But using your way, I think, that an equal and opposite drift is caused when the list is satisfied backwards. So the net result is ~zero drift. Cool going man!
Francis Xavier
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
