Page 1 of 1
How to fight "dancing" box syndrom?
Posted: Sun Oct 18, 2009 6:12 pm
by Dragonlord
Something which I'm having troubles with since I started using Bullet and this is what I call the dancing box syndrom. I have for example a small box around 0.2 units in size. Now this box rests on a larger box let's say 1.0 units in size. The larger box has a larger mass than the smaller just to avoid the mass ratio problem but still kept close to each other for testing. Now the box starts out in the simulation right above the larger box touching it. What can be observed is the box jittering on the larger box. Now what troubles me is to figure out how to best prevent the box from dancing. After all it's a simple situation: a smaller box shape on a larger box shape. From a mathematical point of view there's a fully stable position for this problem but Bullet keeps the box dancing around not even triggering deactivation.
What can be best done in such a situation? How in general can shapes be prevented from dancing around too much? Is this a penetration recovery issues or solver issues in general?
Re: How to fight "dancing" box syndrom?
Posted: Sun Oct 18, 2009 6:25 pm
by ngbinh
For smaller box resting on larger box, it's important to have 4 contacts points generated each frame. Have you tried to see how many contacts are there between them?
There are many factors that affect stable box stacking. You may have to be more precise.
Anyway, methods like Bullet may be able to simulate about 20+ boxes stacking (I remembered someone did that). If you want more, you may have to use different method. Refer to my post here:
http://www.bulletphysics.com/Bullet/php ... f=4&t=4101
Re: How to fight "dancing" box syndrom?
Posted: Sun Oct 18, 2009 10:55 pm
by Dragonlord
It's only two box stacking in this example and as mentioned a simple 0.2 unit box on a 1.0 unit box, nothing fancy. I don't know how to be more specific in that case so you might want to give me a pointer there.
Re: How to fight "dancing" box syndrom?
Posted: Mon Oct 19, 2009 12:14 am
by marcimatz
I noticed something similar when one of the boxes (or both) is a triangular mesh instead of a "pure" box (i.e. btBoxShape). If both are of type btBoxShape, it is very stable in my experience. Otherwise have you tried to scale both boxes up (e.g. by a factor 10) and see what happens then?
Re: How to fight "dancing" box syndrom?
Posted: Mon Oct 19, 2009 11:19 am
by ngbinh
Dragonlord wrote:It's only two box stacking in this example and as mentioned a simple 0.2 unit box on a 1.0 unit box, nothing fancy. I don't know how to be more specific in that case so you might want to give me a pointer there.
Have you checked the number of contacts? That'd be the first thing I do in your case.
Re: How to fight "dancing" box syndrom?
Posted: Tue Oct 20, 2009 6:31 pm
by Dragonlord
Could it be due to margins? I don't know right now what margins are set by default but with a 0.2 unit object could the margins cause the contact points to vary in number causing the dancing? I don't know exactly where to intercept those control points to figure out the problem.
Re: How to fight "dancing" box syndrom?
Posted: Thu Oct 22, 2009 1:10 am
by Mattg
I think it could be margins, just try with a 1.0 and 5.0 unit box combo instead.
Re: How to fight "dancing" box syndrom?
Posted: Thu Oct 22, 2009 5:16 pm
by Dragonlord
A larger margin? I expected to use a smaller margin. Why has it to be larger?
Re: How to fight "dancing" box syndrom?
Posted: Mon Oct 26, 2009 6:27 pm
by Erwin Coumans
Please reproduce the problem in the Bullet BasicDemo, so we can have a look at it.
(attach the zipped BasicDemo.cpp in this forum, or in the
google issue tracker)
Thanks,
Erwin
Re: How to fight "dancing" box syndrom?
Posted: Wed Oct 28, 2009 4:24 pm
by Dragonlord
Sorry, I'm rather time constraint right now. I'll try to reproduce it in the BasicDemo once I get some free time. Currently it's me running after time so I can't do it in the next couple of days.