Rolling Friction

I am having a very serious problem in jME-Physics (which I think is actually an ODE problem but not sure).  I set up my collisions in jME-Physics like I would for any object on a sphere, but on a flat surface rolling it never slows down…perpetual motion at its most annoying.  Can anyone get rolling friction to work?



darkfrog

Didn't we discuss that already with the result that there is no friction for rolling spheres in ODE and you have to simulate it yourself by applying forces?

I keep getting told by the ODE people that it is supported though. :o



darkfrog

I don't think odejava (at least not the one we're building upon) is very up-to-date, so even though that feature has gotten added to ODE, it's not certain that odejava have it yet.

Perhaps we should attempt to update the native ODE files and hopefully get even more good stuff. :wink:



darkfrog

Well, our ode natives are quite up to date - the only changes since 9-2004 were some trimesh collision optimizations (I can compile them the next couple of days).

If ode has rolling friction I can't find it - the only note on that in the ode docs seems to be:

"Contact joints can simulate friction at the contact by applying special forces in the two friction directions that are perpendicular to the normal."

So where should that rolling friction be activated? If we know that we could add support on the java side, too.

i've never seen any other way of doing it other than simulating it yourself, which I actually like…having that control

Okay, so as I expected it just comes from some people in the ODE IRC channel that don’t really know, they just blanket a, “Yeah, it supports it” when a question is asked. :-p



What do you guys think of adding rolling friction on the Java side so jME-Physics supports it based on the information here:



http://ode.org/cgi-bin/wiki.pl?RollingFrictionOrAerodynamicDrag



It seems very unrealistic that rolling friction is not supported and don’t really think this engine is utlimately useful without some hacking if it isn’t supported.  For this reason once I get finished with the networking API I would be willing to spend some time adding this feature to jME-Physics if the other developers agree with this idea?



darkfrog

sure, can be put into the effects package besides Attractor and such - interface for such things is already there so it would be only an additional class

Great, I'll let you know when I've been able to research an implementation of this more.



darkfrog

Guys, I'd like to add a method to DynamicPhysicsObject to set a rolling friction coefficient and then have the ability to just set this value and rolling friction will be applied by jME-Physics for me.  I have tested the following code and perhaps there's a cleaner way to write it up, I just threw it together though:


            Vector3f angular = playerPhysics.getAngularVelocity();
            float coefficient = 1.0f;
            float ax = Math.abs(angular.x);
            if (ax < coefficient * pg.getTimePerFrame()) {
                ax = 0.0f;
            } else {
                ax -= coefficient * pg.getTimePerFrame();
            }
            if (angular.x < 0.0f) {
                ax = -ax;
            }
           
            float ay = Math.abs(angular.y);
            if (ay < coefficient * pg.getTimePerFrame()) {
                ay = 0.0f;
            } else {
                ay -= coefficient * pg.getTimePerFrame();
            }
            if (angular.y < 0.0f) {
                ay = -ay;
            }
           
            float az = Math.abs(angular.z);
            if (az < coefficient * pg.getTimePerFrame()) {
                az = 0.0f;
            } else {
                az -= coefficient * pg.getTimePerFrame();
            }
            if (angular.z < 0.0f) {
                az = -az;
            }

            playerPhysics.setAngularVelocity(ax, ay, az);



If no one has any objection or optimization to add I'll go ahead and modify the project with this and check it in.  Also, ignore the "pg.getTimePerFrame()" as that's specific to the project I was applying it in.

darkfrog

Great you tested rolling friction, but I in deed do have some worries here:

  • rolling friction is applied even if no contacts are there?
  • friction coefficient is dependent on two colliding objects not only on one, thus it cannot be specified in DPO (like friction!)
  • time per frame (time per step in jemphysics) should be regarded in a more clever way
  • this regards angular velocity only - what about axis (normal) velocity?
  • where is the code posted here located? Is it a PhysicsUpdateAction? I think the interface of jmephysics does not need to be changed for rolling friction, but only an additional class should be added.



    Hope this is not too disencouraging  :expressionless: -> keep up the good work  :slight_smile:

Point taken, but I still think there's a place for it in PhysicsObject.  We could set the friction coefficient on a surface and an object and those would be added together to determine the friction coefficient for that contact.  I am currently using this code in my onContact method, but if it were applied automagically to two objects when contact is made I think it would make working with this much easier.  I don't know how creating another class could be as easy as that.  I mean, won't I end up having to call update on the other class as well?



Not sure what you mean about finding a more clever way to deal with TPF/TPS.  I would definitely be using the step time if it were being used directly in jmephysics.



So for example you have StaticPhysicsObject floor and DynamicPhysicsObject ball, something like this:


floor.setRollingFriction(0.5f);
ball.setRollingFriction(0.5f);



That's all that would be necessary and when the two objects are in contact with each other a friction coefficient would be applied of 1.0f.  Further, this would only happen when one or both were set to something other than 0.0f, otherwise it is ignored entirely.  This way all current code would continue to work the same, but projects could easily introduce friction into their projects with a couple lines of code.

darkfrog

Example: sphere1 and sphere2 should have rolling friction with the floor of 1, sphere1 and sphere2 should not cause any friction with each other, sphere1 should additionally have rolling friction with another box (sphere2 not) -> you can't specify that in DPO  :expressionless:

Other example: sphere1-box1 friction 1, sphere1-box2 friction 2, sphere2-box1 friction 2, sphere2-box2 friction 1 -> cannot be specified, too, but can be realistic for different materials



the fps thing you have implemented would cause rolling friction to be larger for smaller tpf/tps, I think - which is not that good.

Okay, I've been looking at PhysicsUpdateAction (what Attractor uses) and the methods I can override are:



beforeUpdate()

beforeStep()

afterUpdate()

afterStep()



None of these gives me what I need though since this should work based on contact between two objects and I have no way (at least that I know of) of determining that information in these methods. More detailed information required. :-p



darkfrog

True, the methods get the world as parameter now (as there might be more than one world) and the world got a getCollisionResults() method.

In CVS - does that suite?

Rolling friction does exist, just not implemented in ODE. :o



Rolling friction is caused primarily by the interference of small indentations formed as one surface rolls over another. Currently a sphere in ODE that has any rotational velocity will continue to roll perpetually because this friction does not exist and thus never loses any momentum.



darkfrog

Okay, I created a PhysicsUpdateAction called RollingFriction that can be used to add rolling friction.  I'll add some extra features to this in the near future, but for now it's in CVS and functional.



darkfrog

Hey, darkfrog, are you aware that you changed rolling friction from O(1) to O(n

You told me to fix it…  :cry:



I told you I was afraid it would be a hog on performance now, but I couldn't figure out a better way to do it, can you?  I guess I can remove the WeakReferences and force people to explicitly remove the PhysicsObject when they are ready to remove it from the scene?



darkfrog