Real-Time Physics Simulation Forum

I have read the posts about size restrictions on objects etc. In my game the bounding box size of some objects can go down to 0.02 or so in one axis. My understanding is that this is too small to be reliable. So I was thinking that I could scale up everything for bullet by 10 (as an example). Is my thinking right here?
Scaling bounding volumes is easy. Scaling the actual triangles would be a pain though and having an extra copy of every mesh scaled for bullet is no good.
One could of course rescale the whole game world but that doesn't really sound very appealing either.
Any other ideas on how to solve this?

Also what is the minimum size I should stay above? Does this only relate to bounding volumes or is the size of individual triangles important too?
I want to make sure I understand the problem before I spend time solving it

Ken

kend wrote:I have read the posts about size restrictions on objects etc. In my game the bounding box size of some objects can go down to 0.02 or so in one axis. My understanding is that this is too small to be reliable. So I was thinking that I could scale up everything for bullet by 10 (as an example). Is my thinking right here?
Scaling bounding volumes is easy. Scaling the actual triangles would be a pain though and having an extra copy of every mesh scaled for bullet is no good.
One could of course rescale the whole game world but that doesn't really sound very appealing either.
Any other ideas on how to solve this?

Also what is the minimum size I should stay above? Does this only relate to bounding volumes or is the size of individual triangles important too?
I want to make sure I understand the problem before I spend time solving it

Ken

The minimum objectsize is mostly for dynamic objects, so I wouldn't worry about static triangle meshes. It's more about dynamic convex hull/box/sphere/cylinder/cone.

This 'minimum size requirement' is due to the collision margin and contact point reduction. Those (independent) values are currently default set at around 0.04 units.

1) collision margin (collisionShape->SetMargin()): this value is to avoid doing costly penetration depth calculation, and also to guarantee a valid normal (otherwise touching objects have undefined contact normal). Don't make the value too small, otherwise performance degrades (due to slow penetration depth approximation), make it not too big, because objects will be 'rounded'. Effectively, objects can never be smaller then this margin.

2) gContactBreakingTreshold, this value is related to contact reduction (points closer then this value are regarded 'the same', and also contact breaking (if contacts are further away then this distance, they are removed). Those values are tuned, so it works nice with default gravity and timestep and object sizes. Make them too small, and you loose points and introduce jitter. Make it too big, and all points get reduced into 1.

So it's best not to touch those values unless necessary.

Do you require very thin moving boxes?
Thanks,
Erwin

PS: see also this link, Halo 2, Havok 2
'don't make anything smaller then a PC Monitor'

http://www.bungie.net/News/TopStory.asp ... lo2feature

Erwin Coumans wrote:The minimum objectsize is mostly for dynamic objects, so I wouldn't worry about static triangle meshes. It's more about dynamic convex hull/box/sphere/cylinder/cone.

This 'minimum size requirement' is due to the collision margin and contact point reduction. Those (independent) values are currently default set at around 0.04 units.

Do you require very thin moving boxes?
Thanks,
Erwin

Yes, dynamic boxes is what I meant. Most of the boxes are "large" but I can see the need for some that are thin. I could of course increase the thickness of the bounding box but then it will look like the actual object is floating above ground. In fact it already does. The actual object is floating about 0.02 - 0.03 units above ground. Is this related to the minimum value (0.04) then?

This thin box object jumps and jitters quite a lot when dropped on ground before it finally settles down. Is this due to the small size?

Regarding step size. What is the best time step in Bullet? I'm currently using 0.01. Would 0.02 be better? Does it matter?

Thanks,
Ken

kend wrote:

Erwin Coumans wrote:The minimum objectsize is mostly for dynamic objects, so I wouldn't worry about static triangle meshes. It's more about dynamic convex hull/box/sphere/cylinder/cone.

This 'minimum size requirement' is due to the collision margin and contact point reduction. Those (independent) values are currently default set at around 0.04 units.

Do you require very thin moving boxes?
Thanks,
Erwin

Yes, dynamic boxes is what I meant. Most of the boxes are "large" but I can see the need for some that are thin. I could of course increase the thickness of the bounding box but then it will look like the actual object is floating above ground. In fact it already does. The actual object is floating about 0.02 - 0.03 units above ground. Is this related to the minimum value (0.04) then?
This thin box object jumps and jitters quite a lot when dropped on ground before it finally settles down. Is this due to the small size?

A long thin box below the collision margins is not well supported, so best avoided if possible: having any side of smaller then say 0.20 units is highly unrecommended.
Ignoring that will result in jitter and failing simulation, unfortunately.

The 'floating' is likely because the trianglemesh has a margin. There is some improvements possible, like setting the margin for static trianglemeshes to zero (setMargin). It will hurt performance for penetrating cases. Please don't do this for dynamic objects. Box has compensation for the margin, which means that there is no gap between stacking boxes. In the future this will also be added for convex hull objects. Sphere's use their radius for margin, so no gap either. Cylinders and Cone have some gap.

kend wrote: Regarding step size. What is the best time step in Bullet? I'm currently using 0.01. Would 0.02 be better? Does it matter?
Thanks,
Ken

A small fixed timestep is best. Most of my demos use 60 Hertz (1/60). 0.01 is smaller then 0.02, so it's better. Then, choose the number of iterations for the constraint solver in the range 4 to 10.

Erwin Coumans wrote:A long thin box below the collision margins is not well supported, so best avoided if possible: having any side of smaller then say 0.20 units is highly unrecommended.
Ignoring that will result in jitter and failing simulation, unfortunately.

The 'floating' is likely because the trianglemesh has a margin. There is some improvements possible, like setting the margin for static trianglemeshes to zero (setMargin). It will hurt performance for penetrating cases. Please don't do this for dynamic objects. Box has compensation for the margin, which means that there is no gap between stacking boxes. In the future this will also be added for convex hull objects. Sphere's use their radius for margin, so no gap either. Cylinders and Cone have some gap.

Ouch. A min size of 0.2 units is pretty big in my "world". So the min size is about 10x the tolerance values. Maybe I will have to look into scaling the whole world somehow.

I'll look into the triangle mesh margin. Maybe lowering it a little for the terrain. Would be awkvard to work in some kind scaled dimensions though...

Ken

kend wrote:

Erwin Coumans wrote:A long thin box below the collision margins is not well supported, so best avoided if possible: having any side of smaller then say 0.20 units is highly unrecommended.
Ignoring that will result in jitter and failing simulation, unfortunately.

The 'floating' is likely because the trianglemesh has a margin. There is some improvements possible, like setting the margin for static trianglemeshes to zero (setMargin). It will hurt performance for penetrating cases. Please don't do this for dynamic objects. Box has compensation for the margin, which means that there is no gap between stacking boxes. In the future this will also be added for convex hull objects. Sphere's use their radius for margin, so no gap either. Cylinders and Cone have some gap.

Ouch. A min size of 0.2 units is pretty big in my "world". So the min size is about 10x the tolerance values. Maybe I will have to look into scaling the whole world somehow.

I'll look into the triangle mesh margin. Maybe lowering it a little for the terrain. Would be awkvard to work in some kind scaled dimensions though...

Ken

Ouch. A min size of 0.2 units is pretty big in my "world". So the min size is about 10x the tolerance values. Maybe I will have to look into scaling the whole world somehow.

What gravity value do you use?
Do you have some mapping from units to meters?

If you choose 9.8 for gravity, you can consider 1 unit = 1 meter, if you use real time steps. So the minimum 'recommended' size would translate to about 20 centimer, for a margin of 0.04. If you look at most games, you will seldom see rigid bodies smaller then that (exceptions confirming the rule).

There are definately ways to improve all this, but there are also other areas in Bullet that require more urgent improvement (compound objects, generic constraints, motors, limits etc) that I prioritized more important for generic use.

How large are typical things in your simulation "world"?

Thanks,
Erwin

Erwin Coumans wrote:What gravity value do you use?
Do you have some mapping from units to meters?

If you choose 9.8 for gravity, you can consider 1 unit = 1 meter, if you use real time steps. So the minimum 'recommended' size would translate to about 20 centimer, for a margin of 0.04. If you look at most games, you will seldom see rigid bodies smaller then that (exceptions confirming the rule).

How large are typical things in your simulation "world"?

Thanks,
Erwin

Yes, I use 9.8 and my units are meters. Most objects will be 0.2 or larger but as you say, there are exceptions. There will be some objects that are below that limit. I was thinking I could use centimeters instead and then all values would 100x. Only concern there is how it will affect the upper bounds. If the world is a few km across you get values that are 100,000 - 300,000. That's larger than I'd like from a floating point error viewpoint.

Let me ask this. What would be needed to get a reliable recommended min size of 10 cm or 0.1 units? If that can be done I'd be happy. Do I just change some values? Which ones?

Ken