Multiple frictional properties per BodyNode

[jslee02]

BodyNode stores one friction coefficient for the all collision shapes in the BodyNode. Multiple friction coefficient per body would be useful in case of a body consist of different materials.

One possible way to do this is that stores the frictional properties in collision object. Currently, DART uses Shape classes for both of collision object and visualization object so we may need to consider split the class.

In addition, multiple frictional directions should be considered too.

[scpeters]

It looks like each ShapeNode with a DynamicsAspect now has its own friction properties, but the ContactConstraint doesn't use them. It only seems to use the friction parameters stored in the body node. To demonstrate this, I modified the hello_world example in scpeters@dbdcdec to have a floor with inclined gravity, so that when setting the box ShapeNode friction to 0.0, it should slide along the floor. It doesn't slide though, unless you modify the ContactConstraint (as in scpeters@f8b5378).

[scpeters]

ShapeNode friction coefficient defined in detail/ShapeFrameAspect.hpp

[mxgrey]

Thanks, that seems like a bug. Feel free to open a PR.

I wonder how we should handle the full transition from BodyNode-specified friction to Shape-specified friction? We shouldn't have the BodyNode and ShapeNodes both store friction data, because they'll easily conflict with each other.

It would be easy enough to change BodyNode::setFrictionCoeff(~) so that it just changes the friction coefficient of all shapes currently in the BodyNode. However that won't help for new shapes that could get added later.

Also, BodyNode::getFrictionCoeff() doesn't make very much sense if friction information is stored per ShapeNode. At best we could return some kind of average friction?

I guess both of those functions should be deprecated and we should recommend to users that they focus on setting friction per ShapeNode.

[jslee02]

Alternatively, we could introduce a friction coefficient mode to ShapeNode to decide which coefficient should be used. The mode would have several modes something like INHERIT, OVERRIDE, BLEND, MIN, and MAX. In this way, newly added shapes could use the same coefficient if the mode is INHERIT, and we could use INHERIT mode as the default not to break backward compatibility.

Here (d912dc7) is a quick implementation based on @scpeters's example.

[jslee02]

On second thought, having the friction property in both of BodyNode and DynamicAspect wouldn't have many benefits but introduces confusions. So just deprecated them from BodyNode and changed the constraint solver to use of DynamicAspect in #1369. Also, applied this to the restitution coefficient as well.

[scpeters]

yeah, it's simpler to just have the parameters in the ShapeNode, rather than also being in the BodyNode