[Bf-committers] New Modifier : Morph Target

k k kkmlist at yandex.com
Tue May 27 19:33:11 CEST 2014

Hi Patrick

Overall I agree about the huge  benefits and sexiness of  arbitrary shape/topology morphing however the lack of such feature in a property blender modifier like mine is not decreasing the value of MTM at all. In fact even just the fact that it can use the previous values(ie vert positions) from the previous modifiers (both the source and the target) is immense value to artists (modelers and riggers mainly).  

Put it this way you cannot do corrective morphing/shape fixing with the current SK system because it happens at the bottom of the stack while the corrections will have to happen later up in the stack. And MTM can let you achieve it. This is naturally a wet dream for a rigger. Arbitrary shape blending might not be so enticing to general rigging needs ;)

You can use ShrinkWrapping with  MTM to to achieve some fancy stuff at the moment, including morphing a plane to face. Now that is not a full arbitrary one to one form matching but still useful and it is almost there. 

To me spending time on pose space, adding stuff for particle morphing etc would be much better time spent at the moment.

If anyone is willing to add patches to expand the general idea of property blender/transferring, that is great.



27.05.2014, 11:39, "patrick boelens" <p_boelens at msn.com>:
> After thinking about this for a bit I think the main strength of this modifier would come from it's arbitrary topology mapping. Others have brought up subdivided -> low-res mappings and vice versa, which would be a big first step in this.
> After that - and perhaps I'm thinking way outside the scope here - it would be amazing if we could morph even something as simple as a subdivided plane into a face e.g. (I'm thinking projection along (an) axis now).
> At that point I think there would be more than enough differences to and advantages over shapekeys for it to warrant its own modifier hands-down. For me personally the one-on-one mapping of vertex positions would seem like the biggest workflow challenge this modifier doesn't yet solve, and is what keeps me slightly wary of this being a modifier that adds an extra layer of complexity for relatively little gain. If all we want to achieve is shapekeys in the modifier stack, I would probably vote for just that: a shapekeys modifier that simply can't be placed below topology-changing (adding or removing) modifiers in the stack.
> Just my $0.02,
> Patrick

More information about the Bf-committers mailing list