/ 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 untill 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.