Muscles fail to wrap around wrapping cylinders after scaling

[suhlrich]

When scaling a body with non-uniform scale factors (scale_x != scale_y != scale_z), wrap cylinders can have muscles that no longer wrap around them after scaling.

Since a PathPoint is scaled linearly by the ScaleSet, and the radius of a WrapCylinder is scaled by an average of multiple ScaleSet components, sometimes the WrapCylinder scales more than the PathPoint and causes the muscle to no longer wrap.

As a simple example, if a PathPoint were located at (1,0,0), the WrapCylinder z axis was (0,0,1) and its radius was 1, and the scale set was (1,2,1), the PathPoint would not move, but the radius of the WrapCylinder would increase to 1.5, moving the PathPoint from the surface of the cylinder to inside it.

Attached are files replicate the problem for the iliacus. This issue is common for iliacus, psoas, and gmax muscles in this model.
WrappingIssue.zip

In theory, you'd want all points on a wrapping surface to scale linearly with the scale set like Points do, but I can't think of a way to ensure this by adjusting the cylinder length and radius. A cumbersome solution would be to search across many poses after scaling and check for large pre-post-scaling changes in moment arms or muscles that pass through their wrapping surfaces. This would be quite slow.

@antoinefalisse

[aymanhab]

@suhlrich Thanks for reporting and documenting the issue. There's an easy solution which is to test wrap points to make sure post scaling that the points are on the outside of the wrap surface (since unlikely to be intended behavior) and if not projecting them out. There's a hook for us to do that post scaling. Thoughts?

[tkuchida]

FWIW, I think it would be time-consuming to guarantee a postcondition like this automatically for any arbitrary model. For example, perhaps the model works fine for the range of motion of interest. I think a postcondition like this can be checked by the user, who would also know how to address it (since the solution might depend on the model, the wrap surface, the muscle, the range of motion, etc.). 🦆

[suhlrich]

@aymanhab, that would be great, but as @tkuchida mentions, the issues often don’t happen in the default pose, so you’d have to do a pose search. It would be difficult to guarantee it for all poses and muscles, but one could search combinations of the coordinate extremes and probably catch many of the cases. Although it may not be a perfect solution for all cases, I think Ayman’s solution would be a big improvement.

[tkuchida]

@aymanhab I think you would also need to check that the points are on the outside of the wrap surface before scaling as well. The scale operation should guarantee that the model is unchanged if everything is scaled by 1.0. If you project points outside the wrap surface in postScale(), a model with points inside a wrap surface would be different after scaling by 1.0. (Granted, one could argue that the original model isn't particularly good, but perhaps the modeler has a reason for this.)

[aymanhab]

Thanks for chiming in @tkuchida My thoughts:

1. Scaling is done in the specific default pose, that's the only thing we need/can check practically.
2. We can just flag points that are inside the wrapping surfaces and then it's the user responsibility. If the user had a purpose for leaving points inside, they can do nothing about them.
3. In likely most of these cases where points are outside and end up inside, we currently produce bad model post-scale from a good-model pre-scale QUIETLY, this doesn't feel friendly or right behavior.
   Love those 🦆 🦆 🦆

[tkuchida]

Sounds great, @aymanhab. Alerting the user to suspicious-looking points would be good, while allowing them to address as appropriate for the situation. I agree: quietly returning a model with characteristics that are likely bad in most cases isn't responsible. 🐫

[suhlrich]

@aymanhab

1. Would it be hard to test at neutral pose, then move each coordinate to either limit? Many of the cases don't show up in neutral pose, so for the slightly greater effort of moving to extreme poses, I think it would be valuable. It would just be 3nDof insted of 1nDof checks.
2. As we build automated tools for kinematic analysis at scale (i.e., with video), having to manually check models for this isn't great. I like your original idea of projecting the point outward (maybe in direction of shortest line from point to wrap surface). If we'd prefer this to not be default behavior, it could be a flag in the ModelScaler that is default to notify and not move the point.
3. agreed.

[antoinefalisse]

@aymanhab following our chat, here is an example model for which that happens for the gmax1_r at the first time instant of the attached motion file:

badWrapping.zip