Dice physics

Game Mechanics
#1

Hi,

In my LWJGL app I load some dice and a table from obj files. Now I need to add the physics so that the dice fall on the table and turn correctly. I then want to be able with the physics engine to correctly pick one of the dice and read what value it has (which number is pointing upwards the positive Z axis)

Whats the best and easiest way to do this? I first thought about JBullet but its hard to implement it in my existing source. As for odejava I’m not sure if its good to use it.

Can anyone help me out here? I need to get a solution soon.

Thanks

#2

Hello. Just to communicate to everyone I am still around.

I always fancied doing a real dice simulation so I have written one as an example application in JOODE.

Its called Dice and its in the examples directory. Although the renderer is Xith I have tried to make it obvious where you need to chop that bit out for your own renderer.

The example throws two dice, and prints the results as each dice has landed and stopped moving on the table.

SPACEBAR rethrows the dice.

For your app you will need just the JOODE jar and the Openmali jar once you adapt the code to your own renderer.

The simulation features bouncy dice, velocity dampening, dice-to-dice collisions and gravity

Tom

#3

Hi, thats nice

I think this example can help me a lot.

Just a few problems: with my downloaded joode.jar I do not have the BodyDamper class which is used in the example as well as the negate function used in the settledFace method. I have commented out the following:

 // new BodyDamper(d1, 10,.1f);
      //  new BodyDamper(d2, 10,.1f);

and wen I run my app it calculates the positions of di1 and di2 but never gets d1SettleCount or d2SettleCount to 0. So I cannot even get to where the settledFace method is called.

#4

Strange you don’t have those classes. Where did you check the files out. They are in the repository. Damper is in the force directory. If you have downloaded the jar off the website that is a old version. Get the source directly from the subversion repository

I expect that because the body dampner is not around (which applied a force against the direction of both angular and linear velocity) there is not a loss of energy in the simulation. I set the bounce to 1 meaning things should bounce for ever. So change bounce down low. Say, .1f. Energy loss should be alot more then.

The 4 parameters that control the simulation are:-
bounce
world ERP (error reduction parameter)
world cfm (constraint force mixing)
and mu (coeffecient of friction) You could try changing this up high as well.

But the simulation is setup pretty well as it is. Get the subversion version.

The negate use is just a math hack. Replace the negate with a new contruction of a Vector3 called down (0,-1,0) and use that subsequenty instead of up

Tom

#5

Ok, yes I was a bit lazy to get the source and build it my self.

Now I’ve come to another problem:

 net.java.dev.joode.util.pool cannot be resolved to a type

and

net.java.dev.joode.collision.collider.INSTANCE cannot be resolved to a type

Would be nice to know how to solve that so that I can buld joode.jar

#6

I will check the project out fresh and work out what all these errors are.

#7

Hmmm. Well I just checked out the project anonymously into a fresh directory and the src compiled as is, and the dice app ran.

I used java 1.6 to run it, but I believe it should work fine with 1.5 and above.

Check your dependencies are pointing to the right libraries etc.

Anyone else got any ideas??

Tom

#8

With what IDE did you build it? I use eclipse but I really hate this IDE. Could not do anything with the checked out project and I somehow had to copy my files into a new Java project. Probably that is the the problem.

Normally I’m using Netbeans. I much prefer this one.

#9

OK, I could build it with Netbeans. Strange that I haven’t seen that before.

One thing now: Do your dice have only the values 1-3? I never got 4,5 or 6.

#10

Hmm,

And what do I have to set for my table object? I’ve used TriMesh but dont know how to use Mass and BodyDamper.
I used setGravityMode(false), setFlag(Body.BODY_FLAG_NO_FORCE, true) and setFlag(Body.BODY_FLAG_GRAVITY, false)

The table gets not pulled down by the gravity but as soon as the first dice hits the table, it flies away.

#11

Stay away from TriMesh. Physics are much easier to calculate with basic geometry, like boxes and spheres

For the table: just use 4 long boxes and 1 flat box - it might collapse, so you might want to add some constraints.

For the dice: 8 spheres with strong springs separating them, will do the job just fine.

To get which side is up, just see which 4 spheres are highest, and lookup the number (1…6) for that comb.

With 8 spheres (on the corners of the imaginary cube), you get nice (perfect) rounded corners, like a real dice has, so they will roll/bounce much smoother. The empty space among the spheres won’t be a problem when rolling on a flat surface like a table.

You need 3*4 (edges) + 6x2(cross faces)+ 2x2(cross center) = 28 springs for the dice

#12

[quote]For the dice: 8 spheres with strong springs separating them, will do the job just fine.
[/quote]
+1, far away the best method to use. fast to compute and realistic results, and in case of, for the inner space you can use a fifth centered sphere with its diameter equals to the height of the dice.

I use such technic (only 4 spheres) to simulate a rigid car and it works pretty well (http://demo.dzzd.net/ROAD4/), 4 spheres constrained to have a constant distance == some kind of physic triangulation.

EDIT: using about 4/5 recursive “constraints step” in this case (rigid body) may help.

if s1 to far or to near from s2 move s1 towards/backward s2, and s2 towards/backward s1, use about half of the overlength of the wanted distance, do the same for all other constraints between sphere.

recursivly do previous step N times. N == approx 4

#13

Ok, I’ll try out that with the dice later.

I need to speed up a little. It does not have to look perfectly but I need to be finished this friday.

One point, even if i use boxes for the table instead of TriMesh what do I have to do inside JOODE that the table does not get affected by the force of the dice?

Another thing I need to solve:
How can I let the player select one of the dice?

#14

IIRC a Geom does not move. A Body does.

So use a Geom for the table.

Anyway, I say you want to use my approach for later, while I think mine could be faster to get working, but I dunno… :-X

#15

Phew,

So many problems. All my objects are a bit more complex as simple object even my dice. They are loaded from an obj and its hard for me to get the right body for my dice and the table. When I use TriMesh for the table, the app runs. But when I use TriMesh for the dice it crashes. when I use Box for the dice I don’t know how to set it to the right size. Right now it just looks wrong, because the collistion is not show right in the app.

To do it with different spheres and connect them with joints, I don’t know where to start. I don’t know which side is which and how long or high the edges are.

#16

Yeah use a box for the table top. But create a geom and add it to the space. Don’t attach a body. That should work fine. Thats called static geometry. It should stay put.

My dice was working with numbers 4-6. Is it that you removed the negate function and did not put it back (semantically or otherwise)?

8 spheres instead of one box for a dice is very clever actually. That should stop the unstable bobbling that my simulation has which is caused by edge-edge collision hacks. Then you can remove disabling the body functionality I put in which kicks in when the a dice has settled. In JOODE you don’t need to put a strong spring between the spheres. You just encase the spheres with a GeomTransform object so that the spheres can be offset from the center of gravity of a single Body object. So you end up with 8 GeomTransforms which you then add to a single body which gets added to the World object.

My computer doesn’t have a gfx card at the moment so I my simulation runs extermely slowly here anyway. Thus I can’t help on tuning the performance. Increase the world step size. You will then probably have to adjust the world erp, cfm, mu (SurfaceParameters) and bounciness parameters to keep the dice realistic. Setting mu to 0 or Infinity has additional speed benifits. Also setting the dice to be a spherical mass also has some extra performance benifits. I would be pretty annoyed if running the physics for 2 bodies is a strain for the dynamics engine though, but well there could be a bug in some subset of the code that is slowing performance down unecissarily. You would need to profile to solve that and I doubt you have time.

Selecting a dice is the graphics renderer’s problem, not the physics engine. Xith has picking routines so you will have to look thats stuff up yourself.

#17

Sorry you posted at same time as me.

Trimesh trimesh collisions don’t work in all cases. So you can’t use them for both. But theoretically you really don’t want to do that anyway.
Surely you can just adjust the ground plane height to be the correct height for whatever graphical representation you are using for the table.

As for dice size, you just have to fiddle. It may be that your graphic representation doesn’t have the center of the dice as the origin, in which case you will have to offset the geometry. You don’t want to do that in the physics. The Body should be in the center of the box representation which it is currently. You just need to adjsut how the graphics are overlayed with respect to the body. Read the obj file and work out where the coordinates of the verteces are. Mutiple the origin offset by the 3x3 rotational matrix of the body, then add the body’s positional vector to that result (negate your offset, jiggle the order of operations until it works).

Tom

#18

you seems to make things more commplexe than what they are. I mean you just need to be able to perform sphere to any object of your world collision (maybe only sphere => box(table/dice) collision) and that’s all.

define 8 sphere
define 8 velocity vector (one per sphere)

do
for each sphere s in the eight sphere
move s with its current velocity vector (perform collision)
perform each constraints between sphere.
end do

finally add some inertia by doing : for each sphere save new velocity vector == (end sphere pos - start sphere pos) *coeff

#19

Verlet Integration FTW. (google for the gamasutra.com article!)

You’ll have realistic dices rolling around without any matrix/cos/sin/sqrt or basically anything - everything happens with a few lines of code.

#20

good article, very well explained,

and I just discover that what I did in 3DzzD was knew as the Verlet Integration and blablabla