Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Dot5

Verlet physics Q for Olii

This topic is 5228 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.



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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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


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]

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
I agree. I just do it as a hobby. the verlet particle system is kinda fun to play with

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!