Dice physics

Well, Verlet Integration has neither Velocity nor Acceleration.

It just has these: [Vec3 @ t=0], [Vec3 @ t=-1], [Vec3 @ t=-2] for each sphere/point.
t=0 means current location
t=-1 means location in previous step
t=-2 means location in step before previous step

Velocity = [Vec3 @ t=0] minus [Vec3 @ t=-1]
Acceleration = ([Vec3 @ t=0] minus [Vec3 @ t=-1]) minus ([Vec3 @ t=-1] minus [Vec3 @ t=-2])
–> basically: current_velocity - last_velocity

Minor diff, yet extremely nice for backtracking during a collision!!

hey, you point out something very interresting for me, acceleration is maybe something I have missed!! , this should explain why I had so much difficulties to get a proper inertia.

Actually, you can have enertia without acceleration.

The downside is that you need lots of spheres, so that the ‘shockwaves’ of collisions can travel through them. The ‘shape’ will compress and naturally bounch back in the opposite direction.

For a good result you might need 4x4x4 spheres (looooooooooaaaaaaaads of springs).

Can I somehow render the geoms or bodies from JOODE?? So it would be much easier to place and scale them correctly.

I have little experience of doing fancy rendering. However, you can setup a custom Scenergraph node for each geom. Create the dice with a Box like it is in the SVN repository allready. Before adding the Geom to the space though, you would need to define a custom scenegraph node to describe how that would be drawn. The class is XithGeomAppearance and you would need to set the scene subtree (look for the method setSceneSubgraph or something). You need to do this before the geom is added to a space (so that the XithManager gets to see the graphics representation when it detects a new Geom has been added to a space).

This will not really help getting you getting you graphic aligning with the collision bounds though. It will mearly take care of all keeping a graphics appearing in sync with the bodies position.

The XithManager inserts a TransformNode into the scenegraph that is adjusted everytime the world updates . This Transform node is synced with a geoms position so that when the body moves around, so do the geoms and their associated transform nodes are moved with the body. So you can hang off arbitary graphics code there for wonderfully complex graphical representations. But JOODE cannot possible ensure this representation relates in any way to the Collision geometry.

Tom

Ok,

I’ve done it with the 8 spheres. For that I calculated minX, minY, minZ and maxX, maxY, maxZ. Then I created 8 spheres and set their position with setPosition to something like this (minZ,minZ,minZ) and so on.

When subtract minX from maxX i get 0.5 and now i don’t know what size to set for the spheres radius. Is it 1f,0.1f or something else? What would you suggest?

My real problem is, that the collisions are completely wrong. Even with the dice it self it doesn’t work.
I have not set the position of the dice Mesh. It gets it position from the Geom object. Is it possible that the spheres and their GeomTransform are not correctly offset? How do i set the Mass and center of the object correctly? And how do I offset the GeomTransform anyway?

Hope you can help me here

Setting the Mass object up is not important. Just set the mass up as 1, and set it up as a sphere of radius 1 or something. (or a box). An incorrect Mass is not usually detectable by the user unless the object being represented is really long and thin. The mass should have the correct center of gravity though, which is implicit by using just one body to represent the dice

The spheres need to be equally distributed around the body, not offcenter. So for every sphere places at +x,+y,+z there needs to be another sphere at -x,-y,z. Common sense.

So to use a GeomTransform you simply set your spheres up first (with setPosition, using the offsets, not global coordinates), and don’t add them to a space. Then you create a geomTransform encapsulating each sphere (I think this is done at construction time of the GEomTRansform). Then you add the GeomTRansform object to the body, and add the GeomTransform to the space. So nowhere do you add the sphere object directly to the body or space. The GeomTransform uses the coordinates in the Shere object to offset the geometry relative to the body.

If you use the default graphics behaviour of the XithManager, the above description will create graphical representations of the spheres and that should all look realistic w.r.t colli8sion behavior. You then need to draw you graphics mesh using the positional information obtained from one of the geoms or the body object. The body positional information is most intuitive because that will be centered w.r.t to the center of mass. Although using a sphere’s might actually correct a mesh that is described using only positive coordinates. There is a chance your graphical representation is not centered, in which case you will have to repositions the graphics from the body’s geometry. You need to learn some basic computer geometry concepts if you can’t do this.

The radius of the spheres is kinda dependant on the scale of the dice. If the dice is 10,000 units in diameter you probably want spheres of radius 100 or something. For this application you aren’t really worried about a small object penetrating the dice. So maybe set the diameter of the spheres to about 10% of the total diameter of the dice. It shouldn’t really be a critical thing though anyway.

Ok,

it works now so that it is acceptable. It is not perfect but its OK.

My next problem is the rotation the code Matrix3.setRandomRotationMatrix(new Matrix3()) gives my only small values back (never bigger than one) what do I have to calculate that I can use that rotation in


            GL11.glRotatef(rotation.x, 1, 0, 0);
            if (rotation.y != 0) GL11.glRotatef(rotation.y, 0, 1, 0);
            if (rotation.z != 0) GL11.glRotatef(rotation.z, 0, 0, 1);

The elements in a rotation matrix will always be less than or equal to one. What is GL11.glRotatef(rotation.x, 1, 0, 0); supposed to do? Is it an axis angle rotation.

You really don’t ever want to try and cut a rotation into three Euler angle rotations when you have the full rotation matrix available. You will run into the Gimblelock problem (look that up!). Basically the order in which you apply the axis of rotation become imporant If you are desperate to use an axis angle rotation then find the methods in the math library that converts the matrix3 into an axix angle representation.

Now JOODE has its own math representation (Matrix3) which does not have all the axis angle stuff. Openmali does, so convert your Matrix3 to a Matrix3f. There is a converter implemented somewhere (MathUtils?) but you can do it manually by copying the 9 elements in the matrix across into a Matrix3F. Just make sure that you don’t accidentally transpose the matrix during the operation.

Openmali has routines for then converting the Matrix3f into an AxixAngle4f object which you can then read off the values to insert into:-

GL11.glRotatef(angle?, axis.x, axis.y, axis.z);

Tom

So, it works almost now.

A few issues:

  • Sometimes only 3 or 4 of my 5 dice get rendered (even though the physics work and return me the die-value like in the example)
  • Sometimes the collision with the table is not correct and my die jumps up as if it has hit a trampoline.

So far, thanks a lot for that great support.

Adjust the bounce parameter probably. And the Dampner and the mu and the mass and the gravity and the worldCFM and the worldERP and the step size.

Fiddle like crazy.

Dunno about the dice rendering, thats not the physics domain really. I am not sure what that could be. Maybe jumble the order of construction and method calls around a bit.

Actually the obvious cheaty way is to make sure the y velocity is below a threshold every timestep. A dirty hack but why not?

Ok, the last problem.

I’ve tried to set the rotation with converting the rotation matrix to a Matrix4f and then to a AxisAngle3f.
This still gives my small values and I multiplied them by a 100.

Now the dice settle on their edge and do not fall flat on the table so that only one side is fully pointing upwards.

Would be great if I could solve this last one too.

Why do you need big values for a rotation? ?The angle will always be between -PI and +PI and the axis is normalized as it should be. I don’t understand why you need large values. The method you are refering to is OpenGL stuff. Does the dice settle in the physcis but not the graphics representation?? i.e. the graphics are rotated and don’t line up with the collision representation through some kind of rotation. If thats the case create a rotation matrix from a axis angle and then premultiply the rotation matrix by that to get an adjusted rotation matrix.

You havn’t really given me much info on the problem.

OK. I actually will be busy for 4 days now so I hope you get your work done. Don’t forget to cite JOODE please.

Tom