Just found this thread tonight. I must say I liked your idea Matt :) Manny and Christian demos are just great. It is funny that most of us can't think outside ICE now. As soon as something a little bit complex appear, we jump in this node graph like zombies.
Constraints (no pun intended) are the key for creativity ! Cheers, Guillaume PS: I don't want to imagine how slow it would be to drive 1000 spheres kinematics using ICE :P On Thu, Feb 13, 2014 at 7:11 PM, Graham Bell <graham.b...@autodesk.com>wrote: > > 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? > > > > > >
