Maya importer produces 'UVs aren't per-vertex or per-polygon per-vertex, skipping' warnings for geometry exported from Maya

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Export from Maya as .abc
2. Import back

(Doesn't always happen -- I'll try to reduce geometry in such a scene then send 
along as attachment.)

Using alembic 1.0.3, both on Linux and Windows.

Original issue reported on code.google.com by tus...@gmail.com on 29 Nov 2011 at 9:46

[GoogleCodeExporter]

Original comment by miller.lucas on 9 Dec 2011 at 5:21

• Added labels: Component-Maya_Import

[GoogleCodeExporter]

I have also noticed this issue.  At first I thought it was related to the 
number of vertices because as I increased the number of verts I could replicate 
this behavior more consistently.  However, I have a test case where this 
happens on one frame sample and not another and yet the failing frame has less 
points than the one that works.

Using Alembic 1.0.5

Original comment by jonathan...@gmail.com on 3 Apr 2012 at 5:15

[GoogleCodeExporter]

Also, I can confirm the UVs for this mesh are not broken on export by viewing 
the resulting ABC in Katana, seems to be an issue with the Maya AbcImport

Original comment by jonathan...@gmail.com on 3 Apr 2012 at 5:29

[GoogleCodeExporter]

Do you have a simple example that you can share?

Original comment by miller.lucas on 3 Apr 2012 at 4:47

[GoogleCodeExporter]

Not right now, but we run into this from time to time. I'll send an example
next time we bump into it.

imre

Original comment by tus...@gmail.com on 3 Apr 2012 at 7:14

[GoogleCodeExporter]

I found a case where this is happening and it's a bug in AbcExport.

In Maya some of the faces may not have UVs, while AbcExport is assuming that it 
has face varying UVs for ALL the faces.

Jonathan, when you say you are viewing the ABC in Katana, are you at the UVs in 
the UV viewer, or are you looking at the SceneGraph Attr?

Original comment by miller.lucas on 3 Apr 2012 at 9:51

• Changed state: Accepted
• Added labels: Component-Maya_Export
• Removed labels: Component-Maya_Import

[GoogleCodeExporter]

I'm looking at the UVs in the UV Viewer.  My data isn't coming from the Maya 
AbcExport, it's actually coming from Houdini12 so I really think it's a problem 
with AbcImport.  

I modified AbcImport to ignore the check it's doing when it prints this message 
and instead use the data as per-vertex UV data and the result seems ok in the 
Maya UV editor and in renders.  As a diagnostic I printed out the indexPtr 
size() and the numFaceVertices and numVertices and noticed that numVertices was 
always less than the indexPtr size by 7 (I don't have it in front of me but I 
think that's the difference) so perhaps indexPtr size isn't accurate?  Is that 
the size in allocated memory?

Original comment by jonathan...@gmail.com on 3 Apr 2012 at 10:29

[GoogleCodeExporter]

Having more UVs than you have face varying vertices for could be problematic, 
especially if the extra data isn't packed at the end.

Original comment by miller.lucas on 3 Apr 2012 at 10:52

[GoogleCodeExporter]

Katana's UV Viewer is more tolerant of mismatches in expected 
"geometry.arbitrary" attributes (the destination of AbcGeom::GeomParam data) 
than the rest of the system is. My guess is that it'll log a warning and omit 
the data when you write it out to a renderer. In my opinion, that's a problem 
with the data.

Original comment by steve.lavietes@gmail.com on 3 Apr 2012 at 11:05

[GoogleCodeExporter]

Hmmm  will the Attribute viewer in Katana be accurate to what data is in the 
abc or will that throw out the mismatched data?  Because for both good and bad 
frames of geometry I always see the proper relationship in size of 1:2 verts:st 
values.

Original comment by jonathan...@gmail.com on 3 Apr 2012 at 11:38

[GoogleCodeExporter]

The Attributes tab in Katana will show you the data as present (valid or not). 
I'm probably jumping into this thread without enough information. If you've got 
some representative data you can share, I'll take a look.

[Restated and only possibly relevant truths:
1) Katana's Alembic_In doesn't do validation of GeomParam footprint on read.
2) The Attributes you see in that tab will reflect the data as advertised in 
the alembic archive.
3) Katana's render output modules validate the footprint of 
"geometry.arbitrary" attributes against the mesh and will exclude anything that 
doesn't match exactly.
4)Katana's UV Viewer tab is tolerant of mismatches if it's more data rather 
than less.]

Original comment by steve.lavietes@gmail.com on 3 Apr 2012 at 11:53

[GoogleCodeExporter]

The AbcExport fix is here:

http://code.google.com/r/millerlucas-dev/source/detail?r=3678ea403483033363f3077
874525f4cfde127c8

Original comment by miller.lucas on 4 Apr 2012 at 12:16

• Changed state: PleaseVerify

[GoogleCodeExporter]

Hi Steve.  Yeah, I was pretty sure that was the behavior for Alembic_In so I 
was confused when I saw what I think is a proper number of st values compared 
to verts in Katana

Lucas, I'm attaching an example abc that I believe exhibits the problem.  If 
you look at frame 6 you should see the problem crop up, but inspecting the same 
abc in Katana there is a valid number of uv's per vert. (8876/4438)

Thanks

Original comment by jonathan...@gmail.com on 5 Apr 2012 at 3:17

Attachments:

• uvTest.abc

[GoogleCodeExporter]

At frame 6 when Maya is setting the UVs it thinks that there are only 4431 face 
varying vertices.

Maya may be dropping some of these face varying vertices if they are degenerate.

Original comment by miller.lucas on 5 Apr 2012 at 5:13

[GoogleCodeExporter]

Sorry for the delay in coming back to you.  But yes, that seemed to be the 
issue.  I cleaned up the geometry and got the expected result and the correct 
number of vertices into Maya.  Thanks much

Original comment by jonathan...@gmail.com on 17 Apr 2012 at 10:30

[GoogleCodeExporter]

The fix seems to work for us at Prime Focus. Thanks

Original comment by arcgr...@gmail.com on 5 Jul 2012 at 11:09

[GoogleCodeExporter]

Fixed in the new released 1.1

Original comment by miller.lucas on 2 Aug 2012 at 11:11

• Changed state: Verified