really nice, first jump into thread Luc-Eric and question is like oh ditch SI what do you wanna use next (*cough* Maya *cough*) But as someone else mentioned... there is old saying... "Every gypsy brags about his horse" not sure how it sounds in English but should get across...
On Fri, Feb 14, 2014 at 4:42 AM, Sebastien Sterling < sebastien.sterl...@gmail.com> wrote: > You can do it in cinema4D ! with the asteroid belt deformer, its right > next to the popcorn deformer and the flap your arms like a bird deformer ! > > > On 14 February 2014 03:49, Guillaume Laforge < > guillaume.laforge...@gmail.com> wrote: > >> Btw, would love to see how to build such asteroid belt in Modo ;) >> >> >> On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind <ml...@carbinestudios.com>wrote: >> >>> Below: >>> >>> >>> -----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 5:26 PM >>> To: softimage@listproc.autodesk.com >>> Subject: Re: Survey - how would you do this? >>> >>> On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind <ml...@carbinestudios.com> >>> wrote: >>> >>> Allows us to define our own primitives, data structures, and >>> treats those data structures as first class citizens in the API. >>> >>> >yeah, with only experience with Softimage's SDK one might think that's >>> >something special. But it's a common thing to do with Maya. >>> >>> [Matt] >>> I was paraphrasing a comment made by one of our engineers. Although I >>> have run into the issue myself more than once. >>> >>> >>> >sure, Fabric requires no work at all to make it usable for artist.. >>> >it's magical. (Does not really answer the questions about your uv >>> editing, retopology, and reduction problems, though) >>> >>> [Matt] >>> Never claimed it did. Only said it's closer in paradigm to what we >>> need, and it still needs to mature for us to give it a serious look. What >>> it does offer is the ability to take control of the situation and develop >>> what we need without re-inventing the wheel from scratch every time. >>> >>> >>> >>> >About authoring stuff that would not be obviously better authored >>> directly in the game engine: >>> >there are a lot of custom authoring tools out there where the tool is >>> actually the Maya running in library mode. >>> >You have no way of knowing this if all you see is a video of it on the >>> >web, the maya UI is not there at all, >>> >it looks like it was a custom tool written from scratch. Maya in >>> library mode takes no licenses. All of this is simply >>> > inconceivable from a Softimage point of view, and it was a factor in >>> getting kicked out of the bigger places. >>> >>> [Matt] >>> The point of editing in the game engine is changes to the engine are >>> immediately available to the artist creating content. What they see is >>> what they get, and with real time feedback. A large portion of any >>> artists' day is spent waiting for files to export from the DCC and collate >>> into the engine. In some cases many minutes per export/collate. That is >>> not iteration friendly and problematic for engineers as they have another >>> set of code to maintain and keep in sync. Having a Maya backend in >>> library mode doesn't solve this problem. >>> >>> One problem we continually face is the ability to see an asset in the >>> context of the game with proper lighting, fx, and other game specific data >>> in the authoring stages. An artist needs to see how a reflective surface >>> will look in a particular zone of a world. You cannot easily replicate >>> that in a commercial DCC. Likewise, it's not simple to recreate the DCC's >>> editing power for creating raw assets. The process of moving towards the >>> engine has to start somewhere. Right now many games have level editors, >>> texture paging editors, and so on. Those tools need to come together and >>> start incorporating raw 3D data into the mix where it can be more easily >>> edited. That's the next generation of tools. Most engines already define >>> how animation works and exposing transform manipulators and FCurve editors >>> wouldn't be too much of a stretch beyond what's already in the system (in >>> comparison to doing the same for modeling, texturing, etc...). The DCC >>> shouldn't be dismissed, but the commercial vendors have to stop working >>> like a cable company and forcing customers to choose off their menus to get >>> any signal at all. >>> >>> >There are other stuff at Autodesk that is moving away from putting >>> everything directly in the DCC when >>> >it makes sense. For example, shaderfx is a realtime shader editor that >>> runs also out of Maya. >>> >The Bifrost and xgen engines are also separate from Maya. >>> >>> [Matt] >>> Does not apply to our situation. Make sense for small to mid sized >>> studios that work with commercial engines where they're limited in what >>> they can modify. Commercial tools tend to develop towards a spec, and is >>> only useful for consumers of the spec. Once you move out of the spec, the >>> tool is less useful because it cannot always accommodate. We built our >>> engine from scratch and in some cases don't follow the same standards as >>> the rest of the industry because we needed to do certain things more >>> efficiently whether it be how we pack data or crunch the numbers. >>> >>> >>> >>> Matt >>> >>> >> >
