Channel modifier lscript runs twice (or more)?

[bartrobinson]

Hey folks,
I've hit a bit of a development roadblock. I'm working on a channel modifier lscript for tire rotation. It uses the store/recall functions to keep track of distance traveled inbetween frames. My problem is that it seems the lscript gets run at least twice, if not many more times each frame. I can provide code if no one has any clues right away. Thanks. The lscript will be freely available when I'm done. Thanks ahead of time.

[Jarno]

You can not depend on channel modifiers being called only once, or even sequentially over time. There are various cases which can cause a channel modifier to be evaluated at a times different from the current. For example due to motion blur, dynamics calculations, showing paths in Layout, path alignment calculations, expressions referencing times other than the current.

---JvdL---

[bartrobinson]

Thanks for the hint! I noticed that after a similar hint today by NanoGator on CgTalk. After that I wrote a quick test script that just counts how many times the script has run and applied it to a channel (meaning that I had the graph window open) in a 60 frame animation. Immediately after applying it, it was run, without my help 63 times. I immediately figured that it gets run once for each frame so it can preview the channel modifications, then perhaps once more to return to the current frame, then two more times for some unknown reason.

So this leads to my next question. I'm trying to write a script that keeps track of the overall all distance traveled by an object. How can I make sure the accumulation only occurs during the animation and not due to "channel modification previews", etc. As I type ideas are brewing, but any help you can provide will be greatly appreciated.

[Jarno]

I take it that your problem is that computing the distance travelled takes too long to do from scratch every time.

You could keep an array of already computed frames. If you need to know the distance at a frame not yet computed, start from the nearest computed frame. Some thought needs to go into when to invalidate computed frames.

You can filter out the calls for frames other than the current frame by comparing the time in the channel access structure with the current interface time. If they differ, skip the expensive calculations.

---JvdL---

[bartrobinson]

Well, not really. The problem seems to be that I get the wrong distance travelled because the script seems to run many more times than just once per frame for the object it is applied to. I did not expect the script to run more than once per frame. Therefore I wrote the script to just keep a running total of distance by adding the difference in position between the current and previous frame. But since it looks like the script runs several times per frame, the same changes get added multiple times. I made a few changes based on NanoGator's suggestions, and keep track of the last frame computed, then compare it to see if I need to compute it again. It resets at frame 0. So it seemed to calm down a bit but still doesn't seem quite right. I'll send the script.