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
>>>
>>>
>>
>

Reply via email to