Why are Shape Keys applied backward in animations ?? makes no sense to me !!

Hi all,
Well the title says it all: if I create a new Shape Key at frame 10, why is it applied also on frames 0 to 9 ?
If I wanted that Shape Key to work on all frames, then I would go to frame 0 to create it.
Unless I missed something ?
Right now I am creating the SK at frame 10, hit ctrl-I and then go to frame 0 to put a restrict view or set the value at 0…Anyone with a smarter workflow?

The first keyframe you set will define the first state of whatever you’ve keyed. Not just shape keys. Move an object to some arbitrary point in space and keyframe its rotation just on frame 50. If there are no other keyframes it will sit at that location from frame 1 until the last frame. If you want shape keys in a certain state on frame 1, put a keyframe on frame 1.

So how do you proceed when you have a 2000 frame animation and you want to create dozens of new shapekeys between frames 1000 and 1500 ?
After creating each of them, you go back to frame 1 to set them at 0 (or restrict vue) ? same thing at frame 1501 to turn them off again? quite tedious in my opinion
My point is why isn’t there at least a “hold forward” option for shape keys like the one for Actions in the NLA editor ?
Just my 2 cents

I thought the workflow for shape keys was you just created them all at any frame. They become part of the mesh. Then to switch between shape keys you animate the Value for a specific shape key from 0.0 to 1.0 at the time when you need them.

If you are creating a ton of shape keys why not just use bones instead? Then you would have NLA features too.

A lot of things might become clear if you … “Use the IPO Curves, Luke!” That is to say, to contemplate that these curves exist, and that they drive virtually everything about the Blender system, including shape-keys.

All shape-keying (of this kind) starts with some “initial state,” which is, like all keys, a cloud-of-locations. Then, you move things around and strike another key, say at Frame 1000. And maybe you do this two more times. Well, what Blender actually does is to compute the relative distance, for each point in the cloud, from the key-position relative to the initial state. And, through all of this, it creates an IPO-curve line.

Each of these states can be visualized as a horizontal line, with each point on the IPO-curve (Y-axis as usual being “time”) therefore being located somewhere between two adjacent lines. (There will be a total of three lines, one for each key, and the X-axis (Y=0) is the initial-state.) The distance in both directions (up and down) reflects the influence of these two shape-keys (and, only these two) upon the actual shape of the object at that instant. Each vertex on the curve of course represents an exact point that will be “precisely hit,” with every other one being an interpolation, in the usual way, between them.

Okay, this will normally produce a nice, smooth “morph.” But, oops, you say you want for it to happen suddenly, at frame 2000? No problem: just go to frame 1999 and strike a point squarely on-top of one of the lines (or the axis). Advance one frame and set another one. The next sudden-jump is to happen at 2500? Go to frame 2499 and set another point, exactly in line with the one at frame 2000 so that the IPO-curve between the two is flat. Advance to frame 2500 and set another point. Your IPO-curve now looks like a square-wave.

You say that “the animation is running ‘backwards?’” Well, that just means that the IPO-curve line is sloping downward, with the vertex at frame=0 at the top (y=1.0), rather than the bottom, so that the final-key is exerting 100% influence at the start of the animation, and the initial-key (y=0.0) is exerting 100% influence at the end. The curve, being an IPO, can run any way you wish. (If you remember the old “Chow Chow Chow!” cat-food commercials, that’s sort-of how they did it.)

Although Blender’s user-interface tries to keep IPOs more-or-less out of the way unless you want to see them, IPOs are the fundamental aspect of the entire animation system.

Yeah, I think he just means that he put a keyframe on a shapekey’s value on frame X and wants to know why the mesh is already displaying that value on frame 1. It’s because he doesn’t have some other keyframe on frame 1 to tell the mesh to do something other than the first keyframe it has.

Yeah, K Horseman it is exactly what you say.
I am just assuming that when we create a new shape key SK1 at frame X, then all previous frames (from X-1 to frame 1) should have SK1=0 as default.
Right now we have to go back to frame 1 to insert a keyframe for SK1 and set its value at 0.

Thanks sundialsvc4 for the IPO tuto.
It is probably the best way to handle that problem but as you probably guessed I didn’t dive into IPOs yet…

I am still very surprised that some “simple” tasks in Blender are not straightforward:
If I drag my rigged mesh +10 frames forward, then associated shape keys won’t move with it. As if there is no links in between mesh and shape keys. Quite strange
Again IPOs are probably the best way to do so but for beginners like me the learning curve is really steep.

In my case I even have to work with the NLA editor, not simply dopesheet, which doesn’t help.

Your over complicating it. you turn it on you turn it off. “Right now we have to go back to frame 1 to insert a keyframe for SK1 and set its value at 0” takes 1.3 seconds. How can it be more straightforward?

This is really simple. The IPO stuff is useful to know but that’s more complicated than you need just to understand what’s going on.

Only the keyframes you put in are the keyframes that exist. If you give it a keyframe that says “Apply this shapekey at a value of 1” and you never give it another earlier keyframe, that is the only value that shapekey has. If you want the shapekey to have another value on another frame, a value like 0 for instance, how do you expect Blender to know this if you never give it that keyframe? It’s that simple. Whatever values you want keyed, key them. That’s it!