Scaling, how/where to maintain scale factors

[aymanhab]

When we scale a model, the Scale(Vec3& scale_factors) method is invoked on "some" of the model components. It's not clear if these scale factors should be pushed down to individual components vs. maintained and applied on the fly. One idea suggested by @aseth1 in PR #538 is that Frame contains scale factors (like it is now, which are determined by a ModelScaler) and then it is up to Components that depend on (connect to) Frames to use these values to perform their own scaling.

[aseth1]

See also #186. Perhaps we should group under a general Scaling issue label?

[jenhicks]

An example of the problem (from @aseth1 ) : the fact that Muscle and Ligaments are treated specially by Model scares me. It points out that anything else (e.g other Forces) that span two or more bodies will not be scaled.

We need a solution that addresses the broader problem.

[aymanhab]

Forum issue with Constraints not scaling https://simtk.org/plugins/phpBB/viewtopicPhpbb.php?f=91&t=6800

[aymanhab]

In the context of visiting scholar project to scale contact meshes I proposed allowing Components to register a callback function that gets invoked when scaling is performed which would be very general and extensible solution, another solution to handle points attached to Frames is to have a Frame keeps a scale factor that gets propagated to connected Components though the mechanics of doing this and making sure scaling always happens and happens exactly once need to be worked out. Also How to handle Ground is another unknown.

[chrisdembia]

I know little about scaling but my naive opinion is that no model component should hold scale factors nor know how to scale itself; this implies there is an "annointed" way of performing scaling. If there is no such "single correct" way of scaling. I am not sure exactly what you are describing, but it seems that a callback mechanism would permit this more flexible scaling, where the user decides how to scale components (by registering the appropriate callback), rather than the components themselves.

[aymanhab]

@chrisdembia The main problem I'm trying to solve here is to allow users to experiment with various scaling methods rather than wire an "annointed" method. That said, there are cases where expected behavior is rather obvious (e.g. scaling a piece of geometry, or contact mesh we do this already for Markers and PathPoints) while for others (e.g. viaPoints or constraints there's no obvious default scaling behavior). The question of who holds the scale factors is an important but separate implementation issue once we agree on desired functionality.

[chrisdembia]

@juzhang

[tkuchida]

I've read the discussions in #538 (not the one by Nate Silver), #186, Forum topic 6800, and above. Why is it necessary or desirable for an arbitrary Component to hold onto a set of scale factors? I can see why we would want a scaling property for, say, a mesh (to avoid writing new geometry files during an iterative scaling procedure, for example), but it seems unnecessary and confusing for, say, a Frame to hold onto a set of scale factors. I would expect a method like void Component::scale(Vec3& scaleFactors) to simply apply the size adjustment to the Component and its descendants (move joint locations, muscle attachments, etc.). It seems like the algorithm that calls scale() should be responsible for keeping track of what's being scaled, maintaining copies of the model if necessary, etc. If the idea is that the user should be able to re-scale a model for different subjects by modifying a scale_factors property, I think a more logical workflow would be for the user to always start from a common "generic" model file. Thoughts? @aseth1 @aymanhab @jimmyDunne