Ehhhh, I’ve tested with envelopes. They’re still useless. I wouldn’t get too excited about that. Now, if we could scale envelopes along constrained axes and then heat weight based on the distance from envelopes rather than the distance from individual bones, we’d be in a situation much closer to Voodoo.
I dont understand what is hard about painting the current way,
maybe I am working with less polygons?
the clipping plane is your friend…
Aaaaaand here it is! It’s officially in master:
https://developer.blender.org/rBc16a8983efba9ecacd8da408d03c37a55483e528
It’s now called “Corrective Smooth Modifier” (aka delta-mush). That was the fastest patch review, cleanup and commit to master I’ve seen. 
Big thanks to Jack and Campbell. Well done!
Not every patch is equal: there are some patches that are more equal then others <sarcastic grin>.
Thank you so much for this !!!
World class, baby.
I’ve played around with this for a brief period of time, and it looks awesome! The only request i’d make would be the ability to somehow bake the results by replacing the existing bone weights (if this is at all possible), so it can be used for game development purposes.
Awesome !!!
This is possible, (not even that complicated in fact),
- one of the first things that crossed my mind when looking into the patch.
but there are 2 caveats.
Adjusting the weights wont be a 1:1 match, it can only be an approximation of the modifier results.
The resulting weights depend testing specific poses, which differ from the rest pose. To do this effectively you would probably want to input a pose and calculate the weights that are closest to this pose. The problem with this is a pose wont necessarily test all deformations. - So you could use entire action (animation) instead of a pose, then mix the result.
Another option could be to automatically rotate each bone and calculate weights at each rotation (accumulate and apply back onto the mesh). The problem with this is you would most likely end up taking poses into account that would never be used in practice (physically impossible/unlikely poses), it may be good-enough, so worth looking into, but I’m fairly sure it would give worse results then testing real poses.
if you could bake all animation poses possible for a armature,
and store it as a tree this would allow for almost instant animation?
for realtime rendering or a game engine?
And yet you would need to still calculate the way the mesh moves between baked poses, you would still have to do a bit of calculation either way so you still might have a slowdown with lots of objects.
If you’re hoping for an almost ‘free’ method in terms of performance, you’re not going to get one, sure you can try to cache all of the possible transition frames to a list or table of sorts, but at a high RAM usage cost.
http://research.cs.wisc.edu/graphics/Gallery/SkinFromExamples/ is the paper for baking arbitrary deformations to bone weights. You could probably add a step as ideasman42 suggested to generate the poses with automatic bone rotations.
As far as recording poses and interpolating between them at run time, as BluePrintRandom seems to be suggesting, this is more like Pose Space Deformation. Afaik there aren’t any game engines that support it. It is certainly an approach that going to be quite memory intensive, depending on the number of poses, and still adds extra processing time in the shape interpolation step. There is also a similar solution that interpolates whole shapekeys in pose space rather than per vertex offsets. This should be slightly faster to calculate, and probably easier to port to a game engine. This would also be easier to add to blender as it could mostly use the existing driver/shapekey system. Either way the memory cost of these methods is likely to be a deal breaker for games.
The example based skinning section on http://skinning.org/ has a good overview of these sorts of methods if anyone is interested.
hmmm… well a low poly actor uses 2.25 ms on animations, without a lot of bones… one actor…
Will the new scene graph optimisations fix it?
something that was both faster, and had better resaults would be appreciated…
You are far from the only one, just look through this thread 
This is a big one that gets quite a few people when initially looking into it. Skeletal animation has the amazing property of being fast & easy to offload to the GPU. The downside that vertices can only move as a linear aggregate of weighted transforms, which means a baked delta mush on a typical rig is simply going to get “good” weights, but still lose volume in extreme poses.
The way to get past this has been, in both the preeminent “skin from examples” paper and in work I’ve seen using it, to create a set of driven bones that give the bone weight “baking” operation addition transformations to use for a better fit to the exemplar poses. Generally this means a “half rotation” bone (driven value being the spherical rotation halfway between the rest pose and current pose) and two scaling bones for each important parent/child joint (driven values being a uniform scale up/down based on the angle between the connected parent/child bones).
The research papers implementing this create these driven bones for all bones & joints (i.e. a phenomenal number of driven bones which tends to negate the advantages of baking to a skeleton in the first place), but in practice & as a result of automatic bone set filtering operations there tends to only be a few which are applicable & so the rest can be deleted.
Straight mixing of the weights tends to give sub-par results. What works quite a bit better is to solve for the weights using a least-squares approach. Work out which bones should affect each vertex then across ALL poses, solve for the weights using a least-squares library (like OpenNL which we already use for LSCM). For even better matches, one can also solve for the initial vertex positions (holding the bone weights constant) which alters the model slightly but tends to get an even closer match to the example pose set.
I have found that, in practice using a plugin someone wrote for Maya, that you can generally just toss in real animations and things tend to work out well enough. Then again, my use case is games and they don’t tend to use too many poses in practice that aren’t specifically catered for in the source animations. It DOES take a bit longer to solve for those weights (given the sheer number of poses the animation set has available) but little hacks like using only every second or third pose can help there too.
For your realtime game use-case? Not really, no.
Sazerac I just wanna thank you so much for this!! Amazing modifier!
Just tried it in Gooseberry branch, fantastic!
I just came across this thread and I’m so excited! Thanks to you, Sazerac, and all who have been involved in producing this!
I’ve been doing some testing today with this modifier. I’ve run into an issue and I’m not sure if this is a bug or user error, but I cannot apply the modifier as a shapekey. ( I get an empty shapekey.)
First, the modifier must be after the armature mod or I get the “Not First in Stack” error. I cannot place the modifier before the armature mod, because this basically defeats the purpose of what I am trying to do. (Create a correctional shapekey based off of the Corrective Smooth Mod.)
Can anyone confirm that this is working as intended, or possibly give me a clue on what I could be doing wrong?
Thanks!
Version: dc95ca9
Interesting, I tested this myself, and yeah, it doesn’t work. I tested doing the same with the ordinary smooth modifier and that will correctly create a shape, so there is definitely something wrong. I tested doing the same with the ordinary smooth modifier and that will correctly create a shape.
It currently just uses standard modifier functionality for this, so I’m not sure what the problem would be, but I’ll take a look.
I raised a bug here: https://developer.blender.org/T44663 if you want to add anything
Thanks for looking into this, Sazerac. Having this functionality is important I think, because my testing has shown that different factor and repeat levels are often needed for different body parts. Having this mod respect the armature mod, at the very least, will help with the creation of corrective shapes.
It’s not a deal breaker as the modifier does a wonderful job by itself. Also, just adding multiple Corrective Smoothing modifiers with different vertex groups assigned, can achieve the same results. I’m not sure how much overhead or system slow down this will cause in the end.
Thanks!