tips for roulette simulation

Post Reply
cesarpachon
Posts: 4
Joined: Fri Jul 05, 2013 2:11 am

tips for roulette simulation

Post by cesarpachon » Thu Feb 22, 2018 4:15 pm

hello, I already had checked some entries in the forums regarding casino roulette simulation, but I am trying to get information regarding to the general strategy to implement the physics. by example, the first rotations of the ball it seems to stick to the edge of the wheel until lost enough energy to being start attracted toward the center by gravity. how to simulate this phase? should I keep adding impulses? in the reality, there is a single huge initial impulse that will keep the ball orbiting, but the collision with the edges I think is tricky because it is supposed to be the internal side of a cylinder. I tried to approximate using a terrain, but it generates squared corners instead of a smooth circular surface. should I use another approach, like not adding a collision entity, but checking the distance to the center and apply impulses (or forces) in each update?
thanks for any hint.

User avatar
drleviathan
Posts: 555
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: tips for roulette simulation

Post by drleviathan » Thu Feb 22, 2018 7:18 pm

More info please. I could imagine several challenges when it comes to simulating a roulette gambling mechanism, but it isn't clear to me what your initial problem is.

As I understand it: the wheel is spun one direction and a small marble is spun the opposite direction along an outer track. When the ball loses enough energy it hits a tab and bounces inside the roulette wheel, eventually coming to rest in one of the various slots of the wheel.

Are you not launching the mechanism in that way? Or have you not yet added the wheel and you're still trying to just roll a ball around a smooth outer track?

What is the dimension of the sphere you use for the ball?
What is the duration of your substep?
Are you using continuous collision detection (CCD)?

You say you're using a btHeightfieldTerrainShape for the outer track?
What is the resolution of your terrain?
Have you considered using btBvhTriangleMeshShape for the outside track?
How many triangles are in the track model?

cesarpachon
Posts: 4
Joined: Fri Jul 05, 2013 2:11 am

Re: tips for roulette simulation

Post by cesarpachon » Fri Feb 23, 2018 8:48 am

hi @drleviathan, thanks for your quick answer! these are the answers to your questions:

-status: I am at the starting phase of this particular prototype (already tried 2D approximations even with simple angular interpolation, no realistic enough) by now I am trying just to simulate the starting phase: from launching the ball with either an initial impulse or a decreasing force (not sure here) until the ball loss contact with the track.

-sizes: modelling the wheel with a radius of 100 units, the ball has radius aprox 1 - 2 units.

-collider shape: I choose a heightmap for the wheels' board because (as far as I understood) the internal conical surface of the wheel board is not a convex polygon.. the resolution of the terrain is: 128 x 128, also tried with 256 x 256. I am planing later add the wheel itself as a trimesh and each tab as box.

- simulation configuration: I am running the simulator with stepSimulation(1/120, 10) . with the following configuration:
btDefaultCollisionConfiguration
btCollisionDispatcher
btDbvtBroadphase
btSequentialImpulseConstraintSolver
btDiscreteDynamicsWorld
(I am using ammo.js, that is a direct port of bullet)

User avatar
drleviathan
Posts: 555
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: tips for roulette simulation

Post by drleviathan » Mon Feb 26, 2018 4:14 pm

It is good that your marble size is on the order of 1 unit. That is about right.

A substep of 1/120 sec sounds good.

I've never used the btHeighfieldTerrainShape but yeah 256x256 might be too low to smooth the facets along the ball's track. I recommend trying to use a btBvhTriangleMeshShape for the ball's track. BTW, you can only use the mesh shape for STATIC objects. You can actually use a large number of triangles (tens of thousands) in the mesh with decent performance... as long as the things colliding against it are relatively small: their bounding box must overlap several tens of triangles (or less) at one time, not thousands of triangles. This condition would be true for the marble, but not for spinning wheel in the middle.

If your central wheel is spinning then it must be DYNAMIC, which means you can't use the mesh shape and must instead use a btCompoundShape with a collection of convex parts: a cone for the main body and boxes or convex hulls for the other bits. Since this object doesn't need to collide against outer track you should use collision groups to eliminate collisions between them, else suffer the performance problem alluded to above.

JJWong
Posts: 3
Joined: Tue May 23, 2017 8:08 pm

Re: tips for roulette simulation

Post by JJWong » Fri May 18, 2018 5:42 pm

drleviathan wrote:
Mon Feb 26, 2018 4:14 pm
It is good that your marble size is on the order of 1 unit. That is about right.

A substep of 1/120 sec sounds good.

I've never used the btHeighfieldTerrainShape but yeah 256x256 might be too low to smooth the facets along the ball's track. I recommend trying to use a btBvhTriangleMeshShape for the ball's track. BTW, you can only use the mesh shape for STATIC objects. You can actually use a large number of triangles (tens of thousands) in the mesh with decent performance... as long as the things colliding against it are relatively small: their bounding box must overlap several tens of triangles (or less) at one time, not thousands of triangles. This condition would be true for the marble, but not for spinning wheel in the middle.

If your central wheel is spinning then it must be DYNAMIC, which means you can't use the mesh shape and must instead use a btCompoundShape with a collection of convex parts: a cone for the main body and boxes or convex hulls for the other bits. Since this object doesn't need to collide against outer track you should use collision groups to eliminate collisions between them, else suffer the performance problem alluded to above.
Wow great advice about the collision groups usage. Thanks for the info.

Post Reply