[Bf-committers] bpy.ops.anim.keyframe_insert() massively slow

[Joshua Leung]

The situations you mention (keying to twos or threes or even on ones)
is not that bad as that kind of complexity is often well managed, with
little "noise" that'd probably need to be smoothed out of it. Also, in
these situations, you're not expecting to try to key this much within
say 1-5 seconds, but maybe more like over 5 minutes - 5 hours, and
maybe not even sequentially at that.

On Tue, May 4, 2010 at 12:24 AM, Charles Wardlaw
<cwardlaw at marchentertainment.com> wrote:
>>
>> Basically, why I strongly urge all baking to go the other way instead,
>> is that keyframes are relatively quite "heavy", especially with the
>> handles (which are of limited importance when you've got a sample on
>> each frame anyway), and also because all the keyframe tools assume
>> that they are not densely packed together in a bunch. So, even though
>> you may have situations where there might be a few relatively
>> "complex" F-Curves with keyframes, they really aren't as complex as
>> the ones here.
>>
>
> Hi,
>
> Sorry to chime in (and I swear Daniel I'm not trying to troll ^_^) but I was
> hoping for clarification: does this statement talk about keyframes made
> through the API (which are a special case) or keyframes in general?  As an
> example, the characters on our current (non-Blender) show at work are
> looking at around 1000 keys being made whenever you key the entire character
> (all controls and keyable attributes), which is a general practice.  It's
> also general practice to key down to twos or threes (and on fast motions,
> every frame), and there are plenty of shots with upwards of ten characters.
>
> Just curious.
> ~ C
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>