Hi André
Between XSI and which other package?
And have you tried this with an operator on the stack that modifies the
geometry? Or tried freezing the operator stack before the export?
I'm glad that you have got it working, but, in all honesty, it has never
worked for us exporting to Maya, Wings, Flesh or any other package we
have tried and then re-importing into xsi. The UV's become totally
useless - looking like the UVs were randomly rearranged. If it makes a
difference, we are using Linux, not Windows. Again, in some cases we
got it working with .obj format, but there were some special cases where
this did not work either. The only concrete way I've been able to get
UVs out and back in is to save them spatially and remap them spatially
after the geometry is re-imported.
cheers,
Luke
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
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
