The split impulse is cached too. For position projection these are two independent solver phases. I use position projection in Rubikon since it gives the best quality at reasonable performance in my opinion. My experience with split impulse is that it does work ok with contacts, but not so good with joints. Erin did a good write up of the stabilization methods here (see "Position Correction Notes"):

https://github.com/erincatto/Box2D/blob/master/Box2D/Box2D/Dynamics/b2Island.cpp

Pseudo velocities is essentially the split-impulse. I use the (full) NGS which is the two solver phases.

I compiled four box scenes for reference if anyone wants to compare:

https://dl.dropboxusercontent.com/u/55377219/Stacking.rar

- Use the arrow keys (up/down) to iterate through the four scenes

- Use ALT and LMB to move the camera (kind of like Maya)

- Use ALT and mouse wheel to zoom

- Use 'R' to reset the scene (camera position is maintained)

- Use 'P' to pause/unpause simulation

- Use SPACE to single step simulation when paused

- Use LMB to pick up objects in the scene

I also enabled the contact visualization. A green contact points means I was able to match the contact point with a contact point from the previous frame (coherency). A red contact point means this is a new point. If your contact points flicker like a Christmas tree this usually means you have a problem. This is a great way to identify problems with warmstarting. Pausing the scenes and single step helps visualizing this.

The boxes are 1x1x1 with density 1000 kg/m^3. Sleeping is disabled. The solver uses 8 velocity and 2 position (NGS) iterations. The solver is essentially the same as in Box2D, but I use a different friction model which is unpublished so far. But this helps with stability and performance quite a bit. So it is a little bit different from what we discussed here.

HTH,

-Dirk

You should drop them and/or also test slightly penetrating. I would not expect perfectly aligned geometry that you get from your artists. The engine should be able to deal with reasonable imperfections and handle them gracefully.

I would add single stepping and the contact point coloring above. This way you can easily inspect if you get all points and if the warmstarting works.

But your stuff looks already great!

Hey sorry for bothering you again, is there a general way to build a list of contacts for a pair of shapes if the collision detection only gives out one contact at a time? I.e. for a box-box collision I only report the biggest penetration, along with a feature index, and then combine it with contacts from the previous frames. It has case-specific logic for discarding the list if the collision type changes (i.e. no face-point contacts if we detected an edge-edge collision), so I'm looking for a more general approach, especially if I want to implement arbitrary polytopes in the future. Also I'd image its possible that my algorithm can end up with 8 contacts for a pair of boxes eventually.

You mean building an incremental manifold over several frames? You basically would find the new point and add it to a persistent manifold and then you would need to confirm the old points using some heuristic. The easiest heuristic would be some distance threshold. If you have a box sliding down the plane this will create wobble since the contact points would be still valid, but you would loose them because they get invalidated. They are all kind of problems with this approach. The major problem with incremental manifolds is that objects can fall out of the world. Which is a huge problem for games since this can lead to bugs where you would not be able to finish a level.

The alternative is the full manifold using clipping techniques. As you observed correctly this can lead to many contact points (e.g. 8 points for box vs. box). The trick is to reduce the contact points to some fixed number. E.g. in my experience 4 points are enough for stable and fast simulations.

I actually talked quite a bit about this at the GDC this year. You can download my presentation "Robust Contact Creation for Physics Simulation" here: http://www.valvesoftware.com/company/publications.html

I happily answer questions regarding the presentation, but please open a new thread so it would be discoverable for others as well.

Cheers,

-Dirk

You mean building an incremental manifold over several frames? You basically would find the new point and add it to a persistent manifold and then you would need to confirm the old points using some heuristic. The easiest heuristic would be some distance threshold. If you have a box sliding down the plane this will create wobble since the contact points would be still valid, but you would loose them because they get invalidated. They are all kind of problems with this approach. The major problem with incremental manifolds is that objects can fall out of the world. Which is a huge problem for games since this can lead to bugs where you would not be able to finish a level.

Actually sliding down a plane would work fine if I use local body coordinates to recreate contacts, or something like "vertex #5 vs face #3" (which is what I'm doing right now, basically each contact has a callback that generates pos1/pos2/normal in each frame based on some feature index).

I'll give it a read later today, thanks.