Unexpected muscle colors when default_activation property is changed

[tkuchida]

Using OpenSim-078b8daf-2018-01-26.zip from AppVeyor/artifacts:

1. Open model
2. Load motion (.mot file from IK) -> muscles are blue (Fig 1) [expected]
3. Change soleus_r default_activation property from 0.05 to 1 -> all muscles change to red (Fig 2) [expected only soleus_r to change color]
4. Change lat_gas_r default_activation property from 0.05 to anything -> no effect [expected either lat_gas_r or all muscles to change color; seems inconsistent]

Fig 1

Fig 2

There's also a brief :hourglass: lag after changing the default_activation property, as if applying to multi-selection, but occurs when only one muscle is selected. :confused:

[aymanhab]

Let me explain what happens under the hood to justify the current behavior:

1. Muscles have a native color (stored in XML or default to red if not specified in line with earlier versions). You can change these colors as you wish in version 4.0.
2. When you load a motion (either manually or by running simulation), that motion generates a sequence of states, the muscles are colored based on the activation stored in these states,
3. Any edits will recreate the systen, causing the muscles to be colored based on their default colors rather than the colors derived from the motion/states. When you play the motion again, activations take over.

Note that in the past we colored the muscles in ad-hoc way in blue-red range which is all what we could do pre 4.0 and led to sometimes unexpected random selection of blue/red.

Please let me know if that explains, and if you have ideas to make this more "expected" from a user perspective.

[tkuchida]

Thanks for the explanation. That makes good sense from a programming perspective, but the user is completely in the dark :black_large_square:. The user flips one light switch and all the lights go on, then returns the switch to its original position but the lights don't go off. To help the user build a mental model of how the software behaves, I recommend printing a message to the Messages window to let them know what it's doing (e.g., in this case, "Rebuilding computational system (State)..."). Otherwise, the user feels like the software is broken, strange, or "has a mind of its own".

[aymanhab]

Thanks for the feedback @tkuchida

My thinking was to have a "Mode" indicator on the status bar to show if we're in "Modeling" mode or "Simulation/Playback" mode. Then we can document what operations take you from one Mode to the other (e.g. edits, or moving coordinate sliders). This also would set us up for another "Model building" mode where the model may have broken links/be-incomplete and you can't perform Simulation/Analysis on it until you're back to "Modeling" mode. Thoughts?

[tkuchida]

My thinking was to have a "Mode" indicator on the status bar to show if we're in "Modeling" mode or "Simulation/Playback" mode.

That would be great, and it could fit in nicely with staging mechanisms in OpenSim (https://github.com/opensim-org/opensim-core/issues/1705, https://github.com/opensim-org/opensim-core/issues/1668).