>><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*...
That's my biggest problem with it; its not *a* weightmap, its *a set* of them. Only being able to view/manipulate one weight map at a time is very Maya-esque and ugly. Unless I am missing something. On Sat, Apr 13, 2013 at 11:33 PM, Christopher < [email protected]> wrote: > Modo system is not hundred percent, quite different from Softimage. How > come Modo can do sliding skin and it seems that Softimage method I need > amount of time to setup, no walks in the park nothing ? :) > > Christopher > > Richard Hurrey <[email protected]> > Sunday, April 14, 2013 12:27 AM > Hey guys, Tim showed me this thread and I figured I would try to explain > things > a bit if I can. But first let me say I'm a big fan of XSI and the work you > guys do, though I have never used it myself, my officemate does and i find > it pretty awesome overall. > > OK... I'm going to start with going through Matt's mail and see if I can > clarify things > > >>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 :) > > > -Rich > Tim Crowson <[email protected]> > Saturday, April 13, 2013 11:11 PM > Rich may be along shortly to clarify some things... > -Tim C. > > On 4/13/2013 2:25 PM, Eric Turman wrote: > > Eric Turman <[email protected]> > Saturday, April 13, 2013 3:25 PM > It reminds me of weighting in Maya how each of the maps > were separate...what a PITA! Maya had (and maybe still has --I haven't > looked at 2014) the worst enveloping blech! > > > > > > -- > > > > > -=T=- > jo benayoun <[email protected]> > Saturday, April 13, 2013 2:33 PM > actually, this is not really new and is quite similar to the way > envelopping is done for years in the in-house 3D package at R+H from what > I remember. They had a complete different way to do rigging/skinning that > I was used to see in other studios. I wouldn't be surprised, this > feature is coming from one of those big. > -- jon > > > Le samedi 13 avril 2013, Sebastien Sterling a écrit : > Sebastien Sterling <[email protected]> > Saturday, April 13, 2013 12:39 PM > (this may be a stupid assumption) i didn't exactly follow all the dude was > saying, thx matt for the clarification, his examples where very abstract... > would being able to disassociate parent hierarchy have any effect on gimble > lock ? making it easier to evade ? > > > > -- -=T=-
<<compose-unknown-contact.jpg>>
