Jump to content
  • Advertisement

Daniel Peterson

Member
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

102 Neutral

About Daniel Peterson

  • Rank
    Newbie

Personal Information

  • Interests
    Business
    Production
    Programming
  1. It worked great, thanks for the help!
  2. Daniel Peterson

    Elastic collisions and contacts warm starting

    Ok. I found the answer in the source code for Irlan Robson's Bounce Physics engine. https://github.com/irlanrobson/bounce/blob/master/src/bounce/dynamics/contacts/contact_solver.cpp The key is to store the restitution velocity bias before the solver starts (for example in the contacts setup method for the solver). if (relativeNormalVelocity < -THRESHOLD) { contact.velocityBias = -relativeNormalVelocity * restitutionCoefficient; } else { contact.velocityBias = 0; } Then in each step of the solver when you calculate the accumulated impulse you add in the velocity bias: float oldImpulse = contact.impulse; float impulse = (-relativeNormalVelocity + contact.velocityBias) * contact.mass; contact.impulse = max(contact.impulse + impulse, 0.0f); impulse = contact.impulse - oldImpulse; That way the relative velocity for the restitution is preserved throughout the iterations. Thank you @Irlan Robson
  3. I implemented contacts warm starting the way Erin Catto describes in his 2009 GDC Box2D lecture (box2d.org/files/GDC2009/GDC2009_Catto_Erin_Solver.ppt). However this seems to only work for inelastic contacts (no bouncing). Can anyone point me in the right direction for how to extend this idea to incorporate elastic collisions? I tried looking through the Box2D source for this, but I could not figure out how it works. Any help is appreciated!
  4. Hi, Most people seem to prefer some version of Sutherland–Hodgman clipping when generating one-shot contacts. Sutherland–Hodgman has O(n*m) time complexity. Is this fast enough for most practical purposes or is there a compelling reason to pick a different algorithm with better time complexity? I guess I could always profile, but I'm also asking in case there are other considerations that I may have overlooked... Is there for example some case of temporal coherency that can be exploited? Thanks!
  5. Daniel Peterson

    GJK warm starting

    Thanks @Randy Gaul! I had a look at the link. In case someone searches for this in the future, here is a condensed 3D version of the strategy used in the Box2D source link that Randy posted. float GetSimplexMetric(const Simplex &s) { const Vector3 sp = s.supportPoints; switch (s.count) { case 2: return (sp[1] - sp[0]).Norm(); case 3: return (sp[1] - sp[0]).Cross(sp[2] - sp[0]).Norm(); case 4: return (sp[1] - sp[0]).Cross(sp[2] - sp[0]).Cross(sp[3] - sp[0]).Norm(); } return 0.0f; } void DoGJK(Cache* cache) { Simplex s(cache->indices, /* New support points calculated from cached vertex indices */); float metric = GetSimplexMetric(s); if (newMetric < cache->metric * 0.5f || newMetric > cache->metric * 2.0f)) { s.clear(); } // Do normal GJK... // Update the cache with the new simplex indices and the simplex metric cache->set(s.indices, s.count); cache->metric = GetSimplexMetric(s); } The idea is to build a metric that is proportional to the length/area/volume of the simplex and then throw away the simplex if this area changes by two big of a factor between frames. The exact ratio of the limits are not so important from what I can tell. It seems to be more of a "better safe than sorry" kind of thing. The big win is in avoiding recalculation of the simplex for resting and near resting contacts. Box2D uses factors 0.5 and 2.0 with a linear metric. So to get the same factors for a square metric like in the example above I guess you would use 0.25 and 4.0 instead. But I doubt there would be much difference in practice...
  6. Daniel Peterson

    GJK warm starting

    Hi, I'm experimenting with GJK and I have a question about warm starting by reusing the simplex from the previous time step. Is this safe and straight forward to do? Will the GJK algorithm converge even if the vertices of the simplex are no longer extreme points of the CSO? Are there any other things to consider? Thanks!
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!