Re: xsi to maya

[Alastair <hearsum(at)glassworks.co.uk>]

I've got this to work but I think in a more simple way than it must have seemed I meant in my original mail.  I was only interested in a one way plotted scenario from xsi to maya. In my xsi_biped based ri g I removed all the neutral poses in the rig and the enveloped animated character went across just fine using crosswalk.
Thanks everyone for their advice


Alastair

Alastair Hearsum
Head of 3D



33/34 Great Pulteney Street
London W1F 9NP
T:+44 (0)20 74341182
F:+44 (0)20 74341183
http://www.glassworks.co.uk
http://www.glassworksamsterdam.nl

(Company registered in England with number 04759979. Registered office 7-9 Swallow Street, London, W1B 4DT. VAT registration number: 867290000)

DISCLAIMER: This e-mail and attachments are strictly privileged, private and confidential and are intended solely for the stated recipient(s). Any views or opinions presented are solely those of the author and do not necessarily represent those of the Company. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If this transmission is received in error please kindly return it to the sender and delete this message from your system.

Andy Jones wrote:

A good thing to be aware of if you're doing conversions between packages
is that you can use .fbx to import just animation on top of a rig you've
already brought over.  This opens up the possibility to do manual fixes
to a rig where like 90% of it comes over fine, and it would take longer
to make a tool to get the remaining 10% every time than to just fix it
once by hand and import just animation from then on.  You just have to
make sure your manipulators have the same transformation spaces, which
is generally not too difficult to achieve. 

- Andy


On 1/4/08, raffaele(at)turbolinea.com <mailto:raffaele(at)turbolinea.com>  <
raffaele(at)turbolinea.com <mailto:raffaele(at)turbolinea.com>  > wrote:

Hi Guy, thanx for the explanation on these "conditioner". 
>From what I had read, and when I attended the collada forum a siggraph a
few years back, I was under the impression that the main goal was to
provide a uniform way (at least initially simple) to provide an easy
tool, save  (rigged) assets to be used in multiple packages. 
But this hasn't happen yet...
So I spent about a month hacking xml files and building my "replacement"
tokens so I could use XSI (as my content creation package) and Maya
(because the plugin I needed wason that platform. 
I was also very carefull to keep my modelling/texturing/uv/rig very
simple and straight forward ( for the conversion). And as you said some
of the attributes where in "application specific" attributes, not the
common collada xml definitions. 

I would just like to hope, at some point someone a the chronos group, or
whomever is in charge of this endeavour looks at the pratical every day
TD task of usin! g Collada in production workflow. Or alternatively,
someone at SoftImage (because I don't think Autodesk would), offer text
document/production workflow list on how to use XSI (for content
creation) -> Collada -> Maya output. 

Until then I will keep hacking xml files.

Cheers,
THX.
RSM




-------- Original Message --------
Subject: Re: xsi to maya

From: Guy Rabiller < guy.rabiller(at)tek2shoot.com
<mailto:guy.rabiller(at)tek2shoot.com> >
Date: Fri, January 04, 2008 8:51 am
To: XSI(at)Softimage.COM <mailto:XSI(at)Softimage.COM> 


  

../.. Did I mention Collada, doesn't work between XSI and Maya ../..
../.. BAD, VERY BAD... edit the collada xml file to fix it. I 
    

automated this
  

, as I found collada Maya format and XSI collada ARE NOT COMPATIBLE
    

../..

Understand what COLLADA is really supposed to address: COLLADA is meant 
to be a digital asset exchange standard, not a cross-application 
'converter'.

I would still recommand the COLLADA pathway though, because the trick is

to provide 'Conditioners' to convert custom items to the target 
application at load / save time. This allows to not worry about the file

format in itself, but on what to convert and how to convert it from/for 
a specific application.

Take a look at the last COLLADA summit paper to better understand the 
process ( 
http://www.khronos.org/developers/library/2007_collada_summit/COLLADA-Su
mmit_(500KB).pdf
<http://www.khronos.org/developers/library/2007_collada_summit/COLLADA-S
ummit_%28500KB%29.pdf>  
).

You even have a Refinery available with plugin support on sourceforge ( 
http://sourceforge.net/projects/colladarefinery
<http://sourceforge.net/projects/colladarefinery>  ).

The logical path would be to do what you did ( editing the XML file ) 
through 'Conditioners' ( 
http://collada.org/mediawiki/index.php/Category:COLLADA_conditioners
<http://collada.org/mediawiki/index.php/Category:COLLADA_conditioners>
). 
COLLADA is not meant to provide conversion, and vendors who sell COLLADA

implementations and API try to embed various conditioners to answer the 
needs, but its a dangerous path if you don't have access to these 
conditioners, if you can't edit them or plug yours.

Idealy, dcc tools ( 3d applications ) should provide a way for us to 
plug custom conditioners, not trying to convert their items for every 
other 3d applications in arbitrary ways.

When you say 'Maya format and XSI collada are not compatible', of course

they are not, because both vendors use custom items not (yet?) 
'standardised' by the COLLADA standard or not directly compatible 
between the applications ( so ultimately a conversion is needed where 
applicable ), but they are saved in a standard file format with a 
standard metastructure, and that's the important point for now. 
Standardised items though, should be loaded correctly. If you 
have/create/buy custom Conditioners, then you'll be able to correctly 
load /save custom items.

The point is to have a standard asset file format exchange, at least. 
Once you have that, you can concentrate on the conversion part.

For example, you could export from XSI to COLLADA to a file '*.xsi.dae',

then use the Refinery with custom Conditioner plugins to convert some 
items to Maya and save the result to a new file '*.maya.dae'. Or you 
could directly integrate those converted elements in the same file and 
save the result as a 'unversal' '*.col' so you would have a file that 
is, this time, fully compatible between the two applications.

Ultimately, each application would convert those item at load time 
through custom conditioners hosted by the application, rather than to 
embed custom converted datas for every applications ( unless too 
application specific to be converted or both are needed by a third 
application/custom tool ).

For this to work, dcc tools companies should stop trying to provide 
infinite variations of importers/exporters/convertors/whatelse.., and 
start to fully support this COLLADA industry standard, and most 
importantly, provide openess and support for *Conditioners*.