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 <[email protected]> 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 > <[email protected]> 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
