I have a problem with Shape Keys in Blender 2.62.
As you can see in the attached .blend file, I have a mesh that starts as a flat vertical surface (“basis” shape), then it deforms to a bent surface (“key 1” shape), and then… I would like to have its upper part flattened, like in the attached screenshot, in “key 2”.
The problem is that after selecting the vertexes that I want to flatten, if I scale them on the Z axis to 0 the results is NOT what I want, and surely those vertexes haven’t the same Z values.
I know that their “real” location is not the one I see when “key 2” is selected, and I can confirm it by selecting them and seeing where the manipulator is placed. But if I choose “Key 1”, it is possible to obtain what I want, and the position is exactly the same where they are in the viewport. This fact suggests me that the real location of the vertexes is NOT the “basis” shape key…
The main question is “how can I do to obtain what I want”, but I would also like to learn more about this subject, too bad browsing Shape Keys tutorials I always find cases that I’m able to handle, like a face opening an eye, the other eye, smiling… all actions that involve different vertexes, that’s too easy :o) …My problem arrives when the same vertexes undergo different sequential transformations. I thought that the “relative” checkbox allowed me to modify the next Shape Key using the previous one as starting point, but it’s not exactly the case… Is there a tutorial/document covering this subject?
This is something that I think Blender handles very poorly.
I have a solution for you, but I really feel like ranting first. Feel free to skip to the solution
RANT:
Blender has an option to apply shape keys while in edit mode … that’s great, but when you’re editing a shape key, it applies your edits to the undeformed vertices of that shape key - it doesn’t apply your edits to the mesh that you see on screen. This really bugs me. It’s obvious to me that we should be able to edit the mesh as it is visible to us. I consider this a bug - other people consider it to be “just the way it works”.
Similarly, Blender is set up really bad when you’re editing the basis with shape keys applied. When you edit the basis, you expect your edit to also be applied to all the other keys. This does happen … but only after you leave edit mode! What happens then is that when you move a basis vertex, Blender sees an offset between the basis and the other keys, and then displays the vertex moving in the opposite direction in spite of the fact that in reality is is moving in the correct direction!
SOLUTION: Use “blend from shape”
Ok, here’s what you do. Turn off all shape keys. Start with key2 looking exactly like the basis. Select the vertices that key2 will flatten.
From now on, make sure you’re editing key2.
Hit ‘w’ -> “Blend from shape” and select “key1”.
Your middle vertices will make a little arch, while the others will remain in the basis position.
Put the cursor at the bottom-most point of the arch, scale the vertices towards the cursor so that they all have the same z value.
Now we need to remove shape key1’s offset from the center bridge. To do this …
Hit ‘w’ -> “Blend from shape” set the weight factor to “-1” and check “add”.
Your end result should have all of key2’s vertices in a vertical line, but they’re not all evenly distributed.
When you apply key2 on top of key1, the bridge should flatten.
I used the description of the shapes the OP needed and was able to do this easily with no issues, the mesh edited exactly as expected, and the flattened portions were made with Scale Z to zero in Edit Mode operating on selected vertices. Here are my steps:
Create Plane object and subdivide it.
Create first Shape (Basis) as flat plane.
Add Shape Key (Key 1) in object mode
With Key 1 selected in the Shapes list, enter Edit Mode, select a row of vertices down the center of the plane, translate it in Z using Proportional Editing to form the arch. Exit to Object mode. Plane flattens to Basis because Key 1 is at value 0.
Add new Shape Key (Key 2)
With Key 2 selected in the Shapes list, enter Edit Mode. Use Blend from Shape to give Key 2 the arch from Key 1, basically copying its shape. Select adjacent rows of vertices at the peak of the arch, Scale in Z to 0 – selected portion of mesh flattens to the median point of the selected vertices. Exit to Object Mode, plane flattens because Key 2 = 0.
Now, using either the pinning button, or by entering value 1.0, Key 1 and Key 2 can be invoked. In animation, a transition from Key1 to key 2 shows the arch flattening out.
Note: This file was produced in 2.61. More recent builds of 2.62 incorporate B-mesh, which is known to affect mesh editing, so there may be some issues arising from that if using a recent 2.62 build.
The pinning button is found beneath the shapes list window, with a top-hat style pushpin icon and the Tool Tip “Always show the current Shape for this Object.” The current shape is the one selected in the shapes list, regardless of its keyed value. It’s used during editing of Shape Keys with the Sculpt tools, but can also invoke the current shape at any time.
Thank you for these informations. As soon as I’ll be in front of Blender at my place, I’ll test them both!
Your posts were very helpful, including the ranting (to have an opinion from more expert persons). I still didn’t know about the “blend from shape” feature, I’ll try that as well!
His method requires that you turn off key1 as key2 turns on.
In my setup I turn on key1 and then key2 is added on top.
Chipmasque, your method avoided my problems because it doesn’t require that you edit a blended mesh. But there are situations where you must edit blended meshes … and blender is bad at this. Say you’re doing some facial expressions. I have two overlapping shapes, say, a raised eyebrow and forehead wrinkles. I make each shape alone, and they look good. Then, I test to make sure they blend well by turning both of them on.
But what if they don’t blend well? You need to edit the mesh, enable “Apply shape keys in Edit Mode” and modify one or both of the keys until they look good together. But when I do this, Blender’s edits my vertices as though only the current shape key is on.
So tools like “Smooth vertices” or “scale along normals” don’t work on the blended mesh (and these are exactly the tools I need to smooth things out) - they behave as though the mesh I’m viewing is only the key I’m currently editing.
In the case you mention, I’d approach the problem by creating a shape key using Blend from Shape twice to create a blended but discrete shape, or by using Blend from Shape on only selected vertices to do something similar. In previous versions it was possible (iirc) to create such “hybrid” shapes by simply adding a key at a frame where the shapes were blended. Not sure that’s now possible, and Blend from Shape sort of replaces that capability. Once the blended shape was finalized I’d go back to its component shapes and use Blend from Shape to tweak any precursor shapes.
I did something very similar in Kata when editing the Cloth-to-Shape Key conversions I used on the character’s costume pants, and on the undulations of the “Shadow Dancer” antagonists. Obviously I couldn’t edit a shape for every frame, so there were many times where had to generate new keys from blends of existing ones, and then retro-fit that new shape to its components. Blend from Shape was extremely useful in that process.
The problem with editing a shape that is produced by the blend of key values is that it isn’t really possible to know which of the two shapes being blended needs to be modified by the edits. If they both are, what’s the percentage each gets modified by? So the edits are applied to the current (selected) shape, assuming that the modeler wants the edits applied there. The intermediate value-blended shape does not exist as a discrete set of vertex locations the way a modeled shape does, so any edits made really have nothing to apply to except the current shape. Creating a specific and separate blended shape does create the set of data that can then be modified.
Hope that makes sense.
BTW, I’ve also used this method for facial shape keys, and found it very effective.
That sounds like a reasonable workaround so long as there isn’t too many shapes thrown into the blend - I might try that.
There shouldn’t be any confusion which blended shape to edit - blender should edit the selected shape only. It’s the behaviour of the editing tools that I’m concerned about.
Say I have a blended shape of key1 key2 and key3. I want to edit key3 to make sure it blends well with the other two … say I want to do an edge slide.
When I slide the vertices, the user expects the vertices to slide across the surface of the blended mesh, but that’s not what happens. Blender instead moves the vertices across the surface of the unblended key3, resulting a bizarre and useless transformation on the blended shape. Ideally what should happen is that Blender behaves as the user expects, but then when the user clicks the LMB to apply the edit, all the changes are applied to key3.
The trick in this case is that Blender doesn’t simply apply a regular edge slide transformation, but instead would have to figure out where to move the edited key3 vertices to produce the result seen in the viewport. Presumably this would involve subtracting away all the other blended shapes.
The edits made are relative to the selected shape, because there is a data set on which the modulations can operate. With a value-blended shape, there is no recorded data set, it’s just a transitory hybrid that results from calculation of the shapes blend. While it might be possible to code for operations on this transitory data, I think the algorithms necessary to then break down that edit so that it applies properly to only one of the component shapes would be more than a little difficult to accomplish. It would require deconstructing the edited hybrid shape, analyzing how it differs from its unedited form, then deconstructing the differences to calculate how they would apply to only the current shape, keeping the influence of the other components in mind as well. The amount of calculation needed may drag down the operations so much it’d be more than a little inefficient.
Phillipe: I cannot comment on the use of Absolute keys because as yet, I haven’t needed to do that. But the Blend from Shape tool will do exactly what you want very quickly. Simply select all vertices in the new shape, invoke Blend from Shape, and apply the previous key’s shape at 100%. Then edit accordingly.
Blend from Shape is extremely versatile, as it can be applied to only selected vertices as well as the entire shape, something that creating a shape from the previous shape would not permit. The proportional shape-blending capability makes hybrid shapes much easier to achieve than previously. All in all I thinks it’s a major bit of progress in handling shapes, which along with the UI changes, makes them a great deal more manageable. Granted, there may be some “2.4x unlearning” to do, but that’s always the case with major revisions to software.
@Chipmasque : thanks for the advice. I will try this Blend from Shape feature ! I am very frustrated, because I mastered Shape keys in the past with 2.49, and even did tutorials, and now I am not able to do anything good in 2.6x… I hope that something will be done to include these features in the manual on day !
Using Relative keys for a walkcycle may be difficult because the animation is made of many Ipos instead of one, and this could make the animation difficult to be made cyclic…
Would it really take so much resources? For a mesh of N vertices, and S shapes, it’s O(N*S) operations to construct or deconstruct a hybrid. You would have to construct and deconstruct the hybrid only once per edit, and Blender is already doing the former task to display the hybrid in the viewport. The hybrid can be stored for the duration of the edit, and then tossed. Is that a wasteful use of memory? It would be like keeping the equivalent of one shape key in the memory.
If you have a huge mesh, and a hundred shape keys, I can understand how this could become cumbersome, but this doesn’t strike me as being a typical use of the shape key functionality.
Your analysis kind of ignores the process of determining what portion of the current edit (as reflected in the transitory hybrid values of the vertices + any edits made) are then applied to the Active, selected shape key. The edits made on the transitory data have to be applied to one of the recorded keys, or when the transitory value is tossed, the shape edits are, too. So let’s say you have three keys forming a particular transitory hybrid shape. You edit a vertex. What portion of the dLoc of that vertex should be applied to the currently selected key? All of it? But that would ignore the contribution of the other two keys to the hybrid shape, so somehow those shapes need to be “subtracted” before a value for the dLoc could be determined and applied to the single current key. Seems like a lot of additional operations for not a great deal of benefit, when the hybrid key can simply be made “real” and then edited as usual.
What I had in mind was a sort of automated version of what you had described earlier.
From what I understood, the manual process was this:
Create a copy of the hybrid, edit it, and apply the change to a key of your choosing. Presumably this would involve subtracting the blended keys from the hybrid (according to their weights) to isolate the key you want to target. The remainder would then be copied to the targeted key. Maybe I didn’t understand your procedure, but to automate this, the subtraction process would be O(N*S), no?
I don’t think I’d be interested in a feature that modifies more than one shape key at once. I would want to control exactly what key is being modified - but that’s just me.
Edit:
Now wait a minute! Blender surely must already be doing something considerably more inefficient!
If you try and edit the Basis of a hybrid shape, what happens is that the vertices actually move in the opposite direction.
This means that Blender is updating the hybrid shape in real time before you finalize the edit! Wouldn’t it be considerably faster if the hybrid was copied and you edit that instead? This would use slightly more memory, but would be faster, and the editing GUI would behave as the user expects. Is there a reason it’s done in real time?
Can’t say I’ve run into the behavior you describe, I generally leave the Basis alone once I start editing shapes, it’s never been a simple process to propagate Basis edits successfully through all the keys. IIRC there was a script that could do that in 2.4x but I’m not really familiar with how it’s treated in current builds.
My comps are too tied up right now for me to do any testing on shapes to see what you describe and maybe get andidea of what’s going on, but once my renderings are done, it’d be interesting to look into it. The details of the innards of how shapes are done in 2.6x are beyond me, so maybe what you propose wouldn’t be as inefficient as I think. Best way to find out is to implement it! Script it, or build your own Blender with the modifications you mention, and test it out. That’s one of the beauties of Open Source, it can be customized as needed, and often someone’s bright idea ends up becoming the next cool feature.
Where’s a good place to get started if I want to learn about coding for Blender?
I’m reasonably experienced with programming, but I have no experience with Blender’s source code. I’m only inferring what Blender is doing from its behaviour.
The behaviour I’m describing is easy to replicate. Create a basis and one or two keys. Turn the keys on, and turn on “Apply shape keys while in edit mode”. Now, select the basis, enter edit mode, and try to edit any of the vertices. They will appear to move in the opposite direction. The more shape keys you have turned on, the farther the vertex will appear to move. Note that I say it “appears” to move because if you exit edit mode, the edit on the basis will be propagated to the shape keys and you will see what Blender actually has done - the vertex will now be seen where you actually put it.
From these facts I conclude that Blender is updating the hybrid shape in real time… if it wasn’t, we wouldn’t see the inverted movement.
Frankly, I feel that this renders “Apply shape keys while in edit mode” worse than useless for anyone trying to edit the basis because it confuses the user without providing any functionality. This had me scratching my head for at least a day until I realized what was going on.
At the very least, I would suggest forcibly disabling “apply shape keys while in edit mode” while editing the basis. This might be the best option if it turns out that there’s a good reason to have real-time updating.
Just so I’m playing on the same field as you, TS, what version are you using? I’ve been avoiding any builds that followed the incorporation of bmesh, as it tends to play mean with older files from what I hear, and isn’t yet stable in all aspects. I have the latest BF release version of 2.62 (r44136) available but naught beyond that.
