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.**** >
