LOL Cinema4D + Asteroid sounds so Amiga (the first platform of this 3D app).
On Thu, Feb 13, 2014 at 10:42 PM, 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 >>> >>> >> >
