Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Aug 2013
Offline Last Active Apr 19 2015 11:46 PM

Topics I've Started

Sequential Impulse Solver and Sliding Contacts

21 May 2014 - 01:01 AM

Hi All,


Been implementing a 2d sequential impulse engine (mostly for the academics of it). The main pipeline of my current engine is:


1) Detect Collisions

2) Resolve % of each penetration

3) Repeat 1 & 2 'n' times

3) Resolve velocities

4) Integrate

5) Repeat


This seems to give fairly descent results. However, no matter what I try when objects stack in vertex-edge configurations, or edge-edge in pyramid-like structure, then the angled objects will push others out of the way regardless of how many objects are in the pile being pushed. Here are some videos showing the results:





Initially I thought there was something wrong with my friction implementation but I've tried increasing friction to no avail. Next, for edge-edge cases I only resolve a single contact, so I've experimented with different contact points also to no avail.


I can only think of two things which may be causing this, either:

   1) This is un-avoidable for a sequential impulse solver -- which doesn't feel entirely correct. sliding from sequential solvers should be gradual drifts; not this dramatic but perhaps I am wrong.

   2) Steps 1 & 2 in my loop place a large emphasis on resolving penetrations (via position corrections) rather than giving more weight to #3. As I've been reading around online, it seems many don't even do #2 but rather only resolve the velocity by applying the appropriate impulse plus some small portion of the penetration (baumgaurte stabilization?).


As far as my penetration resolution implementation: it resolves the penetrating objects in the direction of the contact normal according to the objects' mass. Each pair is resolved  in the order of greatest separating velocity.


Simple answer seems to be put everything to sleep.... though I feel like that's just masking a stability problem.


I'd appreciate any feedback on the ordering of my main loop, and any suggestions on what may be causing my stacks to push apart / how I might be able to mitigate that? Would a TOI solver fix this, or is simultaneous resolution the only answer?  Anyways, I feel like I have lots of ideas, but no clear direction; so some guidance would be very helpful.


Let me know if you need more info from me.



GJK Simplex Caching and Circles

22 August 2013 - 11:35 AM

Hi, I've just finished implementing GJK for collision detection in my 2D physics engine. However, I'm trying to modify my implementation so that it will work with circles as well. Normally, this would be pretty straight forward since a support function for a circle is really simple (circle.pos + |dir|*radius). However, I'm also warmstarting my GJK implementation using the cached support vertices from the previous frame. Since circles obviously don't have vertices (to cache say the index), and the actual support point will change between frames it suddenly doesn't seem so clear. Does anyone have a good suggestion on how to go about caching a simplex that also involves a circle?



Scalable Vertex Transformations

22 August 2013 - 11:22 AM

So I've been working on the collision detection portion of my 2D physics engine (just finished implementing GJK with simplex caching), however throughout the process I've been curious about the most efficient and scalable means for transforming my polygon vertices. Currently I transform only the cached support vertices of my simplex into world coordinates at the beginning of GJK (to get an updated copy of the simplex assuming the polygons have moved between frames), and then I transform each newly added support vertex into world coordinates. This equates to roughly 12 or so transformations per candidate collision pairs.


Though this seems more scalable than transforming all vertices of each polygon per frame, doing it all up front would allow me to take advantage of parallelization (whether on the GPU or not).


Any suggestions on when to transform vertices; as needed vs batched in parallel (pre-computation and perhaps again at render).