the guy just didn't know that the XSI exporter needs an image attached
or it will ignore the UVs on export.
wazzup with you and emailing me through a list hosted on the other side
of the world when you're some 5 desks away from me anyway? : p
P.S.
I'm still somewhat inclined to blame part of the problem on affogato.
Jordi, if you're reading, did Ian's RIB exporter have problems with UVs
and the C++ SDK reordering them into buggerdom?
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.
***********************************
* Raffaele Fragapane *
* GTD (at) Rising Sun Pictures *
* "Remember, TD is for TopDog" *
***********************************
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
