penetration problem with plate falling on floor

Post Reply
loefje
Posts: 18
Joined: Thu May 28, 2009 10:43 am

penetration problem with plate falling on floor

Post by loefje »

Hi there,

I'm having some issues with blocks of ~0.7 by 0.7 by 0.1 meters
falling flat onto a floor from a height of 1.2 meters, with gravity
set to ( 0,0, -10 ), in my z-up world.

as you can see in the images taken from the simulation with
timestep 1.0/60.0 ( maxSubSteps = 20 ) the objects penetrate
the floor heavily: http://dynamica.org/PUB/blocks_fall_pro ... oblem.html

I've poored over the docs and this forum, but neither setting the timestep to 1/120
helps much, nor does anything I've tried so far, like setting m_world->getSolverInfo().m_eps
to 0.2 ( or 0.8 ), and playing with the other variables. What helped a little is using a BoxShape
for the floor, rather than a StaticPlane (?).

The only thing that really helps is scaling up the simulationworld by a factor of 10
so that the blocks are 7 meters on a side, but that is both a nuisance for hooking up
the simulation to my visualisation routines, and frustrating, since for instance
the ragdoll example uses similar dimensions to my original dimensions.

Could anybody give me a hint as to what's going on ?

Thanks a bunch.

Jochem van der Spek

ps setting the sizes to 7 meters, and doing 6 steps of
m_world->stepSimulation( 1.0 / 60.0 );
causes no interpenetration, but doing 1 step with
m_world->stepSimulation( 1.0 / 10.0, 6 );
does. From the docs however, i take the latter to result
in the same sequence of simulationsteps as the former, or
am I missing something ?
RBD
Posts: 141
Joined: Tue Sep 16, 2008 11:31 am

Re: penetration problem with plate falling on floor

Post by RBD »

Are blocks using btBoxShape collision shape as well?
loefje
Posts: 18
Joined: Thu May 28, 2009 10:43 am

Re: penetration problem with plate falling on floor

Post by loefje »

yes, they are.
RBD
Posts: 141
Joined: Tue Sep 16, 2008 11:31 am

Re: penetration problem with plate falling on floor

Post by RBD »

btBoxShape has a default internal (as opposed to hull/mesh shapes which add an external) collision margin of 0.04; so that margin * 2 for either side ~= 0.08, which leaves very little left from your 0.1 size and, especially since the margin can be considered approximate as it will vary based on the collision distance calculation (i.e. face to face vs vertex to face).

So your 0.1 size is probably too small, or your collision margin too large... but it's probably best to just make that object's dimension larger (or your btBoxShape anyhow, you could leave your "plate" the same size for visual purposes).
sparkprime
Posts: 508
Joined: Fri May 30, 2008 2:51 am
Location: Ossining, New York
Contact:

Re: penetration problem with plate falling on floor

Post by sparkprime »

Noone knows how to make bullet work properly at those kinds of sizes
SinisterMephisto
Posts: 20
Joined: Tue Sep 01, 2009 4:19 pm

Re: penetration problem with plate falling on floor

Post by SinisterMephisto »

I also have this problem with cylinders. they dont fall through the world but it seems collision detection only occurs at the centre of the cylinder so it spin on the floor.
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: penetration problem with plate falling on floor

Post by Erwin Coumans »

Using a btBoxShape of 0.7,0.7,0.1 shouldn't be a problem. Attached is a modified Bullet/Demos/BasicDemo/BasicDemo.cpp and precompiled Win32 executable that just works fine. Can you verify this?

Can you reproduce the problem in the Bullet/Demos/BasicDemo?
Thanks,
Erwin
Noone knows how to make bullet work properly at those kinds of sizes
??
I also have this problem with cylinders. they dont fall through the world but it seems collision detection only occurs at the centre of the cylinder so it spin on the floor.
This must be a different problem. Please check if CcdPhysicsDemo works fine, and compare your setup.
Attachments
BasicDemo.zip
(334.23 KiB) Downloaded 276 times
sparkprime
Posts: 508
Joined: Fri May 30, 2008 2:51 am
Location: Ossining, New York
Contact:

Re: penetration problem with plate falling on floor

Post by sparkprime »

Erwin Coumans wrote:Using a btBoxShape of 0.7,0.7,0.1 shouldn't be a problem. Attached is a modified Bullet/Demos/BasicDemo/BasicDemo.cpp and precompiled Win32 executable that just works fine. Can you verify this?
As I understand it, his boxes are half that size in all dimensions
Noone knows how to make bullet work properly at those kinds of sizes
??
It's the standard problem with small objects -- they don't behave realistically. This is my game engine with boxes of his size:

http://www.youtube.com/watch?v=O-tq0XQz990
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: penetration problem with plate falling on floor

Post by Erwin Coumans »

When using a box of .35x.35x0.05 the collision margin needs to be reduced, and a smaller timestep is required. A smaller timestep is necessary, because in one simulation frame, the object travels too far, relative to its dimension. When using 0.02 margin and an internal timestep of 1./240. things should be fairly stable.

See attached BasicDemo.cpp and precompiled Win32 executable. If this doesn't help, please provide a reproduction case.
Thanks a lot,
Erwin
Attachments
BasicDemo.zip
(272.32 KiB) Downloaded 391 times
sparkprime
Posts: 508
Joined: Fri May 30, 2008 2:51 am
Location: Ossining, New York
Contact:

Re: penetration problem with plate falling on floor

Post by sparkprime »

That's interesting, my margin of 0.01 was too small... With your margin it's much better. What made you suggest 0.02?

It's still not as good as scaling everything up though. To some extent increasing the frequency is the right thing to do, but you have to increase it to ever more absurd values to make it work the smaller and smaller the objects become.

With .3 x .3 x .3 boxes at normal gravity, you can just about get away with 60hz

with .1 x .1 x .1 boxes at 1/3 of normal gravity, you can't get away with 60hz -- the boxes just sit there dancing away...

So clearly there is something more going on than just these values needing to be kept in ratio.

I think Bullet has improved since I did this though:

http://www.bulletphysics.com/Bullet/php ... f=9&t=2535
Post Reply