pnvv, I'm not sure what you mean by "the meters go away". If you mean they count backwards then that's OK. If you mean they disappear, then that's a bug.
Thanks for the feedback. I tried those parameters and got similar results. I also tried various combinations of force and torque on the ends of the spaghetti. I liked the results of using your parameters, but felt uneasy that the scene performed well for only a small range of frequencies.
Thanks for the suggestion, but I was not able to improve the performance. Maybe I'm missing something. If I didn't change box color with torque, then I believe your suggestion would be faster.
Details:
I replaced
a := _abs(g1.angle - g0.angle);
g0.colorHSVA = [235.0 - 3133.0 * a, 1, 1, 1];
g1.colorHSVA = [235.0 - 3133.0 * a, 1, 1, 1];
with
torque := ((readable(owner)).totImp3)(2)*sim.frequency;
g0.colorHSVA = [235.0 + 1e6*torque/3.0, 1, 1, 1];
g1.colorHSVA = [235.0 + 1e6*torque/3.0, 1, 1, 1];
and
a > 0.075 ? {
with
torque < -0.00075 ? {
The scene went from 80% of simulation time to 62%. I then tried coloring 1 box per hinge, which sped things up, but caused one end of each of the larger pieces to stay red.
Regarding "I think the fact that it runs at 1000 hz has more of an affect on computer performance rather than the color script.":
I agree. I've done some experimenting and it appears that coloring the rotor has little effect on the performance. Coloring the stator only needs to be done once and then the code can be deleted because the stator colors don't change. If you decide to color your scene, then I will delete this one.
Q: Is your algorithm based on any well-known data smoothing algorithm?
A: I don't know. It was the simplest I could find. It creates a new surface based on midpoints between the original surface adjacent points.
Regarding cutting the original polygon, I didn't realize you could do that. Sounds like a good way to make teeth, stone walls, and igloos.