Has anybody else felt frustrated by the appearance of a TimeIPO only in the Object IPO block? I had a use in mind for relative vertex keys, but I couldn’t put it to effect because I had already used a timeIPO on the object IPO block of that object. To illustrate the problem, lets say an object has location keys at frame 1, 101, and 201. It also has a TimeIPO with points at the following co-ordinates (1,1), (101,101) and (301, 201). So for the first 100 frames the object moves exactly as it would without a TimeIPO, then over the subsequent 200 frames it covers the distance between its keyframes at 101 and 201. That is to say, its speed is halved, and the journey time between those keys is doubled. So far no problem. But if a relative vertex key was then made to take effect at frame 201, it would do so without being affected by the TimeIPO. That is to say, the RVK deformation would not occur simultaneously as the object reached the position defined by its location keyframe at 201, but instead at the genuine 201 frame. At that frame, its location would be intermediate between the keys placed at 101 and 201. I imagine that similar discrepancies could occur between the other IPO blocks, such as animated materials etc.
Does anyone know of a simple workaround? I could do a bunch of calculations to work out how to synchronise the two, but in that case I would be as well not using the TimeIPO at all. I introduced it in the first place to simplify my calculations! Perhaps it would be best if a time IPO was incorporated into other blocks besides the Object block. Any thoughts, anybody?
I had a similar problem a long long time ago.
I wanted to slow down the middle of my animation - after I had animated loads before and after the point I wanted to slow it down.
I wrote a quick script to attach my timeIPO to all the objects in the scene, but then found that it didn’t work on RVKs.
I just had to hack around with the RVKs by hand to try to get it to match up with the rest of the animation.
It would be very useful if the timeIPO applied to everything animatable.
It would also be very useful to have a global timeIPO that affected everything in the scene.
I’m pondering what you say here and it does not seem to me that what you describe is quite within the scope of IPOs:
That is to say, its speed is halved, and the journey time between those keys is doubled. So far no problem. But if a relative vertex key was then made to take effect at frame 201, it would do so without being affected by the TimeIPO. That is to say, the RVK deformation would not occur simultaneously as the object reached the position defined by its location keyframe at 201, but instead at the genuine 201 frame. At that frame, its location would be intermediate between the keys placed at 101 and 201. (bold italics mine)
It seems that what you are really looking for here would be dependent upon a calculation, or trigger viz: “when an object reaches a certain position.” In effect, you selected “frame 201” because the object (absent the influence of a time-IPO) had reached the desired position at that point in time. Now, when the time-IPO exerts its influence, you still want the effect to begin when the object reaches that position, not that time.
This sounds like “a new fee-chur,” and at the moment I’m not quite sure what kind of a feature it would be; how it would be described and implemented. It sounds more like what “constraints” do, but it’s not really quite a constraint either. Python could undoubtedly do it, but trips through the Python system can slow things down… Hmmmm…
Thanks for your understanding guys. That was a hard problem to describe. It is always reassuring to find that someone else has been there. I’m nothing of a programmer, so the notion of writing a script still seems a long way off to me. It does seem like a “fee-chur” that would be better integrated into Blender than scripted though. Here’s hoping…
Nonetheless, it may well prove that Python is the solution de jour, because what you’re asking for is very similar to some of the requirements encountered by GameBlender programmers. Let’s see what the other folks say.