Take me in and I will distract the secretary!
2014-02-13 22:23 GMT-06:00 Sebastien Sterling <[email protected]> : > Guillaume next time you are invited round AD headquarters for an event say > you are going to the toilette and steal the deeds back for softimage. > > THE SPICE MUST FLOW ! > > > On 14 February 2014 05:15, Emilio Hernandez <[email protected]> wrote: > >> Sorry to jump into this masters discution, but don't we have PyQT in >> Softimage also? >> >> And now that Luc-Eric jumped in... >> >> Ok, Maya is more customizable, and better for Devs to integrate it into a >> pipeline and bla, bla, bla. Because out of the box sorry but... pffff.... >> >> I am a novel in Maya and I am using it because I need to, not because I >> am convinced of using it. And the more I use it, the more I love Softimage. >> >> I couldn't find a way to transfer a simple UV from one mesh to another. >> So I went and dug into Creative Crash to find a script... >> >> A script for this, a script for that. The only thing I want to thank >> Maya is that I started scripting again... Thank god I have two monitors to >> have the script editor open with I don't know how many tabs. Or why not. >> I can have a lot of buttons clogging more my workspace with nice Maya >> icons. I don't have time to start getting "creative" to draw an icon for >> each additional script I write to do a simple task... >> >> And speaking of constrains. To constrain to a point on a mesh in Maya, >> you need to have UV's!!!!! and watch out. If you constrain to a point >> that in the UV is in two different coordinates... ciao... >> >> So yes maybe when you have an army of Devs scripting and scripting. You >> can have awsome custom tools... >> >> But when you have a small studio or you are freelance, for me Maya is "no >> go". >> >> So instead of spreading the word on how "good is Maya" compared to >> "Softimage" to try to convince us to switch platforms, because Maya is >> "more customizable". We want a descent upgrade of Softimage. Not only a >> "super camera switcher". >> >> What is the fear of Autodesk? >> >> That if you guys start making real improvements on Softimage the Maya >> "industry standard" farce will fall? >> >> Sorry but I am really pissed off of how Autodesk is handling Softimage. >> The best thing you can do is put it on sale so that people who really >> cares, will take Softimage to the next level instead of burying it in Asia. >> >> But this will hardly happen. Softimage in some other hands will be a >> very strong contender to Maya >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 2014-02-13 20:49 GMT-06:00 Guillaume Laforge < >> [email protected]>: >> >> 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 >>>> >>>> >>> >> >
