From IPO to IPO
/ by Toni
With Python drivers, textures and perhaps even modifiers in the horizon, and many new things like the Key module and the beginnings of the new Armature already in place, these times are quite exiting for those who use and develop Blender in Python. But instead of touching any of those new areas, here the focus is on animation scripting using the good old basic IPO module. For non-Blender users, IPOs are the Blender term/component for animation curves (keyframes are the defining controlpoints of those curves).
I have started using a method where create new IPOs for script-animated objects based on existing hand-animated objects in the scene, and try to share the techniques here. Creating IPO curves, which define the animation for the object for the whole duration of the shot/scene, is a simple way to have the scripted animation renderfarm-safe, and it also enables manual tweaking of the animations after they’ve been generated. These are the reasons for me having to port some previously made framechange-scriptlinked animation scripts, which work ‘live’ in Blender (are run always when a frame is changed), to these animation curve generating ones.
The method was ‘discovered’ (I don’t know if it is a common technique somewhere already, but am not surprised if it is..) for an animation where actually needed to know the coming locations of certain target objects ‘beforehand’, i.e. needed to start the movement of the scripted objects earlier so that they would nicely meet the targets in a certain point of spacetime. This proved quite straightforward with IPOs, and the Python module for it worked well (for once i was not using some bleeding edge code, so encountered in fact no bugs all in the process!). That pretty simple script is tested and demonstrated in typedance– you can first try seeing the hand-made animation (move in time by e.g. dragging the green horizontal line in the timeline or in the IPO window, or e.g press alt-a to play back the animation). Then press alt-p in the text window with the script, and playback / scrub time again to see what the script did.
The switchboard script was made originally earlier, as a test in September/October (after being inspired at Robodock :), and then suddenly used for the teaser we put together before the Blender conference. It features a bunch of wires that move individually, switching between plugs.
The first version was made using framechange-scriptlinks, which worked ok, but was quite uncontrollable (it was part of the fun, like Basse enjoyed having this artificial life form in his scene, doing its thing) and renderfarm-safety was left as an open issue. But it worked ok for the teaser – is actually the only thing that is animating in that shot with a lot of wires. This file is now provided as-is as switchboard1, For the actual scene we’ve been now working on, I had to add some features like ability to define a path along which the bunch of wires travels over time. This I got working by extending the previous code, earlier this week, as you can see in switchboard2
It was not until wednesday this week I realized that the IPO-creation approach would be the right for this switchboard script too. It guarantees right behaviour in the renderfarm, ’cause the animations are predefined and hance certainly the same for all the different computers doing the rendering. Also as the script does not do anything after it has been run to create the script, we are free to work on the animation curves manually afterwards. Obviously having the animation pre-generated is faster too, which also makes the manual animation work in the scene with the wires much nicer.
Furthermore, perhaps surprisingly, this approach also enables making the code simpler! A major problem with the framechange-scriptlinked approach was that current implementation of executing python scripts in Blender clears the namespace always after execution. So I had to use the Registry module to make the objects persist (the wires have to know from where and to where they are going), and it proved very clumsy because that module does not currently support storing objects of classes defined in the same module. So now with the ipo-creation approach everything is done in one execution, so everything works normally — all the python objects needed just are there.
I just got the code working today with the basic features needed, i.e. it reads information from what I’ve started calling a guide IPO, namely the SwitchMove IPO block, to shape the movements i.e. when creating the individual curves for the movements of the wires from one plug to another. It tries to be simple code, with some basic functions, and no classes yet. Currently it only works for a single wire, ’cause was debugging the IPO-creation with it (had funny bugs of course, like one that created curves like this: crazy ipo), so will still need to wrap up the odds and ends to have it fully usable again. But am happy that the hard problems in dealing with the different timings in an out the curves are solved now! :) That work-in-progress / proof-of-concept new version is switchboard3 (with the animation for the single curve created already). It looks funny ’cause the randomness happened to put several steps on one side next to each other, but when we have hundreds of wires in the final i bet it’ll look pretty cool..
So from IPO to IPO,
curve after curve we go..
(sung after the melody of the ‘from disco to disco’ (town after town) by the Helsinki House Underground (or something related))
will be off-line next week but hopefully the files are nicely there for people to see now, and if there are quickie questions perhaps this evening can reply .. will be back finalising the switchboard script after next week again then. feedback and suggestions are of course always welcome .. and and there are many things to add things, like using actions to animate the wire-connectors attaching to the plugs, but that is a another story i guess.
~Toni
« Mini Progress Report; Two | Live LSCM Unwrap »
This is a really cool script, once you get it finished I will give it a try.
Just, please, make nice comments on the code, so people who are newbies in Blender Python programming can understand how it works.
I have a nice thing in mind that could be done with the script, making a 4 legged robot dance on a checker board using randomness and using the nearest checker. Just a test to see if it worked out nicelly.
Also, the thinking behind this script can also be linked to Crowd Control, you also use randomness, control lots of objects and must be somewhat controllable.
Perhaps a Crowd Control script can be derived from yours, dunno …
Keep it up,
— Rui —
there are some comments especially in the last version, had to do that also to be figure out the right algorithms when getting the values from the guide IPOs and adjusting them to be correct for the created one .. but at least after the movie is finished, i guess we’ll all have to have good time for cleaning and documenting the files
we might use some sort of crowd control scripting in Elephants dream too, but the specific needs for that are open still .. we’ve drafted a walkstep system which is somehow similar to these (especially the typedance one) too. also looked at Blender People briefly, but don’t know yet if need that kind of functionality.
cheers and thanks for comments,
~Toni
I too was struggeling with the Registry module. But then I moved everything into the Blender-module.
Thank you for your scripts!
This is really fantastic stuff. This is like watching a DVD “Extras” disk, and thinking “Hmmm… I could try that sometime.” The difference is, here we can really see exactly how it was done!!!
To me, this scripting work really seems to be hilighting a ton (pun intended ;-) of un-tapped potential. :-)
Toni:
By saying that “this method is renderfarm safe”, are you implying that there are currently parts of the animation system that are *not* renderfarm safe?
Toni’s away for this week so I’ll answer here.
The previous quick and dirty method was using a scriptlink that decided randomly on frame change where the plugs would connect to. This meant that every time the script was run, you’d get different results, even between each time it was played back in the view, and even when it was rendered. It was completely uncontrollable but lots of fun to play with, and worked great for the teaser where we just rendered it out in one go, on one machine, and we weren’t worried about precision. In its previous state where it decided randomly on frame change, it wouldn’t be render farm safe, because each node would come up with its own random values on its own, so the frames rendered on different nodes wouldn’t work in sequence.
The current method featured here still uses random calculations, but it doesn’t happen on frame change – it just runs through once and bakes the results to Ipo curves. This makes it much faster to play back since the calculation is already done, it allows us to manually tweak the individual Ipos after the simulation has been run, and it means that the render farm just has to render out the baked animation, so it’s the same animation for every node.
Oh and yes, I just remembered that one thing in Blender’s animation system that’s apparently not renderfarm safe is slow parenting. Ton said he’ll see if he can fix that if we need to use it.
Cheers
If the BezTriple handle stuff could be fixed, that would be great.
Seems to me it was implemented by somebody who knows python but nothing about handles and async adding…
So what to use, setPoints() or points.append(BezTriple)?
If that stuff gets fixed, anyone can write a script to bake slowparents into ipo’s.
When loading switchboard3.blend in blender-cvs, I have the following error:
read lib /home/antont/elephant/production/lib/machine/switchboard/switchboard2.blend
ERROR: can’t find lib /home/antont/elephant/production/lib/machine/switchboard/switchboard2.blend
LIB ERROR: can’t find IPmove_target_a
stephane – switchboard3.blend has no relative path to the linked switchboard2.blend. The workaround is to recreate the mentioned directory structure (mkdir -p /home/antont/elephant/production/lib/machine/switchboard) and place the .blends in there. This solves only partly the problem, though :/
/Nathan
oh sorry, i should have tested the blends on clean machines / pack the data – can prepare new blends if there is interest.
Toni: if that doesn’t take you too much time that would be nice.
Stephane
http://www.blender.org/~antont/standalone-switchboard3.blend has that ipo made local now, does it work for you?
Toni: there is no more external links issues. Thanks.
btw BlenderPeople already bakes to IPOs, and is now getting rid of the MySQL dependency for easier installation (using SQlite first, could be full python too but the authors knows sql and it does the job nicely as well).
http://www.harkyman.com/bpblog//bparchive/2005_12_01_bparchive.html
in the meantime,
Blender core is also getting grouping.. http://www.blender.org/bf/0001_0100.avi
IpoedObject is kinda cool, but also sucky .. see http://www.blender.org/~antont/makewireipos.py for a perhaps-final version of the code, soon to be seen in the movie :)