# (** it's the mailman **) Physics junkie...

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

## Recommended Posts

Hi everybody, <edit: cf. update in last post...> -Direct link- Any comments, implementation warning, advices, etc... are as usual very welcome. Note: The default projectile is the ball wich is very light so you most certainly want to switch to something else using Ctrl. Middle click allows spawning a lot of bodies at once but don't use that with the chair... please ;). [Edited by - b34r on July 30, 2005 10:16:31 AM]

##### Share on other sites
In case you are interested I updated my old archive with the current version link.

It now has Coulomb friction (finally :)) and much better handling of static contacts. There's contact caching too but it's fairly slow at the moment. The nice thing is, bodies can finally cleanly travel on top of others and it's pretty much essential for a game physic engine.

While all the systems now support swept tests only the sphere ones are swept for now (and the OBB/sphere swept test is a nasty hack ;)). OBB/poly can act strange because the contact generation is very bad.

##### Share on other sites
The behaviour is pretty nice, though as you say a bit slow. I like how the contact caching/preservation elinates drift. I think your contacts are a bit too sticky at times though - I've seen a couple of oddities - and have a screenshot of one in particular if you want it - where a box is suspended on the edge of a jenga block - like this (from the side):
           /         /         X /        \  ______\        /|      | \    /|      |   \/|      |

with deactivation disabled - there must be an erroneous cached contact around X that is keeping it there because it is slightly springy.

Edit: fix ascii piccy!

Edit again: gave up on the ascii art - gamedev keeps messing it up!!

[Edited by - MrRowl on July 24, 2005 10:49:44 AM]

##### Share on other sites
Quote:
 Original post by MrRowlThe behaviour is pretty nice, though as you say a bit slow. I like how the contact caching/preservation elinates drift. I think your contacts are a bit too sticky at times though - I've seen a couple of oddities - and have a screenshot of one in particular if you want it - where a box is suspended on the edge of a jenga block - like this (from the side): / / X / ______\ /| | \ /| | \/| | with deactivation disabled - there must be an erroneous cached contact around X that is keeping it there because it is slightly springy.

Thanks :), I'm trying to find some non-overkill method to speed up cache lookups. I managed that sticky thing too :). I don't really get why it happens. But it may happen because I do not break static contacts when they are only slightly separating. The drifting, that is still occuring nevertheless, would break them all the time if I didn't.

I think I should (but don't) update the cached contact normal in order to account for this kind of hinge behavior. This might very well be the cause of the problem now that I think of it \:...

I'm not satisfied by this "sticky" trick but even if I was to solve contacts simultaneously jittering would not stop as it is caused by penetration anyway. I'm using time warping now so I guess the next step toward improved stability are definitively swept tests. I expect that they should generate a lot less wrong contacts than a discrete method.

I was wondering, are you treating static contacts in a special way in Jiglib? I played with it a bit and found that even with no deactivation your jittering is really small (well at least compared to my stuff ;)). You don't suffer too much from the "box sitting on the top corner of another box" problem either. Without special treatment for static contacts this configuration was incredibly unstable for me... Maybe shock propagation helps.

Do you know how iterative, robust solver handle penetration? I think the extra impulse is a fine solution but heck... What kind of trick do they use to make everything that stable. And, anybody can explain to me what is the "projection method" for correcting penetration?

Thanks!

##### Share on other sites
Quote:
 Do you know how iterative, robust solver handle penetration? I think the extra impulse is a fine solution but heck... What kind of trick do they use to make everything that stable. And, anybody can explain to me what is the "projection method" for correcting penetration?Thanks!

The "projection method" can be applied when using Verlet integration, for example in a mass-spring-engine, i.e. the velocity of a single mass point is represented as delta r. (r - r0).

You can then move a point out of the obstacle by simply setting r = [some point outside or on the surface of the obstacle]

tmp = r;        r += (((r - r0) * (dt / dt0)) + ((F / m) * dt * dt)); r0 = tmp;dt0 = dt;

-cmor

##### Share on other sites
Good one again. I can't seem to switch to something heavier by pressing control. I definetaly want something heavier, maybe make this default?

How did you implement Coulomb friction? I would like to do this for my 2d domino, like yours in 3d. Is it the one described by MrRowl?

##### Share on other sites
Quote:
 Original post by cmorThe "projection method" can be applied when using Verlet integration, for example in a mass-spring-engine, i.e. the velocity of a single mass point is represented as delta r. (r - r0).You can then move a point out of the obstacle by simply setting r = [some point outside or on the surface of the obstacle]*** Source Snippet Removed ***-cmor

Okay, I see. That's equivalent to the extra impulse method. There's still room for overshooting the correction so you need (a preferably tweakable :() relaxation constant.

Quote:
 Original post by AiroGood one again. I can't seem to switch to something heavier by pressing control. I definetaly want something heavier, maybe make this default? How did you implement Coulomb friction? I would like to do this for my 2d domino, like yours in 3d. Is it the one described by MrRowl?

Thanks,
Sorry I did not specify, left-ctrl only, hope that fix it :).

The friction is done pretty much the same yes, I compare the length of the normal relative velocity vector (times the static_friction coefficient) against the tangential velocity vector magnitude. If the tangential velocity is greater, then the static contact breaks. Since I did not do any serious checks I'm 100% sure it's physically wrong tho ;).

A more correct way, as I understand it, involve the depth of penetration instead of the normal relative velocity. This should make bottom elements of stacks friction higher than top elements.

##### Share on other sites
it runs like ass on this machine, thats for sure. (~2ghz?)

ill try it later on my laptop, which seemed to run it fine, sounds promising
!

##### Share on other sites
Quote:
 Original post by AiroGood one again. I can't seem to switch to something heavier by pressing control. I definetaly want something heavier, maybe make this default? How did you implement Coulomb friction? I would like to do this for my 2d domino, like yours in 3d. Is it the one described by MrRowl?

Quote:
 A more correct way, as I understand it, involve the depth of penetration instead of the normal relative velocity. This should make bottom elements of stacks friction higher than top elements.

The force Coulomb law states that the maximum static friction force is u_s*Fn.
If Ft > u_s*Fn then dynamic friction is applied. For a stack of boxes the bottom ones have a larger normal force due to the weight on top, so the maximum amount of static friction force is higher.

I'll try the impulse method on my code, if only weekends were longer ;-)

##### Share on other sites
Quote:
 Original post by Eelcoit runs like ass on this machine, thats for sure. (~2ghz?)ill try it later on my laptop, which seemed to run it fine, sounds promising!

Yeah I know, 2ghz shouldn't be that slow tho... If you have an old gfx card (<= GeForce2) make sure you disable triadic operators (F3) as it is reaaaaally slow :).
There's a lot of new/delete going on when stacks collapse and the brute force cache lookup is not free either \:. The new/delete problem is trivial to solve but I'm not sure what kind of structure would be best fitted to this kind of spatial query. A KD-Tree might quickly get very unbalanced as contacts appear and disappear pretty much randomly all over the place...

Maybe I'll just make some silly 1-axis ordered list and see if a divide and conquer lookup gives good enough improvements. But yeah, it's a pain right now.

1. 1
Rutin
32
2. 2
3. 3
4. 4
5. 5

• 12
• 9
• 9
• 9
• 14
• ### Forum Statistics

• Total Topics
633314
• Total Posts
3011324
• ### Who's Online (See full list)

There are no registered users currently online

×