Question about units (pinball game)

[telengard]

Hi there,

I did a quick search in the forums and it seems that there are some guidelines for units and smallest size etc.

I am creating a pinball table/editor and everything is specified in millimeters. The smallest things are around 20/30mm or so and some of the larger ones are maybe 200 (some are larger, walls etc but are static). The only things that really move are the pinball (~27mm), flippers (maybe 90mm), and plunger (160mm or so). Most everything is static (but does animate with no effect on gameplay).

So my questions are, can I keep using the units I'm using. I've done a lot of coding based on this and it would be quite a lot of work to change. Is it as simple as changing the gravity value to reflect using mm instead of meters?

Also, will I have issues since the smallest object is 27mm and the largest ones, like ramps, can get quite big (although be static)? Also, I assume that when speaking of size it's the smallest dimension, for instance a box's smallest dimension (out of width, height, length). Is that true?

Also, is it possible w/ the engine to detect a ball rolling over a flat surface, so not really colliding but touching (maybe that's the same thing??).

Sorry for all the questions, this stuff is sorta new to me.

Thanks for any info. I was pretty psyched to see my pinball moving today.

~telengard

[Erwin Coumans]

Hi there,

I did a quick search in the forums and it seems that there are some guidelines for units and smallest size etc.

I am creating a pinball table/editor and everything is specified in millimeters. The smallest things are around 20/30mm or so and some of the larger ones are maybe 200 (some are larger, walls etc but are static). The only things that really move are the pinball (~27mm), flippers (maybe 90mm), and plunger (160mm or so). Most everything is static (but does animate with no effect on gameplay).

So my questions are, can I keep using the units I'm using. I've done a lot of coding based on this and it would be quite a lot of work to change. Is it as simple as changing the gravity value to reflect using mm instead of meters?

Also, will I have issues since the smallest object is 27mm and the largest ones, like ramps, can get quite big (although be static)? Also, I assume that when speaking of size it's the smallest dimension, for instance a box's smallest dimension (out of width, height, length). Is that true?

Some (internal) parameters are tweaked with units around 1, so the behaviour might be not very well. You can try it out, and if things don't work out you can re-tune some of those values. This applies to the collision margin (although for spheres you don't need to worry about those), btCollisionShape::setMargin, and btScal contact breaking thresholds, see btPersistentManifold.cpp/gContactBreakingThreshold. You might want to increase this, if your units are 100 times larger then usual.

Also, is it possible w/ the engine to detect a ball rolling over a flat surface, so not really colliding but touching (maybe that's the same thing??).

Colliding and touching is the same in Bullet: they both create contact points, and those get resolved in the same way (applying impulses).

Hope this helps,
Erwin

[telengard]

Hi there,

Thanks for the info. I converted my program such that it is now in meters and things seem to be working better. I had to adjust for the half extents and positioning but all seems well. One thing I haven't been able to figure out is my btSphereShape. The radius in meters is .0083 as it is a pinball. I implemented the debug drawer routine and the eight sided box shown for it is much bigger than the pinball. Is there a minimum size I can create a sphereshape? I noticed that it does get larger if I increase the radius but at small sizes it seems to hold at some fixed value.

~telengard

[telengard]

Has anyone any input on this? Kinda stuck at the moment.

~telengard

[Erwin Coumans]

One of the issues is the default collision margin, which is around 0.04 units. You can set the collision margin to be smaller (don't use zero!), like 0.01.

Code: Select all

sphereShape->setMargin(0.01);

Simulating very small objects is more challenging, and you are dealing with very small objects, which requires additional effort. For now, you should use a small internal timestep as 3rd argument to btDynamicsWorld::stepSimulation:

Code: Select all

btScalar dt = realDeltaTime;
btScalar internalFixedTimeStep = 1.0/420.f; //take a very small subStep, to avoid tunneling/missing collisions
int maxNumInternalSubSteps = 10;
int numActualSimSteps = m_dynamicsWorld->stepSimulation(dt,maxSimSubSteps,internalFixedTimeStep );

Hope this helps,
Erwin

By the way: continuous collision detection and response should avoid this effect, but it is disabled at the moment. It will be re-enabled later.

[telengard]

Excellent, I will try this tonight. Thanks!

Yes, unfortunately relatively speaking the pinball is quite small. I'm already scaling from mm to meters and didn't want to also have to add a x 10 scale to fit into the sweet spot if I could avoid it.

~telengard