Has anyone tried Collada?
> -----Original Message-----
> From: owner-xsi(at)Softimage.COM
> [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Matthias Worch
> Sent: 23 August 2005 02:30
> To: Luke
> Cc: XSI(at)Softimage.COM
> Subject: Re: .xsi format trashes UVs
>
> I got it working well now, going between Windows Maya and XSI.
> Materials are preserved as well as grouping. The setup is a
> bit of a mess inside XSI because everything is in clusters,
> but it works. The viewport doesn't display the textures
> correctly either, but it renders fine.
>
> I'm making sure that each object has an image file attached
> to it and that I export to version 3.0, which is what the
> Maya plugins supports (XSI defaults to 3.6 when you export,
> and that messes stuff up).
> Only materials I haven't gotten to work correctly are shaders
> with transparency settings. The UVs still don't transfer correctly.
>
> --
> Matthias Worch
> http://www.langsuyar.com
>
> L> Hi André
>
> L> Between XSI and which other package?
>
> L> And have you tried this with an operator on the stack that
> modifies
> L> the geometry? Or tried freezing the operator stack before
> the export?
>
> L> I'm glad that you have got it working, but, in all honesty, it has
> L> never worked for us exporting to Maya, Wings, Flesh or any other
> L> package we have tried and then re-importing into xsi. The UV's
> L> become totally useless - looking like the UVs were randomly
> L> rearranged. If it makes a difference, we are using Linux, not
> L> Windows. Again, in some cases we got it working with .obj format,
> L> but there were some special cases where this did not work either.
> L> The only concrete way I've been able to get UVs out and
> back in is to
> L> save them spatially and remap them spatially after the
> geometry is re-imported.
>
> L> cheers,
>
> L> Luke
>
> L> André Adam wrote:
>
> >> ??? Don't know about your special SDK issue, but dotXSI for sure
> >> stores UV data correctly. We're using it since Soft|3d as
> our primary
> >> export format and never ran into any problems...
> >>
> >> -André
> >>
> >> Luke wrote:
> >>
> >>> Hi Raffaele ;-),
> >>>
> >>> I'll walk to your desk and chat to you about this in a
> minute ( now
> >>> you are in the same room! ), but it is worth posting so everyone
> >>> else knows about it.
> >>>
> >>> XSI incorrectly stores UV data within its SDK ( based on the
> >>> examples from the SDK on how to access it ) and as a
> result, there
> >>> are a LOT of issues saving and storing UV data between it
> and other packages.
> >>>
> >>> We have been running into a lot of issues lately with
> this and it is
> >>> especially apparent when you use UV's in the C-SDK. From
> Python the
> >>> problem is easier to solve.
> >>>
> >>> Only way that we have ever been able to get this working is to
> >>> export as a .obj and import using .obj
> >>>
> >>> From what I can tell, any manipulation of a mesh fries the sample
> >>> indices in such a way that they are, from that point forward,
> >>> useless from the SDK ( the indices get scrampled and the
> >>> elementArray that "should" unscramble them isn't correct
> ). Since
> >>> the dotXSI format must have been written using the C-SDK ( makes
> >>> sense for speed.... ), it also suffers from this problem.
> >>>
> >>> The only reason I think that .obj handles itself properly is that
> >>> when it exports the mesh it traverses it in the same
> order that the
> >>> SDK examples indicate it should, which means the UV's are written
> >>> out as you would expect if you were accessing them upon import or
> >>> manipulation from the SDK.
> >>>
> >>> It's a big pain in the arse but it can be worked around.
> Once I get
> >>> some time myself and Moritz will send XSI a repro for the
> problem,
> >>> since it is not the easiest thing to demonstrate.
> >>>
> >>> Good luck.
> >>>
> >>> Luke
> >>>
> >>> P.S. If you are up for a bit of a coding excercise, another
> >>> workable solution is to write a nearest neightbour comparison
> >>> between two meshes, one with the OK UVs before the export to maya
> >>> and one with the fried UVs. You can find the same points
> in space
> >>> and then copy over the UV data deviod of issues. It is a simple
> >>> thing to code that should take you about an hour or two.
> >>>
> >>> ozu's mailbot wrote:
> >>>
> >>>> dotXSI will only keep the UVs if there is an image map
> attached to it.
> >>>>
> >>>> oO
> >>>>
> >>>> Raffaele Fragapane wrote:
> >>>>
> >>>>> it would help to know how you're transfering data.
> >>>>> anyway... I've transfered heaps of stuff between maya
> and XSI in
> >>>>> the past, and when it's only geometry and UVs you want to move
> >>>>> across OBJ will do the job perfectly.
> >>>>>
> >>>>> Matthias Worch wrote:
> >>>>>
> >>>>>> I'm having the hardest time trying to get a UVed model
> from XSI
> >>>>>> to Maya 6, the UVs get lost during transfer no matter what
> >>>>>> options I use (the model doesn't have any UVs once
> it's imported
> >>>>>> into Maya). Has anybody experienced this? If so, how
> did you fix it?
> >>>>>>
> >>>>>> --
> >>>>>> Matthias Worch
> >>>>>> http://www.langsuyar.com
> >>>>>>
> >>>>>> ---
> >>>>>> Unsubscribe? Mail Majordomo(at)Softimage.COM with the
> following text
> >>>>>> in body:
> >>>>>> unsubscribe xsi
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>> ---
> >>>> Unsubscribe? Mail Majordomo(at)Softimage.COM with the
> following text
> >>>> in
> >>>> body:
> >>>> unsubscribe xsi
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> ---
> >> Unsubscribe? Mail Majordomo(at)Softimage.COM with the
> following text in
> >> body:
> >> unsubscribe xsi
>
>
>
>
> L> ---
> L> Unsubscribe? Mail Majordomo(at)Softimage.COM with the
> following text in body:
> L> unsubscribe xsi
>
>
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following
> text in body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
