|
Hi Luke,
not transferring the data to another 3d package but into our game
engine. It doesn't matter if I freeze things or not, the current state
of a given object always arrives correctly inside the game, so I'd call
dotXSI pretty robust. If you lose the UV info after moving the data to a
different package and back, it might be related to the dotXSI
implementation of that package?
Cheers!
-André
Luke wrote:
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
|
