Address uv/st vertical origin - maya vs prman - need to decide on approach and document

[GoogleCodeExporter]

Hi all,

The current AbcExport and AbcImport Maya plugins export/import v as "1 - v". In 
other words the UVs are flipped vertically around 0.5 in Alembic files when 
using Maya, although they round-trip fine into Maya because it's happening in 
both plugins. The flipping becomes apparent when you start moving data from 
Maya into another package that expects unmodified UVs, or vice-versa. As far as 
I understand, the flipping is related specifically to prman UV/st conventions 
since in prman "0" in v is at the top of the texture. I don't know of any other 
3d app that inherently creates or expects UVs in that manner although I'd 
certainly be curious to hear if there are any. In any case, not only will this 
inversion cause a lot of confusion amongst users of Alembic, but it is 
especially troublesome even in the prman case when dealing with 
vertically-stacked UV tiles as is becoming common convention in packages such 
as Mudbox and Mari.

I'd like to request that this inversion either be removed or turned into an 
option that defaults off as soon as possible, ideally the 1.0.2 release. 
Personally I'd vote for no option at all, since an option would suggest that 
it's acceptable to write Alembic file with inverted UVs. If that starts 
happening then the reader of an Alembic file will never know when to expect a 
given orientation. There could be additional metadata about the orientation, 
but IMO that seems like a bunch of tail chasing for something that is very easy 
to handle directly in the renderer (in the case of prman) or any other app or 
renderer that happens to want inverted UVs. I think it's fair for those apps to 
treat themselves as the exception and consider 0,0 as lower left to be "network 
order" so to speak.

I realize that the Maya plugins that ship with Alembic are technically just 
reference implementations, but we all know that most people will use them 
unmodified or with little modification.

So ... what say you, Alembic gods? :)

(I believe that Steve and probably
at least a few other developers already know about this request, but
just wanted to get it out there on the list too.)

-Jonathan

The uv >1.0 mudbox/mari style is a compelling argument for allowing
unmodified uv data out of maya.

The arguments against it as the only option include:
1) It partially invalidates existing data written with 1.0/1.0.1
unless we go with "support both with metadata" or specifically
recognize the existing version metadata. Dependent on the amount of
production data currently in use, this might not be a big deal.
2) We've generally matched RenderMan conventions for AbcGeom
definitions -- including the v ordering for NuPatch.

I believe the v flip made sense (or was never noted as issue at all)
to both original contributing studios because our shader conventions
were originally based on RenderMan (and NURBS).

That said, I'd rather pick one way than two.

-stevel

Original issue reported on code.google.com by ble...@gmail.com on 21 Sep 2011 at 12:18

[GoogleCodeExporter]

Per Francois:

To clarify: we consider that (0,0) corresponding to the lower-left
corner of a texture is the "standard" way UV values for polymeshes
should be expressed in Alembic files. This will be made clear in the
documentation as well, and all readers should be able to safely make
that assumption.

The changes have already been made to Maya, and an option was added to prman.

Original comment by miller.lucas on 6 Oct 2011 at 1:36

• Changed state: PleaseVerify

[GoogleCodeExporter]

Original comment by miller.lucas on 15 Oct 2011 at 12:29

• Changed state: Verified