Just to clarify, at least as far as the roadkill plugin is concerned, it's
not the importing or exporting of the obj that's the problem; this works
just fine. It was the copying of uvs back to the original model from the
re-imported one that caused the problem. This was fixed by re-ordering the
UVs on the destination mesh after the copy operation.
I'd like to say I was smart enough to have worked out the smart solution for
roadkill but in fact thanks are due to Frederic Valluer.
André, It was me I'd be more inclined to post to the XSI Wiki. It seems more
suitable and things can go missing or become hard to find on XSIbase.
Code. Run this after copying UVs (Python):-
def FixUVs( oObj ) :
oClusters = oObj.ActivePrimitive.geometry.clusters;
# Look for our sample cluster
for i in range( oClusters.count ) :
oCls = oClusters(i)
if ( oCls.type == constants.siSampledPointCluster ):
oCluster = oCls
break
# the UVspace we're interested in will be the
# most recently added, the last in the list.
# As long as you keep your fingers crossed.
#
oUVspace =
oCluster.LocalProperties(oCluster.LocalProperties.count-1)
aSamples = []
aFixed = []
# build the lut
oFacets = oObj.ActivePrimitive.Geometry.Facets
for oFacet in oFacets :
for oSample in oFacet.Samples :
aSamples.append( oSample.Index )
aElements = oUVspace.Elements.Array
aIndices = oCluster.Elements.Array
aFixed.append( [] )
aFixed.append( [] )
aFixed.append( [] )
## there HAS to be a better way to do this, surely?
for i in range( len( aIndices ) ):
aFixed[0].append( 1 )
aFixed[1].append( 1 )
aFixed[2].append( 1 )
# and rebuild the uvs
for i in range( len( aIndices ) ):
idx = aSamples[aIndices[i]]
aFixed[0][idx] = aElements[0][i]
aFixed[1][idx] = aElements[1][i]
aFixed[2][idx] = aElements[2][i]
oUVspace.Elements.Array = aFixed
-----Original Message-----
From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On
Behalf Of André Adam
Sent: 20 August 2007 10:51
To: XSI(at)Softimage.COM
Subject: Re: OT Headus UV Layout
The problem with not being able to copy UVs back to the original mesh
properly after obj import/export is the structure of the sample
cluster,
which is the place XSI binds UVs and Vertex Colours to. The mapping
between polygon indices and sample cluster indices is subject to change
in regards to modelling operations. The wavefront object format offers
no templates for this index mapping, so the sample structure is simply
rebuild during obj import.
This is not a bad thing in the first place, but when modelling
operations have been performed on the original mesh after the texture
projection has been applied, the sample indices don't match up anymore
after wavefront export/import and a direct UV copy fails big time.
I've finished a script last week to copy UVs for these cases. It is not
as smart as the solution found in Kim's Roadkill plugin (which I
discovered 10 minutes after finishing work on my script), but it does
the job over here. Since this seems to be a common problem I'll go and
upload it to XSIBase. I'll pass a line to the list as soon as it is
available from there.
Cheers!
-André
Bernard Lebel wrote:
Well to be honest that's a problem I've seen a lot. At Action
Synthèse
we also had that with Unfold3d's predecessor, AutoUV. Some geek spent
hours trying to figure it out without significant success.
I have no clue what's going on. But from my experience, I find it a
disturbing coincidence that all these UV problems through OBJ
exchange
are raised with XSI. I think Softimage released at least few "fixes"
to their OBJ exchangers to stop those problems, but they still occur.
I was told by several non-Softimage people that this had everything
to
do with XSI. Someone else from this list explained to me that - sorry
if I got it wrong - XSI is actually trying to fix something from the
import, and because of sloppy export from other softwares it can
result in more problems.
I dream of the day where exchanging OBJ files between any software
will be pain free.
Cheers
Bernard
On 8/17/07, *Bradley Gabe * <withanar(at)stanwinston.com
<mailto:withanar(at)stanwinston.com>> wrote:
Same issue here. I think we settled on roadkill doing the
changing
due to vast evidence of point order consistency between XSI and
zbrush via obj interchange. Even so, with GATOR, point order
problems magically disappear for most things.
we've had problems here with roadkill changing vert numering, is
it maybe a
xsi thing?
jason
----- Original Message -----
From: "Bernard Lebel" <3dbernard(at)gmail.com
<mailto:3dbernard(at)gmail.com>>
To: <XSI(at)Softimage.COM <mailto:XSI(at)Softimage.COM>>
Sent: Friday, August 17, 2007 3:33 PM
Subject: Re: OT Headus UV Layout
> We used UV Layout to a certain extent here. All good, except
for one
> thing: sometimes when the mesh comes back in XSI, some
component
> numbering has changed. We had to gator the UVs back on the
original
> mesh. Generally worked pretty well.
>
>
> Bernard
>
>
>
> On 8/17/07, olivier jeannel <olivier.jeannel(at)noos.fr
<mailto:olivier.jeannel(at)noos.fr>> wrote:
>>
>> Hi people,
>>
>> I might have a bunch of meshes to UV unwrap soon. I'm
looking for the
>> best
>> decent solutions and I'm testing Roadkill and Unfold atm.
>> I've heard about Headus UV Layout but the site
www.headus.com <http://www.headus.com> and
>> www.uvlayout.com/ <http://www.uvlayout.com/> seems down.
>> I'd be happy if you pro UV guys could share some advices...
>>
>> Thanks a lot,
>>
>>
>> Olivier
---
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
