Matt makes some valid points and to me shows some of the (even these days) major differences between games and film/tv pipelines.
It¹s not that ICE isn¹t capable of doing amazing things, there¹s plenty example of that, but that when it comes to creating games assets and pipelines, its perhaps not best suited to some of the requirements. It¹s not much good creating custom ICE nodes and compounds, but they can in effect be useless, unless you can reflect the tool/tech in the game engine and/or get the exported. Sure you can bake as many have mentioned, but that doesn¹t always apply in all cases. Also it creates more data that has got to be loaded in game and memory, and as Marc says games is so often about balancing budget to get things running. Even when you have assets built to spec, you can still end up cutting back anywhere you can, to get the framerate. 30 fps was realistic, 60 was very often a dream. Game devs are renown for building lots of proprietary tools and technology, some of which is justifiable, others times they¹re reinventing the wheel. But I think some of that is changing. Whereas in the past games would literally write everything, more are now buying off the shelf with middleware for some things, and focusing their resources on the right things. It¹s simply not always realistic and financially viable to write everything bespoke. I used to be a firm believer of having a DCC as a game editor, as I¹d seen too many show off programmers thinking they could write their own Max/Maya and while I have seen some good editors, most have been poor. But I think Marc¹s points are very valid, I wouldn¹t take that approach now. I still think in the right context the DCC could work, but it depends a lot on the pipeline and the type of game being made. The game engine is always going to be the best place to view assets, as its the end result, but I¹d squeeze everything I could from a DCC before pushing my data through the pipe. I thought Matt challenge was great and very typical of the type of thing you see now in mobile/casual gaming. Simple data, simple process, get it down and get it out. On 13/02/2014 23:48, "Marc Brinkley" <marc.brink...@microsoft.com> wrote: >Just to tack on... > >Coming from UE3 and Unity, I can safely say that building engine >dependent tools\editors into a DCC is decidedly not the way to go. If you >can avoid it at all costs, I would highly recommend that. > >It's a slippery slope. You realize that most of the infrastructure you >want is already in a DCC so it makes sense to use that as a base...months >and years later you realize that was not a good decision. :) And now... > >My mantra over the last several years has been...the DCC is just that, it >creates digital content. Everything else is done in engine\editor. >Materials, post FX, physics, VFX, Fluids, lighting, animation sequencing, >cameras, terrain generation, scene assembly and so on should only ever be >done in your engine and editor. > >And I got there from having tried to build the DCC into our editors. Both >with Soft and with Maya. Both were the wrong choice. > > >My team of nearly 50+ environment artists live a daily struggle because >we made that choice. > >__________________________________________________________________________ >_____ >Marc Brinkley >343 Industries >Microsoft Studios >marc.brinkley [at] microsoft.com > >-----Original Message----- >From: softimage-boun...@listproc.autodesk.com >[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind >Sent: Thursday, February 13, 2014 3:16 PM >To: softimage@listproc.autodesk.com >Subject: RE: Survey - how would you do this? > >I cannot reveal what our plans are, but I can say what we need is an >environment that has an open and deep SDK to allow us to build tools on >our terms, and not on the application's terms, so we can make our own >infrastructure without having to re-invent the wheel and reduce risk from >pipeline changes/regressions from commercial software. Allows us to >define our own primitives, data structures, and treats those data >structures as first class citizens in the API. Not have licensing which >ties the content creation product into our released product, and is very >cost effective for very large teams working across multiple sites. Can >be set up quickly and easily and is a light install, and not require >engineers to make usable or explain to artists. In concept, Fabric >engine most closely fits that paradigm, but it needs to mature before we >can give it a serious look. I would not be surprised if we develop our >own tools a la Pixar or the other mainstays of the industry. The trend >in this space is to build your creation tools into your engine so you can >take advantage of real time feedback from iteration (a la Valve). Since >we built our own engine from scratch, we have full control to implement >such features on our terms. > >Max, Maya, and Softimage don't cater to the MMORPG space very well. You >can use the products, as many have obviously demonstrated over the years, >but it's very much shaving the corners of the square peg to fit it into >the round hole. This has been a classic problem in games for a long time >as the commercial software largely cater to film/video and assume games >is a simpler version of that paradigm. In the early days of games that >was a band-aid that worked, but games have evolved a lot since then >making the current 3D software not so relevant anymore. The difference >with an MMORPG is the game has larger scope, compared to a console or >mobile game, and therefore must pull back on nifty art features and think >more big picture of the gameplay as network bandwidth is an issue, and >there is a very wide variety of hardware out there that must be accounted >for - unlike a console where a particular platform is known in advance >and likely not to change (much). Majority of our anticipated customers >still use older hardware running Windows XP, for example. We have to >make content which caters to that lowest denomination. As tools move >forward to accommodate those working on feats like Elysium, they tend to >forget and leave behind those who still need that micro-architecture edit >capability like us where pixels are still pushed one by one. > >There is a reason why many games don't have interesting artwork - the >tools get in the way. > > >Matt > > > > >-----Original Message----- >From: softimage-boun...@listproc.autodesk.com >[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric >Rousseau >Sent: Thursday, February 13, 2014 2:26 PM >To: softimage@listproc.autodesk.com >Subject: Re: Survey - how would you do this? > >On Thu, Feb 13, 2014 at 2:31 PM, Matt Lind <ml...@carbinestudios.com> >wrote: >> 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 bottom line is ICE is not tailored to our needs and is of very >>limited use/benefit. >[...] >> 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 > >So.... do you have a plan to diminish your dependency on Softimage? >what is it, what's next? > >
<<attachment: winmail.dat>>
