I promised b34r I'd post a new demo of my physics stuff - so http://www.rowlhouse.co.uk/jiglib None of the demos use a shock step, so consequently they actually feel a little bit slower than my previous demo versions. The reason they don't use it (and this is quite amusing) - it only worked quite nicely before because it had a bug in it, and now I fixed the bug it produces significant artifacts! I want to fix it properly... You can configure the demos by modifying the config files - if you want to play around or if they run too slowly on your machine. Anyway, I made a whole load of changes. See the readme.txt for how to use the demo. The significant changes to the algorithm are these: 1. During collision detection penetration depth is recorded at each point - but the penetration depth (PD) is calculated (in some cases estimated) for the beginning of the collision sweep. This means that during a collision -ve penetration depths get recorded. Also, the position gets recorded relative to the positions of the objects at the beginning of the collision sweep. 2. collision/contact impulses all get applied to the objects in the position they were at the beginning of the step. 3. If PD > 0 then an extra term is added to the impulse calculation to make the penetration relax to 0 over a number of timesteps. 4. If PD < 0 and the elasticity = 0 (actually, that's not quite the criterion I use, but anyway...), then an extra term is added to the impulse calculation to make the penetration relax to 0 over a number (1) of timesteps - i.e. using the same code as in 3. What this means is that if there is an inelastic collision between an object and the world between T and T + dt then: 1. at time T an impulse gets applied that slows the object down just enough so that at time T + dt it will be touching the world. 2. at time T + dt another impulse gets applied that brings the object to a complete stop. So - no more objects stopping short of the ground when they fall, etc. Lots more to do to make it useful - at the very least I need to refactor the collision system (currently you can't have composites of different primitives, which is a really dumb thing!), and b34r demonstrated how excellent contact caching can be. I'm anticipating this will solve the drift that you can see in the walls - apart from the drift there's very little jitter. Edit: Yes, I know the ragdoll's limbs separate from his body if you pick him up and swing him around hard, but then I say the same would happen to you!

Nice work. To me it doesnt feel slower than your previous demo'but I probably haven't looked at it as much as you did ;-)

Cheers
airo

f'in awesome dude!

Quote:Original post by b34r
edit: Just played a bit more, removing deactivation and setting physic frequency to 30hz and it's really

stable...

I wanted to improve the behaviour outside of the 1g, 60Hz, 1m box range. For example, it handles boxes with sizes ranging from 2cm to 5m. More than that the mass is so big the impulse calculation fails with floats. At the small end I think I have 1cm hard-coded in the collision system somewhere (e.g. for combining contact points) - I'll root it out! It can be better, but it's certainly a lot better in this regard than the older jiglib.

Quote:Original post by sbroumley
Can I ask how you incorporated SSE instructions? I've just started tinkering with SSE and so far I've been barely able to get any speedups. Do you just set .net compiler options appropriately or did you add some special vector simd class code?

Really just compiler options. However, I've also unrolled some of the vector stuff to make it more amenable to compiler optimisations. And I've avoided operator overloading as much as possible in the collision processing code (which is the big performance spike).

I started using valgrind to look at the cache performance too - I found that by swapping the order of two members in my collision report structure I got a speedup of around 5% (in the case with jigtest.cfg and sleeping disabled). I'm going to look into prefetching the collision structure into cache before it gets accessed (i.e. whilst processing the previous collision).