Well, if you want to use the Apollo 13 analogy: NASA had teams of engineers to collectively work on solutions in parallel to get through that crisis. I don't have teams, it's just me. I have to choose between retrofitting the CO2 monitor vs. figuring out the LEM power up sequence for re-entry. I don't have the time or resources to solve all the problems. I have to pick one and address it the best I can. Perhaps that'll put it into perspective.
The quick snapshot of our pipeline is we currently have 450,000+ assets developed over nearly 9 years. Approximately 15% of those assets were created in XSI v6.x or earlier and haven't been touched since (largely because many cannot be opened anymore and we don't have time/resources to revisit). We were stuck on Softimage 7.5 for nearly 5 years, which comprises 70% of our total assets. Many things did not work in XSI 6.x or Softimage 7.5. So lots of crashes, corruptions, and bugs when working with that data. That leaves assets created in Softimage 2013 SP1 and later as truly eligible for working in ICE. That is about 10-15% of our total asset library because we've only been using Softimage 2013 SP1 since February 2013.....in fact, almost exactly one year ago today. Unless somebody can give me a magic 'cleanse asset' button, to use ICE on the older data is full of land mines and very high risk. To work around many of the issues, artists migrated to other software such as Modo, Z-brush, and so on, further fracturing our pipeline where work takes place, and reducing our needs to write tools in Softimage for art manipulation where ICE can be a meaningful contributor. The majority of the assets produced in Softimage are simple props, buildings for environments, or character animation of simple discrete sequences (walk, run, jump, ...). Artists have very small windows on the schedule to get assets done. Prop team, for example, they get a few hours to create an asset from scratch and complete it - modeling, texturing, and animation. They produce a few props apiece every day. To work that fast requires the asset be very primitive and workflow include a lot of corner cutting. The heavy lifting is done in custom editors for designing and modeling terrain, and placing items in the worlds. The art department is a factory for generating pieces in a LEGO kit where each piece is unique. It's very difficult to come up with cookie cutter solutions to the types of problems we face as you cannot make assumptions how individual assets will be used in a world. I have already coded up solutions for most of the problems we could think of such as taking clothing from one character and refitting it onto another, or remapping face animation between dissimilar faces of other characters while retaining intent of the pose. I tried re-writing those tools in ICE to provide more interactivity, but couldn't do it because ICE doesn't support needed features. Working around those limitations was more work than it was worth with a final result no better than what I was trying to replace. Since almost any tool created must talk to a SQL database, that puts constraints on where I can implement ICE as ICE doesn't talk to databases, or if it did, would probably pound it mercilessly. As for ICE itself: - ICE is not stable and mature in our experience. We've tested quite a bit since inception. - ICE crashes frequently on referenced models, 90% of our assets are referenced models. - ICE crashes frequently when manipulating texture UVs and cluster properties such as user normals. We use those properties very heavily. - ICE is very slow for kinematics. I tried it for a face animation system but the load was too much. I had to resort to the animation mixer w expressions. - ICE doesn't support NURBS for looking up closest locations on NURBS Surfaces where the surface is a surface mesh. I wanted to re-write our clothing refit and transfer tool, but couldn't because of this roadblock. I tried working around the problem with a custom ICE node in C++, but the SDK doesn't support location searches in custom ICE nodes. - ICE does not preserve custom data in topology operations. If an artist uses an ICE topology operator to do modeling, the asset loses its custom data to instruct the game engine how to use it which generates a lot of bugs in QA. I submitted bug reports to Autodesk, but it has yet to be addressed. ICE is not mature in the respect it's standards/ways of doing things keeps changing. Example - in softimage 7.5 and 2010 the way paths (fullname) were defined for parameters on cluster properties were not consistent depending on the context which you accessed them. In 2011 they changed again invalidating ICE compounds made in previous versions. We cannot afford those kinds of changes. We don't have the resources to go back and revisit tens of thousands of assets to make corrections. We need full control of the ICE compound version manager. I haven't spent much time on it, but in the limited time I have spent with it (a few years ago) it didn't seem very open. Softimage tended to automatically prompt the user with a dialog each time it found a compound that was out of date. I couldn't find a way to suppress it and drive it through scripting on a scene load event as there are times we do not want the update to happen. That is an important pipeline management issue for us. Bottom line - for most of the problems I need to solve which I've tried ICE, ICE has either crash and burned or come up short in feature set to support our needs. Believe me, I've tried many times over many betas and releases and many different applications in production. The bottom line is ICE is not tailored to our needs and is of very limited use/benefit. Therefore, it's not a priority to get it working in our pipeline compared to the many other issues I must address to get our game out the door. For sake of argument, let's pretend ICE does work and is fully mature. The context in which we can use ICE is not the same context in which you and many others use it in film/video. When you make an asset and render it, you can pretty much forget about it and move onto the next. We do not have that luxury. We must maintain our assets release to release in the same fashion a commercial application is developed. But since art isn't code, we do not have the luxury of modifying classes or sub-classing code to implement updates and have it ripple out. We must manually revisit assets to apply such updates. Since standards have evolved over time, it's not always possible to run a batch process to do these updates as there is no way to know which standard was in effect when the asset was last touched. Operators have very limited benefit in a games pipeline as they don't translate into the game engine. We have a proprietary engine which we built in-house from scratch. Our principal engineer was the inventor of HLSL and one of the engineers behind World of Warcraft's engine, so he knows his stuff. Our game engine already has its own particle system, does not support IK or other runtime effects coming from a content creation package (most MMORPG's don't). Our primary needs are data translation (import/export), database communications, texture unfolding/UV manipulation, modeling tools such as re-topology and polygon reduction, hardware (real time) shading -- All of which Softimage doesn't do very well. On a simpler level- the ability to store colors in a palette for use in vertex color painting and sharing the palette between environment scenes. The ability to paint a texture on a model in 3D. The ability to re-pack and relax texture UVs into a defined UV space without requiring the f'in Unfold operator. The ability to resolve real time shader parameter names of in render passes which are overridden. On the animation side, the only real benefit ICE can give is a custom constraint operator or perhaps a custom tail rig operator for some of our characters. All our deformations must come through envelopes, but since we have hard limits on the number of bones we can use, there isn't enough resolution for a cloth simulator or deformation operator to be of use. Each of our assets must live on its own in a vacuum inside a model so it can be referenced into other scenes. That means no external dependencies other than texture maps. What we really need is for the god damn real time shaders to function up to their name and have migration paths that actually work. That is highly important and has been our biggest issue. When art is generated and exported, it must be migrated into the pipeline so other departments can work with the data downstream in production. Scripters, designers, engineers, level builders, etc... It's not too difficult to introduce art into the system, but there is a lot of inertia to make modifications because of all the downstream dependencies. Once an asset is available, you have to make the assumption it's used anywhere and everywhere because if you rip it out or modify it, you may break many things with a very large ripple effect. Chasing down those types of problems is very difficult, time consuming and stressful if you do not know the cause. For that reason, introducing something which is still aqueous, such as ICE, into production that really doesn't need it, is really not a good idea So you tell me where I can use ICE that makes it sooooo important to make a round hose fit over a square filter for something of very limited benefit? I really want to hear this, Brad. Matt -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bradley Gabe Sent: Wednesday, February 12, 2014 5:47 PM To: [email protected] Subject: Re: Survey - how would you do this? Yup, if you were one of the NASA engineers back in Houston during the Apollo 13 mission, the astronauts would have all died. :p ICE not stable and mature? You're kidding, right? Some things are worth figuring out how to fit a round hose over a square filter. ICE is one of those things.
