Verlet physics Q for Olii
Author
I have been developing a verlet based physics system for an FPS game. So far I have used primarily the Jacobsen paper to go from with a lot of success. I have collision responses, soft and hard bodies, rag doll and vehicle (to some degree) simulations. I was interested in looking at the idea of having a more complex model, in fact using a visual mesh fastened to a frame ( as jacobsen describes). This would allow much more complex models to be used without having the overhead of satisfying a ton of constraints. This in itself it reletively easy however I cannot seem to get a satisfactory method of introducing friction to the object.
I downloaded your demo (slide collision - BTW all your demos are v.good) to see if you had achieved this, and noticed it behaves very similar to mine (objects sliding indefinatly). Do you know of a way to introduce contact friction to the body without having to calculate a persistant set of constraints fastening the model to the frame? I noticed from some recent demos of the upcoming "bleeding edge" technologies like the HL2 engine that they suffer the same problem (one obvious example is the sliding fridge in the unreal3 engine demo). Its getting close to the point where the system would become almost as complex as a real rigid body sim (by that i mean a traditional RB sim) and I would rather go that route if I had to start calculating relative torques and forces to affect the frames individual (and heavily approximated) particles.
regatds, Dot5
Author
One method I am thinking about is to store the collision position, then check the position the next frame, and recalculate a new one if it is still contacting based on the derived velocity.
static friciton is a pain, yes 
I haven''t thought too much about it though, but you can try that.
this is my standard collison response of a particle hitting a segment, in 2D.
and I tried something interesting. I replace the ADD STATIC FRICITON CODE HERE with
if (Dt * Dt < 1.0f) Dt = Vector(0.0f, 0.0f);
which basically cap the tangencial displacement of the particle, if it is below a threshold.
it seems to simulate static friction, but I can''t say it''s 100% working, it was just something I was messing with.
I haven''t thought too much about it though, but you can try that.
this is my standard collison response of a particle hitting a segment, in 2D.
void Slide(float t, const Vector& N) { // collision response parameters float elasticity = 0.4f; float friction = m_fFriction; float threshold = 0.1f; // avoid floating point innacuracy problems // current particle displacement Vector D = (m_xNewPos - m_xCurrPos) ; // new particle position at point of impact m_xCurrPos += D * t + N * threshold; // impact velocity float dn = (D * N); // make sure it''s an impact, not a separation if (dn > 0.0f) dn = 0.0f; // split impact along normal and collision plane Vector Dn = N * dn; Vector Dt = D - Dn; //-------------------------------------- // ADD STATIC FRICTION CODE HERE //-------------------------------------- // calculate impact response D = Dn * -elasticity + Dt * (1.0f - friction); // calcualte new particle target position after impact, // and add the threshold to conserve the momentum intact m_xNewPos = m_xCurrPos + D + N * threshold; // flag as collided this frame m_bCollided = true; }and I tried something interesting. I replace the ADD STATIC FRICITON CODE HERE with
if (Dt * Dt < 1.0f) Dt = Vector(0.0f, 0.0f);
which basically cap the tangencial displacement of the particle, if it is below a threshold.
it seems to simulate static friction, but I can''t say it''s 100% working, it was just something I was messing with.
Author
Yeah, friction on a particle is not too bad. For the other objects which are straight math models (using the verlet method) the friction works fine (even for stacked objects).
My problem was updating the frame to represent friction of a particle that is not readilly on the frame. I was considering calculating a couple force based on the distance between the collision point and any points on my frame (which is a cubic) but this would be very expensive.
I will try storing the collision data over a frame so I can calculate a new target pos based on any friction from the given velocity and let you know. My monitor might as well be a thawing turkey at the moment (can''t think anymore today) so im off home.
cheers Oliii
My problem was updating the frame to represent friction of a particle that is not readilly on the frame. I was considering calculating a couple force based on the distance between the collision point and any points on my frame (which is a cubic) but this would be very expensive.
I will try storing the collision data over a frame so I can calculate a new target pos based on any friction from the given velocity and let you know. My monitor might as well be a thawing turkey at the moment (can''t think anymore today
) so im off home.cheers Oliii
actually, I had another look, and the change isn't doing much, no matter how far I push the threshold. the gravity gets in the way, pushes the particle down the slope, so in the end, it just makes the dynamic friciton harder after a given threshold, but that's it. I tweaked it and had much better results storing a 'collided' boolean per particle, and in the update function
that gives me very good looking static friction.
[edited by - oliii on June 2, 2004 4:52:48 PM]
void Update(float dt) { AddForce(Vector(0, 40 * m_fMass)); Vector xDisp = (m_xNewPos - m_xCurrPos); m_bSticking = (m_bCollided) && ((xDisp * xDisp) < 0.008f); if (m_bSticking) { m_xNewPos = m_xCurrPos; } else { Vector Temp = m_xNewPos; m_xNewPos += xDisp + m_xForces * (m_fInvMass * (dt*dt)); m_xCurrPos = Temp; m_xForces = Vector(0.0f, 0.0f); } SetCollided(false); CalculateBoundingBox(); }that gives me very good looking static friction.
[edited by - oliii on June 2, 2004 4:52:48 PM]
My experience has been that whilst the particle/verlet approach looks simple, it just doesn''t scale well and as soon as you make it more sophisticated it becomes less simple, less elegant and less powerful than a rigid body approach. The latter doesn''t need to be at all complicated if you''re willing to trade a little performance for simplicity (i.e. use impulses + iterative solver along the lines of the Guendelman et al. paper - see my demo).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
