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

[Daniel Salazar - 3Developer.com]

Hi Aligorith, it does answer the question but doesn't solve the
problem, basically I would much rather prefer script links or what
ever system is used in 2.5 to run my script on frame change. If that
is absolutely impossible then I need a working system to bake object
and/or vertex data... but again.. it hurts me to have to bake data...
is there a way against this?

cheers

Daniel Salazar
www.3developer.com



On Mon, May 3, 2010 at 4:30 AM, Joshua Leung <aligorith at gmail.com> wrote:
> Hi,
>
> This function is really not intended for baking scripts. In fact, the
> "keyframe" system isn't meant for that at all in general. Only the
> "samples" system (which also gets stored in F-Curves, but instead of
> keyframes) is designed for this stuff. However, this is currently not
> exposed via PyAPI in any useful way, so unless you go via C, there
> isn't much you can do about this.
>
> 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.
>
> Now, the functionality your refer to is really intended for inserting
> the occasional keyframe (i.e. like a user does through the UI). This
> means on average once every 5-10 frames or somewhere in between. For
> that, it's perfectly acceptable, and probably expected, that the
> curves get recalculated nicely, and that it is fine to resize the
> keyframes array one item at a time (assuming that changes are
> infrequent, and nice playback speed without heaps of unfilled/unused
> mem hanging around is preferred).
>
> The samples on the other hand are based on the concept that in one go,
> we're going to set aside a chunk of densely-packed samples spaced
> evenly, and that we know exactly the range that these go for, and that
> we'd like to populate that set of values NOW (that's what baking tools
> do).
>
> So, apart from this not being exposed, why isn't this used more?
> Firstly, this was hinted at, but never implemented in the old Blender
> anim system too, so it's certainly not an entirely new concept, though
> it is probably foreign to most users for that reason. And a few tools
> now DO use this, namely sound and F-Curve baking.
> Secondly, I have not yet put in place much functionality to tweak this
> sort of data. Mainly because it is my intention to implement curve
> fitting tools to get a usable set of keyframes out of this noisy data,
> since editing such densely packed data is really not too feasible.
> This will hopefully come eventually, though there are heaps of other
> priorities at the moment before that.
>
> Hopefully this answers the question :)
>
> Aligorith
>
> On Mon, May 3, 2010 at 8:03 PM, Daniel Salazar - 3Developer.com
> <zanqdo at gmail.com> wrote:
>> (Intended for coders, please don't troll)
>>
>> So can anything be done to speedup bpy.ops.anim.keyframe_insert? I'm
>> using this to bake my scripts since I coudn't find any alternative to
>> scriptlinks (fail there from 2.5). My scripts run fast (in an instant)
>> but inserting the keyframes can make the execution time go up to
>> minutes. Is this lacking optimization? what's happening here?
>>
>> cheers
>>
>> Daniel Salazar
>> www.3developer.com
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>