Btw, would love to see how to build such asteroid belt in Modo ;)
On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind <[email protected]> wrote: > Below: > > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Luc-Eric Rousseau > Sent: Thursday, February 13, 2014 5:26 PM > To: [email protected] > Subject: Re: Survey - how would you do this? > > On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind <[email protected]> > 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 > >
