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: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, March 28, 2013 1:49 PM To: softimage@listproc.autodesk.com 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" <ml...@carbinestudios.com<mailto:ml...@carbinestudios.com>> 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.
