Do these limitations still apply?

[moonshine]

Back in December 2006, the Erwin posted the following advice. Does the advice still apply to the latest version of Bullet? (it seems to me that Bullet is targeted at gaming and may not have enough accuracy for use in engineering simulations) :

a) Sizes of less than 0.2 are not supported.

b) Large mass ratios are not supported either (avoid 100kg on top of 1kg)

c) Don't use huge sizes for collision shapes (<10 units). If you need a larger static environment, use either triangle meshes with reasonable sized triangles (< 10 units), or a plane shape.

d) It's best to use meters for units: 1 meter = 1 unit. Then gravity around 10.

e) Keep object sizes 'reasonable' above 20 centimeter (in any direction) and at most 10 meters.

f) Never make the margin totally zero or too small (setCollisionMargin/setMargin), that's destined to fail. Best to use at least 0.02 - 0.05 units.

[Erwin Coumans]

Yes, it is best to stick to those limitations. Bullet primary target audience are game and movie industry professionals.

The latest Bullet 2.74 can deal with smaller objects, such as 0.05 centimeter for default gravity of -9.8 m/s^2 (assuming metric units). When you really want to use very small objects, you will need to use a smaller internal fixed timestep, for example:

Code: Select all

dynamicsWorld->stepSimulation(deltaTime,10,1./240.);

Thanks,
Erwin

[moonshine]

The latest Bullet 2.74 can deal with smaller objects, such as 0.05 centimeter

Just to be sure, that really is 0.05 cm (0.5 mm) ? (That's a big improvement on 0.2m (20 cm)!)

[Francescu]

Erwin,

Did you mean 5 centimeters as the object size?

With very small objects support in 2.74, can Bullet deal with very small collision margins? Could you tell me what the smallest margin I should be able to use then? (smallers than 0.01?)

Thanks in advance

The latest Bullet 2.74 can deal with smaller objects, such as 0.05 centimeter for default gravity of -9.8 m/s^2 (assuming metric units). When you really want to use very small objects, you will need to use a smaller internal fixed timestep, for example:

Code: Select all

dynamicsWorld->stepSimulation(deltaTime,10,1./240.);

Thanks,
Erwin

[Erwin Coumans]

Yes, I meant to say 5 centimeter, or 0.05 meter.

Bullet can deal with very small collision margins, but it is generally not a good idea for games: it harms performance (because deep penetrations use a much more costly algorithm), and it it less stable (contact information is more reliable when using a larger margin).

By default the margin is around 4 centimeter (0.04 meter), but for box, sphere it is already embedded _inside_ the shape. For convex hull shapes you can shift the vertices to move the margin inside the object. For static (non-moving) triangle meshes you can safely set the margin to zero, but for moving objects it is better to leave the default collision margin, and compensate the graphics object where necessary.

Thanks,
Erwin

[Francescu]

Thanks Erwin,

Yes I'm already compensating for the margin and moving it inside the objects - I will just change my margin of 0.010 back to 0.040 - I had used 0.10 as my objects were already fairly small but I do understand the impact of doing so now...I did set a margin of zero to static triangle meshes so it should be good.

Thanks for the complementary info. Cheers.

[jann.poppinga]

Are these limitations relevant to collision detection in static scenes, physics simulation, or both?

Also, I have a wide range of object sizes - both < 0.05 m and > 10 m. Is better to be under or over the ideal interval?

[jann.poppinga]

So?

[sparkprime]

I've yet to have any luck with 0.05m wide boxes but 0.05m halfwidth boxes aren't too bad. This is with 1/100 or 1/200 simulation time with a box or cylinder intersecting a btBVHTriangleMesh (gravity of 9.. I started experimenting with small shapes about 2 years ago and have played with a lot of tuning parameters including margins, erp, solver steps, and contact breaking threshold without any luck. This has recently come again because artists have started building smaller props like pizza boxes and trash can lids that are 0.05cm wide. Is there a bullet demo that demonstrates this working? Are there some broadphases that detect collisions quicker than other broadphases? I.e. these kind of tunneling problems typically happen when the pair is not in the cache I think. I am considering experimenting with scaling the world by a factor of 10.

[jann.poppinga]

@moonshine: I tried finding the post of Erwin's you're referring to, but to no avail. Did you mean on this forum or on the wiki or elsewhere? Are you sure it was Dec. 2006?

Edit: @Erwin What happens if you don't respect the size limitations?

[Erwin Coumans]

There are several issues:

a) Sizes of less than 0.2 are not supported.

Some improvements have been made in the collision detection to support smaller shapes. Make sure to adjust the collision margin accordingly, if you use very small objects.
When doing physics simulation using very small objects (<0.05 for any of its features), you might need to use a smaller internal timestep, for example 'stepSimulation(deltaTime,10,1./240.);

b) Large mass ratios are not supported either (avoid 100kg on top of 1kg)

This is a limitation of the constraint solver. We are in touch with some academics who are doing research in this area, so this mass ratio restriction might improve in the future.

c) Don't use huge sizes for collision shapes (<10 units). If you need a larger static environment, use either triangle meshes with reasonable sized triangles (< 10 units), or a plane shape.
d) It's best to use meters for units: 1 meter = 1 unit. Then gravity around 10.
e) Keep object sizes 'reasonable' above 20 centimeter (in any direction) and at most 10 meters.

Most important is to avoid huge size rations, say below 1:1000 if possible (0.1 versus 10 meter), to avoid floating point inaccuracy in the collision detection implementation (GJK, EPA, SAT etc). It is about the size of smallest and biggest features, so for static triangle meshes, it is the triangle size that matters, not the bounding box. The 1 meter = 1 unit recommendation is because some default settings are tuned with those units in mind.

f) Never make the margin totally zero or too small (setCollisionMargin/setMargin), that's destined to fail. Best to use at least 0.02 - 0.05 units.

This is mainly a collision detection performance and accuracy issue. Note that for static triangle meshes, the collision margin can be zero.
We haven't tested zero margins for moving objects, but improvements have been made to support smaller collision margins. If the margin of both objects is very small, the penetration depth algorithm might slow down calculations.

If you are running into specific issues, please attach a .bullet file to this issue, so we can have a look at it.
Thanks,
Erwin

[xiaoQ0903]

There are several issues:

b) Large mass ratios are not supported either (avoid 100kg on top of 1kg)

This is a limitation of the constraint solver. We are in touch with some academics who are doing research in this area, so this mass ratio restriction might improve in the future.

Hi Erwin! I am a student who is now doing some research about crane operator training systems! We use Bullet as the dynamics module of the training system. But the constraint is too elastic and becomes unstable when the mass ratio is too high. So I am doing some work to increase the mass ratio and stability of the constraint,I see that you are doing the same work,Would you give me some help or some advice? i.e...the link to the papers about this restriction or the blog of the academics who are doing research in this area......
Thanks very much!
-xiaoQ

[Erwin Coumans]

You might need a better constraint solver method than the Projected Gauss Seidel iterative LCP solver method used in many real-time physics engines such as Bullet, ODE etc.

See Kenny Erleben's work and his previous student Morten Silcowitz at http://iphys.wordpress.com, in particular http://iphys.wordpress.com/2010/06/08/a ... e-problems also implemented in Java in Jinngine at http://code.google.com/p/jinngine/sourc ... java?r=288

Other work by Jeff Trinkle/Binh Nguyen is at http://www.cs.rpi.edu/~nguyeb2/dVC3d

Thanks,
Erwin

[xiaoQ0903]

You might need a better constraint solver method than the Projected Gauss Seidel iterative LCP solver method used in many real-time physics engines such as Bullet, ODE etc.

See Kenny Erleben's work and his previous student Morten Silcowitz at http://iphys.wordpress.com, in particular http://iphys.wordpress.com/2010/06/08/a ... e-problems also implemented in Java in Jinngine at http://code.google.com/p/jinngine/sourc ... java?r=288

Other work by Jeff Trinkle/Binh Nguyen is at http://www.cs.rpi.edu/~nguyeb2/dVC3d

Thanks,
Erwin

Thanks Erwin!
I will take a closer look at the materials you have mentioned！I am not very familiar with java，Is there any resources which implement the nonsmooth-nonlinear-conjugate-gradient-method with C++ or C#？