Problems with setting materials and computing mass of shared trimesh

I have some poker chips in my card game.  We'd like the chips to look realistic as the player tosses them out onto the playing field.  The problem is that when I throw them out on the table with any significant angular momentum, they flip end-over-end forever.  I think I need friction.  But, that requires materials, which doesn't seem to work for me.

Here's the code for creating my DynamicPhysicsNode:

private void loadModel(){

chipNode = new SharedMesh("Chip-" + chipCounter++, sharedMeshTarget);



chipNode.setModelBound(new BoundingBox());


chipPhysicsNode = renderer.getPhysics().createDynamicNode();

chipPhysicsNode.setName(chipNode.getName() + "-physics");






If I comment out the computeMass(), I get the same behavior as I mentioned above (seemingly frictionless movement).  If I compute the mass, I get nothing.  The object doesn't even show up in my scene.  I'm not seeing any exceptions in the logs.  Any ideas?

You already have friction; otherwise your chips would just slide over the table.

ODE (I assume you are using jME Physics 2 with ODEJava backend) does not provide rolling friction. This means a rolling wheel (or chip) does not lose any kinetic energy. To roughly simulate rolling friction you can use darkfrogs new constant momentum attenuation (currently it is named FrictionCallback, going to be renamed, though). Probably you can restrict it to be applied only while it has collision events.

I have not tested the trimesh math computation thoroughly (it was a contribution) - probably it returns NaN. But it should not bother you:

You should use a cylinder instead of trimesh accuracy for your chips: instead of calling generatePhysicsGeometry call createCylinder and scale it to fit your chip. Additionally you may want to adjust the absolute mass yourself by setting it to a value instead of computing it from the material (as your chips might have 'plastic' material but have a heavy core of metal…

Further, I actually wrote exactly what you're asking for back in jME-Physics 1.  It was a rolling friction callback.  If you'd be interested in porting it to jME-Physics 2 that might be the shortest distance to your goal?

implementation would be quite different in jME Physics 2 :expressionless: (due to collision events) - so porting is not so good/easy.

Good point…Irrisor's recommendation is probably the best by basing your efforts on a revision of FrictionCallback to add collision-based friction.  This would be a good feature to have as well if you'd be interested in contributing it back.

I actually started out porting the RollingFriction to jmeP2.  I've modified it to use the ContactCallback interface to catch pending contacts and build up a list of contacts for the current frame.

It doesn't seem to act correctly (physically; it works just fine as code), so I'm not contributing it back yet.  But, when I get it working, I'll send it back.

My task list was just reprioritized today, though, so it'll be a couple of weeks before I'm back on this project.

Let us know how it turns out.  You might find the code for FrictionCallback helpful though as a working implementation that applies friction (granted, it happens all the time).