Frame Change Handler Bug?

Coding Python Support
1

I don’t know if this is a bug or a “feature” so I thought I would post it here and see what you think!?

Basically if you create a script and have it execute on a frame change by using either the frame_change_pre or frame_change_post handler you will get predictable and repeatable results ie the script is run once per frame.

If however you enable motion-blur in Cycles while rendering, the script will be run multiple times per frame. This is because cycles jumps the frame counter back and forth behind the scenes to generate the motion-blur, screwing up the frame change handler.

I don’t know if this would be considered a bug in Cycles or the Python API because technically both are doing what they should be doing, its just that they are not working together in the expected way.

I just spent about three days looking for bugs in my scripts before I realized it was due to the frame_change_pre handler being called more than it should, hopefully this post will prevent someone else from doing the same :frowning:

2

The way I have handled that case in the past is to leverage the render_pre and render_post events as well. Inside render_pre set a global flag like “i_am_rending = True”. Then in your frame_change_pre examine the flag and skip operations if you are indeed rendering. When the render_post fires set the flag to False.

If you really need to update while rendering your render_pre can go even further and examine that state of the motion blur checkbox and set another flag to determine if you are rendering and motion blurring.

Not ideal but you might be able to defend against the recursion.

Another check I put in place for frame_change_pre is to examine the current frame. If I am on the same frame then no need to update again.