(sneaks in)
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...
BTW if you need to constraint to a point on a mesh in Maya, you can
use clusters without the mesh needing to have UVs.
http://www.terencejacobson.com/hyperRealMeshParent.mel
That script is an example, really nice for getting things like the
'doritos' effect in Maya without doing too much under-the-hood stuff.
However if you do not require the clusters to deform in parallel with
other deformers (skinClusters, blendshapes what have you) then the
relative attribute in the cluster should allow for most types of
object-to-point-on-mesh constraints. And yes, the default point-to-poly
constraint is rubbish. :P
As far as transferrring UVs go...did the Transfer Attributes tool not
work out? I know it's not really as flexible as GATOR, but usually for
99% of cases where topology is identical it should work out fine.
However I use Diamant Tools regularly when I need to project details/UVs
from mesh to mesh where the topology isn't the same for whatever reason.
Hopefully that helps out if you need to tackle these specific problems
again!
(sneaks out)
Yours sincerely,
Siew Yi Liang
On 2/13/2014 8:15 PM, Emilio Hernandez 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] <mailto:[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] <mailto:[email protected]>> wrote:
Below:
-----Original Message-----
From: [email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>] On Behalf Of
Luc-Eric Rousseau
Sent: Thursday, February 13, 2014 5:26 PM
To: [email protected]
<mailto:[email protected]>
Subject: Re: Survey - how would you do this?
On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind
<[email protected] <mailto:[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
