Physics and Lowpassing

Please don't post Bullet support questions here, use the above forums instead.
Post Reply
goruka
Posts: 27
Joined: Wed Nov 07, 2007 12:49 am

Physics and Lowpassing

Post by goruka »

Hi! I have a question... so far i have been playing around with physics and got a somewhat working implementation.. however, i have some doubts..
So far the implementation seems to work fine, I implemented the normal impulsed based system with iterative solver, and i'm doing velocity accumulation of contacts with warmstarting, and a little position correction to avoid objects to jitter when being one on top of another.

This works fine for most cases, but in some cases, i still have some problems, for example, an object moving with another on top (both with full friction). In this case, the object on top seems to be doing some little jittering which seems to happen due to friction <-> velocity feedbacking itself. the object stays in place, but vibrates very very sightly. Is this to be expected or am I doing it wrong?

I thought i could simply add a lowpass to the "visual" output (translation/rotation) to compensate for this, but i'm still not sure if this would be the best method, because it may be a bug (or a better method?)

Well, thanks for reading this!
Erin Catto
Posts: 316
Joined: Fri Jul 01, 2005 5:29 am
Location: Irvine
Contact:

Re: Physics and Lowpassing

Post by Erin Catto »

How are you matching contacts for warmstarting? Is the translation disrupting warm starting?

Are you warm starting friction and normal impulses?
goruka
Posts: 27
Joined: Wed Nov 07, 2007 12:49 am

Re: Physics and Lowpassing

Post by goruka »

Erin Catto wrote:How are you matching contacts for warmstarting? Is the translation disrupting warm starting?

Are you warm starting friction and normal impulses?
Ah, I found a bug computing the inertial tensor :( Works great now..

About warm starting though, I've seen in many implementations that the exact contact features (which edge, tri, point,etc) are saved and compared for warmstarting.. I'm finding this a bit of a hassle to implement (code gets a bit more complex than what i'd wish) .. so I wanted to ask..

Is there any reason why I couldn't just save the contact points in untransformed object space for each contact, and then comparing against those when getting the new set of points, instead of the feature info? (I mean, other problem than having to compute the inverse transform of the objects for each frame)

Cheers!

Oh, also, I ported your work in Box2D lite to 3D, for learning mainly, is it ok if i clean it up and release it?
Erin Catto
Posts: 316
Joined: Fri Jul 01, 2005 5:29 am
Location: Irvine
Contact:

Re: Physics and Lowpassing

Post by Erin Catto »

Is there any reason why I couldn't just save the contact points in untransformed object space for each contact, and then comparing against those when getting the new set of points, instead of the feature info? (I mean, other problem than having to compute the inverse transform of the objects for each frame)
It is a bit tricky to store features. I improved this in the current version of Box2D (1.4.3 http://box2d.org). The idea is to store the reference face, the clipped edge, and 1 or 2 for the first or second vertex on the clipped edge.

The advantage of storing features is that you don't need to use any tolerances.
Oh, also, I ported your work in Box2D lite to 3D, for learning mainly, is it ok if i clean it up and release it?
This would be great. Please post a link on the links forum.
goruka
Posts: 27
Joined: Wed Nov 07, 2007 12:49 am

Re: Physics and Lowpassing

Post by goruka »

Erin Catto wrote:
The advantage of storing features is that you don't need to use any tolerances.
Ah, I see.. my main issue is that i find a bit messy to store feature pairs in 3D, as i have to store faces, edges and points, and when clipping a face support by a face support (by calculating clip planes), i need to turn face info into edge info and vertex info, so my support structure gets really big and complicated, as it does the clipping algorithm, I was thinking that by just storing vertex info in untransformed object coordinates, and also some direction normal for predicting, i could get away with it...
Will give it a check!
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Physics and Lowpassing

Post by Erwin Coumans »

goruka wrote:
Erin Catto wrote:
The advantage of storing features is that you don't need to use any tolerances.
Ah, I see.. my main issue is that i find a bit messy to store feature pairs in 3D, as i have to store faces, edges and points, and when clipping a face support by a face support (by calculating clip planes), i need to turn face info into edge info and vertex info, so my support structure gets really big and complicated, as it does the clipping algorithm, I was thinking that by just storing vertex info in untransformed object coordinates, and also some direction normal for predicting, i could get away with it...
Storing vertices in untransformed object coordinates (and then checking the distance of their projection onto the separating normal in worldspace against a tolerance) is what Bullet uses. The advantage is that it supports non-polyhedral shapes, like cylinders and cones without the need to have features, disadvantage is use of tolerances. But we use tolerances anyway to determine wether a contact is valid or not.
See btPersistentManifold::refreshContactPoints

Clipping planes and checking features in 3D is implemented in an (inactive) Bullet contribution, see Hull::AddContactsHullHull. Jan Bender's IBDS physics library adds a similar clipping approach to Bullet for convex polyhedra.

Hope this helps,
Erwin
DannyChapman
Posts: 84
Joined: Sun Jan 07, 2007 4:29 pm
Location: Oxford, England
Contact:

Re: Physics and Lowpassing

Post by DannyChapman »

I use local space positions too and it works fine and is very simple.

Also, I woke up this morning thinking how trivial it would be to use this to add an additional position based friction constraint that would be enabled when you detect that static friction _should_ be preventing movement (even though it might not with an iterative solver).
Dirk Gregorius
Posts: 861
Joined: Sun Jul 03, 2005 4:06 pm
Location: Kirkland, WA

Re: Physics and Lowpassing

Post by Dirk Gregorius »

I tought about the position correction for friction as well. For an impulse solver you just need to verify if the accumulated friction impulse was clamped against the accumulated normal impulse. My guts feeling is that the impact is not too big though. For central friction I realized more friction artifacts then for per-point friction, so it might help there.

Maybe you can share your experience with us when you try it in JigLib...


Cheers,
-Dirk
neil.simpson05
Posts: 2
Joined: Fri Jan 25, 2008 10:01 am

Re: Physics and Lowpassing

Post by neil.simpson05 »

Hi!

Just see that site, u will get more Info........

http://www.iop.org/EJ/article/1742-6596 ... 0Ozk2wi7Kg
Post Reply