>>Basically the guy took
24 minutes to explain a 2 minute concept.
Its true, I did take the
long way around. My goal was to make sure that everyone... if they were
complete newbies, or seasoned veterans could grasp things. I have been
amazed at how hard the idea of abstracted weights has been for people so
I took my time. I was also asked by Hippy to breakdown somethings in
the way he wanted so there was some time there too.
>>The main point is Modo can define
the order in which deformers are evaluated to solve envelope weights,
and envelope weights are assigned using 'weight containers' which are
logical assignments of points to deformers. A different
kind of weight map.
You can assign a
standard weight map to a deformer too, weight containers are just
another method to do so. As Tim points out, a Weight Container is
really more like a Weight Map Item (or Proxy) it allows you to feed
them into deformers even when no points or "weighting" has been added to
them. The key concept here is that with WCs you can build a
complete rig with no mesh involved at all... load this into a scene and
then just add the points you want to weight into the WCs and the
deformation setup will work on them. Once you do add the points in them,
you can adjust the weights like you would with any weight map.
>><SNIP>In Softimage you'd normally place
the bones into a hierarchy and assign the weights to the
joints. <SNIP>
>>In Modo, the weights were assigned
to the individual bones via 'weight containers' (their version of a
weight map), but the bones were not placed into a hiearchy. <SNIP>
Modo
allows you to work in this traditional method too... add a set of
joints, in a hierarchy, to a mesh through the "bind" command and all of
the joints will be assigned a set of weight maps. You can then add or
subtract weights like
you are used too... if you add to one joint it will take away from
another. The WC way of working is not the only way.
Also there is no "metadata" on a Weight Container, as far
as the system is concerned its just another weight map. Its just defined
a bit differently and provides a more flexible approach to how weights,
rigs are applied and created.
>>The part I take issue
with is not having bones in their usual places will make it difficult
for animators to judge how the character is moving when adjusting keys. After all, you don't generally envelope a rig
unless it's expected to be animated, so why disassociate the bones from
the animator's perspective?
I did not cover all the different ways to use Order of
Operation (OOO) deformations with using a hierarchy... so let me try and
clarify a bit. You can use a standard hierarchy of bones if you want
with the OOO method (with or without using Weight Containers) you just
need to tell your joints to pass their local transformations into the
deformer (which is just setting on the joints themselves). So you could
have your standard set of joints and the animator can have access to
them in the way you describe there. There are also other ways to provide
controls to animators that don't require the joints... more on that
another time.
Anyway, I didn't show local transformations in the
video because I was trying to make the idea of OOO
very clear. To show the joints moving in local space seemed like it
would cause more confusion.
>>The
part of greater interest was pre-evaluation and post-evaluation events
which gives the artist the opportunity to further modify the resulting
deformation as each
>>deformer is evaluated.
This is THE most important part of modo's
deformation pipeline... Order of Operation. Its something I was exposed
to at Rhythm and Hues and it was a mind blowing, eye opening experience
for me. When I saw that modo was tackling
deformations in the same way I was very excited. I was also impressed
that Luxology was able to come up with a way to provide the standard
normalized approach to weighting in a OOO system (using normalization
groups). Basically you can have your deformation cake and eat it too.
>>The
example given was not very good as it could be easily replicated using
linked parameters to drive a lattice or some other easy control, but in
more complex cases could be useful for sculpting
the envelope deformation in very specific ways.
That example was more illustrative of the issue at hand than a
true practical case, that said, its how I would handle sculpt offsets
for an elbow I was rigging too. I personally find it about
as strait forward as you can get. I like having explicit point control
over my shape.
>>You can replicate most of it in
softimage using a different strategy than is typically used, but some of
the more advanced stuff, such as compensation, would require a custom
envelope operator or ICE.
Of that I have no doubt... the stuff you guys
can do in ICE is down right amazing :)
