I don't think you can compare ICE to those other examples you described. At this point, I think the only way for ICE to go down is for the entire package to be discontinued. We are tiny compared to your place, but we also need to build assets that last us for a long time. I use ICE for a lot of these things without hesitation because I really don't see it being ripped out or becoming unsupported at any point.
Also, I find it very stable; I've done many crazy things with it, and while it can sometimes be slow, it does not crash pretty much ever. Granted, kinematics is an area where I've seen some flaky behavior, but this may be from back when they weren't officially supported as I don't need kinematics much these days. On Thu, Feb 13, 2014 at 12:01 AM, Matt Lind <ml...@carbinestudios.com>wrote: > Part of it is circumstance, as in we only have so many resources. For > example, our art department is 100+, but I'm the only one in the department > who writes code and I'm currently tasked with significantly higher priority > issues helping out an under staffed engineering department than writing > one-offs for every artist who needs a button. > > The other part is pipeline management of a large scale software > development effort. We have a feature film sized team working to build a > high profile AAA title. With an engine and tools under constant evolution, > and life expectancy of 15+ years, you must choose methods of content > creation which can withstand changes to the software, such as Softimage, as > well as changes to the game itself. An asset created today must expect to > live for 10+ years without any further maintenance. If given the choice > between creating an asteroid belt using constraints vs. ICE, we'll probably > opt for constraints because we know it's a fairly stable and mature system, > which cannot be said for ICE. We've been bitten many times already such as > when we created a number of simulations back in XSI 5 using the Softimage > particle system only for the particle system to be ripped out and replaced > with ICE. We can no longer open those assets in Softimage. Same happened > again with updates to the realtime shader APIs. So now we must either live > with their current state of dysfunction, or rebuild from scratch. On > projects of this magnitude, risk assessment has a very high priority and > taken extremely seriously because one bad move can literally sink the > project if the ripple effect is large enough. While we do take measures to > abstract data from commercial tools, we only have so much programming power > in house to do so. > > The point is we cannot subscribe to workflows which are prone to human > error. Creating temporary data and expecting the artist to clean up after > himself has proven to not be reliable as assets are referenced by other > assets all the time. If crap is left around, then anybody referencing that > asset also inherits the crap which results in bugs in game. In film/video > you can sweep things under the carpet if they aren't perfect as long as the > problem doesn't show up on camera. We don't have that luxury. What you > make has to be functional and optimal for a live game environment, > conservative on resources, and not make any assumptions how it will be > used. Function has higher priority than looking pretty. > > There's a lot more to it, but I think you get the gist of it. > > Matt > > > > > -----Original Message----- > From: softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joseph > G. (LARC-E1A)[LITES] > Sent: Wednesday, February 12, 2014 10:59 AM > To: softimage@listproc.autodesk.com > Subject: RE: Survey - how would you do this? > > So cheese and monkeys aside. After 25 years as a 3D animator I've never > worked in games. So from a serious perspective I simply don't understand. > It's not clear to me why you aren't able to use ICE or scripts and freeze > those construction connections sending only the raw assets over without > ICE or scripting. What is it about this pipeline which makes that > difficult? > > -- > Joey Ponthieux > LaRC Information Technology Enhanced Services (LITES) Mymic Technical > Services NASA Langley Research Center > __________________________________________________ > Opinions stated here-in are strictly those of the author and do not > represent the opinions of NASA or any other party. > > > -----Original Message----- > From: softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind > Sent: Wednesday, February 12, 2014 1:35 PM > To: softimage@listproc.autodesk.com > Subject: RE: Survey - how would you do this? > > We'd have to add support for ICE in our exporter and pipeline management > tools. We don't have resources to do that at present. > > If the artist doesn't clean up after himself responsibly, it creates a lot > of problems. > > > Matt > > > > > > -----Original Message----- > From: softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau > Sent: Wednesday, February 12, 2014 7:21 AM > To: softimage@listproc.autodesk.com > Subject: Re: Survey - how would you do this? > > On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind <ml...@carbinestudios.com> > wrote: > > The solution is 100% art driven in this case and cannot rely on game > > engine logic or engineering resources. If it could, there wouldn't be > > a challenge ;-) > > > > Cannot use ICE, but you can use expressions, constraints, or animation > mixer to set up and plot out to explicit controls later if you prefer. > > > > A junior or staff level artist must be able to setup and complete the > task unsupervised in 30 minutes or less. Must also avoid creating any bugs > such as leaving temporary data in the scene or methods that require such > tactics. Bugs that make their way into the game engine are very expensive > to find, fix, and QA. Therefore, great emphasis should be placed on > technique and working cleanly. > > > > Sorry, I missed a bit. Why couldn't you plot animation by things driven by > ICE? Don't you have to do that for expression, anim mixer, etc? I mean > you don't have that in the engine either, right? > > > > >
