Jump to content
  • Advertisement
Sign in to follow this  
MrRowl

JigLib physics - new version

This topic is 4837 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
It looks very good and it's not slow, even on my laptop (pentium M@1.76).
Really good work :).

I didn't spot any odd behavior, there's a bit of drifting in stacks but really nothing bad (imho). Well, I hope I can find time to write some more collision primitive :) you seem to have a nice collection already.

About contact caching, I did get a small improvement with the cache only (ie. correcting contacts positions) but the biggest improvement came from handling static contacts with a point/point constraint.

However, I think that you have much less drifting than I do without contact caching + contact constraint so you may not even need it.
Looks quite useable to me already, you just need composite collision shapes. Not a big deal ;).

Good job again!
PS: I really like the colors of the huge pyramid in the AVI :).

edit: Just played a bit more, removing deactivation and setting physic frequency to 30hz and it's really stable... amazing...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by MrRowl
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.


I'm having troubles especially with low frequencies. Above 50hz centimeter wide bodies work acceptably, at 30hz: no luck. That jittering I can't get rid of. When I get a chance to, I'll add contact depth sorting and reimplement a working contact averaging.

Btw, are you using contact averaging or simply sequencial processing?

Share this post


Link to post
Share on other sites
this is very nice, on my athlon 1700+ it takes some slow time at start to stabilize the objects, but then it is ok (until i hit the wall hard with the car)
it would be great if you would make this a cross-platform and language library like newton dynamics engine is, that means you shouldn't expose the C++ objects out of the library, but just provide nice functions..

Share this post


Link to post
Share on other sites
Nice job Danny. Soon you'll be able to rename it Jiggy-less-Lib :)

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?

cheers
-Steve.

Share this post


Link to post
Share on other sites
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).


Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!