I'm with Matt in these.
I've asked for few features in Unfold, for example, I do not want UV Islands rescaled with each pack, because in games, I have to decide what areas have more pixel density, and it's always overwritten by packing. UV editor needs a lot more love. I love the UV Lattice in Maya (if I remember correctly), love the move and sew tool (which I wrote in Softimage, but due to a Softimage bug sometimes it doesn't align UV shells correctly), I would love to see symmetry in UV, and asked for fixing the proportional issue, when the proportional transforms affects the unconnected islands too... I do not know modo well, time by time I give it a try, and with my 4 years of hardcore LW background, I found it a bit clumsy however it has a great potential. Maybe I should do a complete project with it, but demo time is not enough, and to purchase it just for a test, it's not a good idea as well. I like it, but I always find something very irritating that prevents me to use it. However this new release looks really promising. I hope that the beta is going on, and there will be more and more service packs for SI to fix all the issues. I'm sure that developers will listen. From: [email protected] [mailto:[email protected]] On Behalf Of Matt Lind Sent: Friday, March 29, 2013 8:51 PM To: [email protected] Subject: RE: Softimage 2014 The issue isn't about whether history is available or not. It's about whether the functions we need to use are usable at all times and in all contexts. Softimage texture workflow only works in specific contexts. That is the issue. Softimage has a construction history which is useful for some operations such as enveloping or putting modeling operations in the animation construction marker, but those same workflows can also cause problems as it does with texture operations in conjunction with modeling. As for specific examples in Modo's favor: 1) UV unfolding and pinning I've been screaming about the past few years. Softimage botched that one. Modo's pins allow the rest of the unpinned texture space to 'solve' in the unfolding process. It's also interactive. I specifically pointed out Modo in the feature requests I submitted, but whoever implemented the pinning feature obviously didn't read the notes. Modo's tools can be applied at any time and in any order. Softimage's cannot. That alone is HUGE. Softimage lacks basic tools such as splitting and merging UVs along selected boundaries, aligning islands, and other expected tools for working with pelts and texture spaces in general. Softimage has the low level features such as tearing mode, but you have to work really hard to select the parts of the texture space to rip apart and isolate as desired. Artists often think in terms of polygon boundaries and tearing along boundaries between body parts such as separating the hands from the arms, or inserting a cut line along the sides of fingers so they splay nicely for unfolding and painting. Pinning and movable pins is a big part of this workflow. It can be done in Softimage, but it takes significantly more effort - especially with the botched implementation of pinning and rigid black box method of unfold's implementation. Tools work nicely together in Modo. The capabilities are there in Softimage, but tools don't play together as they should, and many expected tools are not implemented correctly or exposed to the end user. 2) Symmetrical modeling such as wrists. It's often necessary to resize or reshape local areas of the character per art direction. In the case of wrists, sometimes they are too fat or too skinny, need to be lengthened or shortened, etc. This is a difficult task in Softimage as the symmetry transforms only work on points. Since Softimage computes reference frames on point selections and doesn't give the artist much input in orienting reference frames, it's a bit of teeth pulling experience to make these simple adjustments as local axes don't necessarily align along the limb's length and perpendicular to the width as desired. Even if the reference frames (centers) are aligned, Softimage doesn't interpret the rotations properly across the axis of symmetry preferring to handle the case in object or global space instead of COG or local. I have reported this issue more than once. Softimage scaling defaults to prevent shearing by scaling on the local axes. Sometimes modelers need the global axis, but as you can clearly see on the MCP, global is not an option for scaling. 3) Another example is locking subcomponents in the topology to prevent accidental editing. This is critical for working with objects that have to join seamlessly with other objects. Artists can lock the points (and normal, and UVs) on the boundary edge so they are not accidentally moved but still allow them to model with reckless abandon on the interior of the object to be quick and efficient. Specific example - faces for bodies. Our characters have customizable faces which are plug and play like a Mr. Potato Head doll. If the customer wants the skinny face, then the skinny face is plugged into the body. If the customer wants the fat face, then the fat face is plugged into the body. For this system to work, all the available faces must have the same contours so they plug into the head seamlessly without cracks. When our library consists of 500+ faces and only one person to do that work, the artist needs the comfort of being able to work quickly without fear of destroying the asset or making it incompatible with other assets (body) it needs to work with. For faces it means locking the contours so they cannot be edited. Modo provides this functionality. Softimage does not. Softimage locks the entire topology of none of the topology. Even if custom operators are written to do the job, they are prone to be removed the next time the artist clicks 'freeze' or 'freeze M'. We've had this very discussion already. I have already submitted and described the above items in beta cycles and we had discussions about them. I'm really starting to wonder if it was a waste of time. I'm not a Modo user, but our character artists repeatedly come to me for basic things Softimage should handle, but doesn't. They want to use Softimage as it would reduce the number of hoops they have to jump through to get content into our game, but these frustrations add up over the course of the day. There are parts of Modo they hate, but the composite score is in favor of Modo vs. Softimage for primary responsibilities. Matt From: [email protected] [mailto:[email protected]] On Behalf Of Luc-Eric Rousseau Sent: Friday, March 29, 2013 12:06 PM To: [email protected] Subject: RE: Softimage 2014 Modo doesn't have construction history (afaik), what does it do to better deal with texturing and iterative workflow you mention? Le 2013-03-28 18:00, "Matt Lind" <[email protected]> a écrit : Freeze isn't 'deadly' per se, but it to get around many of the instabilities of Softimage we've had to resort to using it heavily. I don't think it's a case of which app mimics the workflow desired, it's more a matter of what problem we're trying to solve as artists producing content for a game development effort. What is deceiving is seeing a texture operator buried under a sample cluster, but it being affected by operations in the main construction history without a visual to inform users there is an existing relationship between the two. Users only look in the sample clusters when needing to get information such as the _Def property to animate the projection - which is not very often. When clicking "Freeze" or "Freeze M", it doesn't register in the user's mind the texture operator(s) will be affected. You also cannot expect an ordinary user to hover the mouse over the operator to get information. That is more of a TD thing when developing a new tool or workflow and would be used in building test cases, prototypes, or diagnosing bugs reported by artists. A niche case. The construction history needs a concept of selective freezing as opposed to muting or disabling from a given location upwards. Groups of operators need to be able to be merged or rearranged independently, possibly even flagged to be immune from freezing so only surrounding operators are frozen. Yes, there are dependencies in some cases such as with deleting subcomponents, but a workflow needs to be devised to better inform and work with the user's desires to edit topology. The most common reasons for freezing construction history are: 1) History gets too large causing performance slowdown and instability. 2) Content is in a finished state and needs to be published for use in other scenes by other users. Example, a prop or tree which serves in a larger environment, possibly referenced in multiple locations (eg. Hundreds of times). Any construction history that requires evaluation only bogs down the entire scene N fold. One problem with the freeze mechanism is it's not granular enough. Many a time an artist will accumulate hundreds or thousands of operators on the construction history while modeling, but can't afford to freeze the entire stack because he many need to retain a specific subset which is providing a certain workflow enhancement specific to the asset. The subset that needs to be retained will be buried in the middle of the construction history and cannot be isolated without significant work on behalf of the user, or cannot be isolated due to technical limitations of Softimage's architecture. Certainly been a gripe of mine dating back to v1.0. This is exactly the problem with texture operators. They live in the middle of the modeling construction history which forces the user to plan every edit ahead of time because as soon as they freeze even once, they've lost most of their texturing workflow such as the preserve UVs, or ability to unfold, or ability to use regularize and other needed features which are accepted as standards in other applications and can be applied in any order. I agree texturing should be the last step in the process, but game development is a heavily iterative process. It's extremely rare for an asset to not get kicked back for revisions, usually tens or hundreds of times due to art direction or game design modifications. Sometimes even for performance reasons as it may tax the game engine too much by invoking too many batches or pull too many textures flooding TRAM. Therefore it's not possible to do all modeling first, then texturing last. The tools need to recognize that fact first and foremost. If they don't, then it doesn't matter what fancy algorithms are used to unfold or do other fancy stuff because the amount of roadblocks of the basic workflow will outweigh the benefits provided by the fancy tools. This is exactly the reason why our character modeling team uses Modo instead of Softimage for their work. Modo's tools aren't all that fancy, but they work together in a nice convenient package. Softimage hasn't evolved much in this area in at least a decade. Matt From: [email protected] [mailto:[email protected]] On Behalf Of Luc-Eric Rousseau Sent: Thursday, March 28, 2013 1:49 PM To: [email protected] Subject: Re: Softimage 2014 which app works the way you think things should work? If "Freeze" is deadly in your pipeline, I'm thinking you could register a siOnBeginCommand event to trap it and do a different process. You can even abort commands, afaik Le 2013-03-28 15:42, "Matt Lind" <[email protected]> a écrit : > > No, I did not know this, but even if I did it wouldn't matter. You cannot > expect ordinary users to work like that when handling many assets per day. > Many of which they did not start themselves. Majority of users habitually > click "freeze" and "Freeze M". They don't even open the explorer even after > pounding it into their heads they should be looking there. > > > > This is an area that needs a serious re-think.
