Scaling strategies.

[steveh]

Hi All,
I've got a slight problem with the pool game I'm writing. The balls are approximately 5cm in diameter. This is 0.05 in bullet units. Unfortunately this does not sit well with the default collision margin values.
Running the sim leads to the balls in the rack "exploding" apart and the balls bouncing and judderingaround the table. What would be the best way to fix this? Scale up al values passed to the physics, then scale down again for rendering? Any better suggestions? I've tried reducing the collision margin, but this seems to have very little effect and might lead to inaccuracies later.

Many thanks,

Steve.

[Erwin Coumans]

Hi Steve,

Let's try to resolve those issues. Please do not set the margin on btSphareShape (an assert should be in place). This is not needed, because it is already 'embedded' in the radius.

I just tried to replace the cubes in the 'Demos/appConcaveDemo' by btSphereShape(0.05f), and made the floor flat, but couldn't reproduce 'explosions'. I did notice a tiny jitter/regular up/down movement, is that what you experience? I'll try to find out what the issue is.

- What is the timestep? (all values passed to 'stepSimulation') ?
- What shapes do you use to represent the static environment exactly? btBoxShape, btTriangleMeshShape, margin etc?
- gravity value?

Thanks,
Erwin

Hi All,
I've got a slight problem with the pool game I'm writing. The balls are approximately 5cm in diameter. This is 0.05 in bullet units. Unfortunately this does not sit well with the default collision margin values.
Running the sim leads to the balls in the rack "exploding" apart and the balls bouncing and judderingaround the table. What would be the best way to fix this? Scale up al values passed to the physics, then scale down again for rendering? Any better suggestions? I've tried reducing the collision margin, but this seems to have very little effect and might lead to inaccuracies later.

Many thanks,

Steve.

[steveh]

Hi Erwin,
I've tracked down the reason for the exploding rack.
I'm not creating any custom collision handling routines like the Basic Demo does. So it appears to be using the btConvexAlgorithm for all collisions instead. This introduces a few additional margins that can be seen on line 132 of btConvexConvexAlgorithm:

input.m_maximumDistanceSquared = min0->getMargin() + min1->getMargin() + m_manifoldPtr->getContactBreakingThreshold();

getMarign returns my balls radius (0.025) plus the default margin (0.04)
which comes to 0.065, getContactBreakingThreshold() returns 0.02.

The resulting value is (2 * 0.065) + 0.02 = 0.15.
This means the pool balls need a whopping 15cm between each ball!

I did initially try to use the custom collision algorithms in the basic demo, but box/box did not work as there was no custom collision routine.

I'd like to set up my phyics wrappers to pick the optimal routine for each case using the custom collision routines where possible. Is this easy to set up?

Would scaling up my positions / gravity values before sending them to Bullet, then scaling them down for the graphics be an option if we still had to use Convex/Convex?

Many thanks.

Steve.

[z8000]

What was the resolution here? Man, I read so many threads that catch my interest that go nowhere!