Actually, I find Modo's deformer stack as probably the most powerful I've used to date. Primarily because it's built on a concept that I don't think I've seen anywhere else. It's ability to mix-n-match normalized an Un-normalized deformers at will, and re-order them, is extremely liberating. I'd say its a lot easier to get things to work than within the constraints of a fully normalized system, where you're forced to sometimes really think about how to get thing to blend together to get the effect you need. Less need for coming up with masking mechanisms, blending systems, limiting selections, etc. I'm used to creating complex rigs to do stuff like that. Not having to do so in Modo was unsettling at first, surprising afterwards, a joy now. Modo still lacks a number of deformers I'd like to have. But if TF opens up meshes to the schematic in the same way they've done for transforms, I'll be able to build my own (Modo's schematic is already a sort of visual programming environment. Still in its infancy, but the foundation is solid). Then I don't have to rely on TF to give me more features (one of the reasons why I love Houdini/ICE). Can't wait...
Sergio Muciño. Sent from my iPad. > On May 7, 2014, at 9:40 AM, Tim Crowson <[email protected]> > wrote: > > The original question was whether Modo had any kind of modeling history. The > answer there is no (not that I've ever needed it either). > > The bigger issue is that Modo doesn't have 'operators' at all in the > Softimage sense. And believe me I miss this from Softimage. I still don't > know how I would do something like .... apply an MDD (deformer), then add > modeling operations on top of that (topo change), then add secondary > animation on top of that (more deformers)... There are definite limitations. > Especially with the demise of Soft, I've been trying to get the Modo devs to > see exactly why people like it so much, and the op stack is a major player, > not mention a good problem solver. > > That said Modo is not closed-minded to the notion of stacking operations in a > way that lets you edit them later... Its deformer stack is a good example of > this, and seems easier and more flexible to me than the equivalent in > Softimage. Someone with feet in both apps will have to tell me if I'm wrong > here (Sergio? Gideon?). > > -Tim > > > > > >> On 5/6/2014 5:07 PM, Matt Lind wrote: >> Under general modelling conditions, you're right in that most people just >> freeze it anyway, but there are workflows that come into play where you must >> have a construction history to employ. For example, primitive retopology. >> >> You may need to do a primitive re-topologize. So you get a polygon mesh >> grid and shrinkwrap it to the object you want to retopo. Although the >> shrinkwrap operator has an option to use nearest vertices, you end up with >> situations where the vertices on the grid collapse and target one or more of >> the same vertices on the target mesh. No good. To fix the problem you must >> move the shrinkwrap operator up the stack into the animation region then use >> the movecomponent tool (or just translate subcomponent) to move the points >> on the grid until they snap to a different vertex on the target mesh. This >> works because your movecomponent operation evaluates first, then the >> shrinkwrap evaluates with the vertex in its current location to find the >> closest vertex on the target mesh. Simple example, but illustrates the >> point. Also comes into play with enveloping and corrective weighting. >> >> These are the kind of flexible workflows we lose by not having a >> construction history. >> >> >> Matt >> >> >> > >
