Jump to content
• Advertisement

Daniel Peterson

Member

6

102 Neutral

• Rank
Newbie

• Interests
Business
Production
Programming
1. Time complexity considerations of Sutherland–Hodgman clipping in one-shot contact generation

It worked great, thanks for the help!
2. 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. Elastic collisions and contacts warm starting

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. Time complexity considerations of Sutherland–Hodgman clipping in one-shot contact generation

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. 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. 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!