Slow InsertKey for Many Pose Bones

Here is a description of what I am doing:
Via a python script I need to load 700 armatures each of which has 70 bones with 2 key frames. Keyframes are defined with the following call
pose_bone.insertKey(arm_ob, frame_number, Object.Pose.ROT)
As I define armatures the call to to insetKey() becomes very slow. This seems to be associated with the slow creation of channels (one channel per bone). As the number of new channels increases the cpu time associated with the call to insetKey grows in a very non-linear manner. For example, for the first call cpu time is 0.002 s and by the 49,000 th call to insetKey() cpu time is 2.0 s.
Is there a way to make things run faster? Is there an alternative to creating channels via insertKey()?
PS: using Fast = True does not decrease cpu time.

Here is your solution:

pose_bone.insertKey(arm_ob, frame_number, [Object.Pose.ROT], True)

the last “True” parameter tells the insertKey function NOT to update the IPOs/Actions or whatever is causing the function to be slow.

HI Didu,
Thanks for the response. At the end of the message I noted that I tried using Fast = True. This does not significantly decrease cpu time. So the problem does not appear to be associated with IPO editing. Interestingly, if I loop over the 49,000 bones a second time after channels have already been created via insertKey and then perform insertKey a second time ,cpu time is always 0.02 s per armature as opposed to 2 s.
That is if each bone already has an associated channel. inserting key frames is fast. If a channel must be created for a bone via insertKey, cpu time scales in a non-linear poor manner with the number of bones created.
Any ideas?

That sounds like a crazy and quick animation. :smiley:
With that many bones you should make at least 3 key frames.
Are you trying to implement a MASSIVE for blender?

Sorry, I have no idea then. I noticed that the Fast parameter makes a significant difference for armature animations that are longer than 200 frames, however, if your animation is only 3 frames, it shouldn’t really make that much difference whether you use Fast or not.

If the delay is caused by inserting the first key frame of an armature, then I doubt you could get rid of it.


I am modifying Blender for scientific applications. So far it is working very well for very large scientific problems. This insertKey() issue is the first major bottle neck I have encountered.
2 key frames per bone gives —> up to key frame 1 no rotation, between keyframe 1 and 2 a fraction of rotation, after key 2 100% rotation. This is what I am after. There is no need for 3 key frames here.

Hey Andy,
I am new to computer animation so I did not know what “Massive” was. Yes, what I am doing is very similar but for a scientific application.

That’s 49,000 bones…I did the math in my head last night,
and i thought 70 x 700 would be a lot more than that.
That’s a lot of bones for blender though, I think!
I was only joking about the 3rd keyframe also. :smiley:
I’m guessing it’s a scientific grass animation?
Good luck,