i wonder how it gets decided what is going to get put in,to a version, i mean i'm sure they try and balance progress so as not to let any of the main 3 SI-MAYA-3ds get ahead of one another, even max got a crowed sim, this time round. keeping everything in a state of perpetual stagnation, sigh.
On 2 April 2013 20:32, Eric Cosky <e...@cosky.com> wrote: > I have to chime in and say that I wish someone in a position of authority > over Softimage would pay attention to what Matt Lind has been saying and > take care of some if not all the things he has been pointing out. I agree > with almost everything he has said, both in this thread and the many he has > written in the past regarding the shortcomings of Softimage specifically in > relation to game dev work and real time shaders.**** > > ** ** > > I don’t like to complain but this morning I just sent another check off > for another year’s subscription only half heartedly because yet another > year has gone by without proper DirectX shader support which is the main > feature that convinced me to get into Softimage in the first place. At the > time, nobody else seemed to be moving in that direction and Softimage’s > approach seemed very promising. I discovered early on that it wasn’t > working well, but I trusted that it would be fixed soon if I kept > submitting bug reports because SI had been promoted as an excellent > solution for creating game assets targeting DirectX. In fact, of the “big > three” Softimage was arguably promoted as the ideal one for game dev. > Several years later, I still can’t use DirectX shaders as part of the > Softimage workflow (and I have yet to hear of anyone who has). I won’t > reiterate the many specific problems that have been pointed out before > regarding Softimage’s problems with DirectX shaders, I’d rather just refer > you to Matt’s numerous detailed posts on the subject in this mailing list > and what I expect is a sizable list of reported bugs filed with AD. I > continue to be disappointed that feature as significant as DX support has > such a low priority for defect fixes and enhancements. **** > > ** ** > > So why did I bother resubbing despite the ongoing disappointment with the > main feature I got into Softimage for? It’s not for the new features, which > are pretty cool but I don’t expect to use anytime soon. One big reason is > that our pipeline is pretty dependent on Softimage at this point, but that > can change – we don’t have the years of assets built up for a large single > project that other people have to deal with. The main reason for sticking > around is that the 2014 bug fix list was pretty good, best ever perhaps. I > see this as a sign the team might be able to actually address more of the > years-old issues with the blessings of management (which would be great). > That being said, I wish I had time to re-evaluate the other tools out > there to convince myself that Softimage is still the best choice for game > dev; there’s been some pretty amazing videos lately coming out of other > tools and at some point I’ll have to take a closer look if Softimage isn’t > able to step it up. Not that I want to, I know the grass isn’t always > greener and disregarding the fact I have years invested in Softimage I just > plain like the tool and the community around it, and want them both to > stick around and do well. **** > > ** ** > > If the team is able to spend their time fixing more bugs, solve some of > the RTShader/gamedev issues and improve the UV/Modeling toolset I think I’d > be a pretty happy camper. I have mixed feelings right now but I remain > hopeful there will be progress in the coming year.**** > > ** ** > > ** ** > > *From:* softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] *On Behalf Of *Marc Brinkley > *Sent:* Tuesday, April 02, 2013 9:18 AM > > *To:* softimage@listproc.autodesk.com > *Subject:* RE: Softimage 2014**** > > ** ** > > Also agree on these.**** > > **** > > One of my long time SI artists even jumped ship to Modo for modeling and > texturing work.**** > > **** > > Modernization of the existing tool sets like Matt is pointing out is > really needed. UV editing being a big one along with modelling\topologizing > tools and bone tools. **** > > **** > > > _______________________________________________________________________________ > **** > > *Marc Brinkley***** > > GO GO GO**** > > Microsoft Studios**** > > [Fun]ction Studio**** > > marc.brinkley [at] microsoft.com**** > > **** > > *From:* softimage-boun...@listproc.autodesk.com [ > mailto:softimage-boun...@listproc.autodesk.com<softimage-boun...@listproc.autodesk.com>] > *On Behalf Of *Szabolcs Matefy > *Sent:* Monday, April 1, 2013 11:54 PM > *To:* softimage@listproc.autodesk.com > *Subject:* RE: Softimage 2014**** > > **** > > 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:* softimage-boun...@listproc.autodesk.com [ > mailto:softimage-boun...@listproc.autodesk.com<softimage-boun...@listproc.autodesk.com>] > *On Behalf Of *Matt Lind > *Sent:* Friday, March 29, 2013 8:51 PM > *To:* softimage@listproc.autodesk.com > *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:* softimage-boun...@listproc.autodesk.com [ > mailto:softimage-boun...@listproc.autodesk.com<softimage-boun...@listproc.autodesk.com>] > *On Behalf Of *Luc-Eric Rousseau > *Sent:* Friday, March 29, 2013 12:06 PM > *To:* softimage@listproc.autodesk.com > *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" <ml...@carbinestudios.com> 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:* 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> 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.**** >
