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 ?
penetration problem with plate falling on floor
-
- Posts: 18
- Joined: Thu May 28, 2009 10:43 am
-
- Posts: 141
- Joined: Tue Sep 16, 2008 11:31 am
Re: penetration problem with plate falling on floor
Are blocks using btBoxShape collision shape as well?
-
- Posts: 18
- Joined: Thu May 28, 2009 10:43 am
Re: penetration problem with plate falling on floor
yes, they are.
-
- Posts: 141
- Joined: Tue Sep 16, 2008 11:31 am
Re: penetration problem with plate falling on floor
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).
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).
-
- Posts: 508
- Joined: Fri May 30, 2008 2:51 am
- Location: Ossining, New York
Re: penetration problem with plate falling on floor
Noone knows how to make bullet work properly at those kinds of sizes
-
- Posts: 20
- Joined: Tue Sep 01, 2009 4:19 pm
Re: penetration problem with plate falling on floor
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.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: penetration problem with plate falling on floor
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
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
This must be a different problem. Please check if CcdPhysicsDemo works fine, and compare your setup.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.
You do not have the required permissions to view the files attached to this post.
-
- Posts: 508
- Joined: Fri May 30, 2008 2:51 am
- Location: Ossining, New York
Re: penetration problem with plate falling on floor
As I understand it, his boxes are half that size in all dimensionsErwin 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?
It's the standard problem with small objects -- they don't behave realistically. This is my game engine with boxes of his size:??Noone knows how to make bullet work properly at those kinds of sizes
http://www.youtube.com/watch?v=O-tq0XQz990
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: penetration problem with plate falling on floor
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
See attached BasicDemo.cpp and precompiled Win32 executable. If this doesn't help, please provide a reproduction case.
Thanks a lot,
Erwin
You do not have the required permissions to view the files attached to this post.
-
- Posts: 508
- Joined: Fri May 30, 2008 2:51 am
- Location: Ossining, New York
Re: penetration problem with plate falling on floor
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
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