Multiple UV sets per object

[Ben Houston]

Hi all,

Just wanted to pass along that we are getting a fair number of
questions regarding Alembic's current non-support for multiple UV sets
per object. My understanding is that it isn't yet supported. Is
support planned to arrive at some point?

It think that multiple UV sets are relatively widely used in high end
visual effect shops (and supported by Maya, 3DS Max and Softimage) so
it may be worthwhile to add support for this in the future.

--
Best regards,
Ben Houston
CTO, Exocortex Technologies, Inc.
http://www.exocortex.com

[Steve LaVietes]

Alembic does support multiple UV sets per object via arbitrary
geometry parameters.

An IV2fGeomParam with a scope of "varying" or "facevarying" within
arbGeomParams is equivalent in type to the result of the primary
getUVsParam() call on the schema. This is similar in philosophy to
adding multiple uv sets as primvars in RenderMan.

What might be missing are application-specific
conventions/implementations to map this back to non-primary uv
representations. I believe there was a previous thread for how this
would be handled in the maya reference implementation (similar to the
handling of color sets).

-stevel

> --
> You received this message because you are subscribed to the Google
> Groups "alembic-discussion" group.
> To post to this group, send email to alembic-d...@googlegroups.com
> To unsubscribe from this group, send email to
> alembic-discuss...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/alembic-discussion?hl=en
>
> For RSS or Atom feeds related to Alembic, see:
>
> http://groups.google.com/group/alembic-dev/feeds
>
> http://groups.google.com/group/alembic-discussion/feeds

[Steven Shapiro]

Hey Steve, that was an email thread. I forwarded it to you so you can
post from it what you'd like.

[Steve LaVietes]

Ah, thanks Steven. Here's what I wrote previously in an email thread:

On 01/20/2012 05:46 PM, Steve LaVietes wrote:

A GeomParam is self-describing. The built-in uv definition is a V2fGeomParam. Additional uv information can be defined as the same type (with a scope of varying, vertex or facevarying) within the arbGeomParams group.

Were there to be multiple built-in (i.e. non-arbitrary) uv definitions, it raises a questions like, "how many should there be?" If the answer to that is "as many as someone wants," the only distinction between those and an equivalently typed GeomParam within arbGeomParams is where they live within the alembic property hierarchy.

Since there is no distinction in most applications (houdini, RenderMan, arnold, katana) between a secondary uv and a self-describing geometry attribute/parameter with an equivalent type, I think your question is more specifically:

"Why is there not a mapping between things within arbGeomParams which match the datatype of a uv set to Maya's uv sets?"

A similar question was raised about per-vertex colors coming in and out of Maya. Since a GeomParam of type C3f and C4f is recognizable as a color -- and can advertise itself as being per-vertex -- the Maya-specific question in that case became, "Which one of these should I use as the color set since only one can be it in Maya?" For that case, we introduced Maya-specific metadata conventions (as proposed by the community) that the importer/exporter could use as additional hints for where to direct the data.

But, uv sets in Maya aren't subject to the same, "there can only be one active" limitation. So, the Maya importer/exporter could do the same thing with anything within arbGeomParams which matched the expected data type. Or if that's not specific enough, we could introduce another metadata convention to indicate, "I really want this thing which matches the expected datatype of a uv set to be used as a uv set."

In any case, I don't feel it's an AbcGeom level issue.

-stevel

[SteveGalle]

Hi. 

I'm digging up this discussion because I have just finished updating the AbcExport and AbcImport plugins that ship with Maya to handle multiple UV sets.

I followed your advice and stored the additional UV data as V2fGeomParams under the arbGeomParam group. The parameters bear the name of the uvset they describe, and each is tagged with a metadata element called 'isCurrentUVSet', which is set to 1 for the uv set that is current at export time, and 0 for all others. This serves both to specify the parameter as a uvset, and to indicate which of the uvsets should be set to current during the import process. This allows for the names, indices, and 'current' status of the uv sets on the imported data to all align with the original source geometry. Files exported without additional UVset data import as they did before, and importing a new file with the old importer results in geometry with only the uvset that was current at export time available, as would be expected. 

We (DD) are (after a little cleanup) happy to contribute the new versions of AbcImport and AbcExport back to the community, but before we do that is it worth another round of discussion regarding making support for multiple UV sets an official feature of the AbcGeom schema? Acknowledging the points you raise below, my concerns moving forward with a solution outside of the schema are twofold. 

First and foremost is the effect leaving this functionality out of the schema will have on standardization. ExoCortex already support multiple UV sets in Crate their own way, now we have an implementation here, and who knows how many others are working on tackling or have already tackled the problem with their own solutions. If I'm Chaos Group deciding how to support multiple UVs for geometry caches at render time, or The Foundry looking at options for Nuke or Katana, who's solution do I choose? Less critically, it's also a shame to have to deal with writing and (to a greater extent) extracting multiple sets of UV data via two different code paths. It's not difficult, but it definitely leads to the question 'why is this really necessary?' With these points in mind, Is formalizing support within the geometry schema something you'd be open to reconsidering, or is it just going to come down to community cooperation to make sure we have a consistent cache format?

Ben, if you're still watching this thread I contacted Helge before I started on our solution to find out if ExoCortex were willing to share the schema you used in Crate, but I never heard back. Without worrying about implementation details, if multiple UV set descriptions will indeed remain outside of the standard schema it would be best for the community if we could at least synchronize on the schema. I have not pushed our solution into production or back to Autodesk yet so if it makes sense to do so there is still an opportunity to match what you guys came up with.

Thanks,

Steve

[Steve LaVietes]

I think this is a case in which we'd want to standardize on metadata conventions (and possibly include utility functions) rather than try to move this to the schema level (in the AbcGeom code sense). The idea of "currentUVSet" (other than the default uvs as described by the non-arbitrary GeomParam returned from .getUVS) doesn't feel general enough to belong there.

I definitely agree that we want to standardize how this is described and interpreted for applications which do participate. I'd like to take a look at how ExoCortex is handling this between applications and then get back to you.

-stevel

--
 
 

[Ben Houston]

Hi Steve,

Right now our structure is:

.uvSetNames (string array property) - stores the names of the UV sets.
May not be very descriptive if it is coming from 3DS Max where UV
sets are not named (thus we use the form "Channel_##" where ## is the
map channel id.)

.uv - the default UV channel.
.uv1 - the next UV channel.
.uv2 - the follow UV channel.
...
.uv10 - another UV channel.

We rely on the contents of the uvSetNames to do the naming thus the
.uv# is expected to be sequential with no gaps.

This does unfortunately extend the PolyMesh directly. In a future
version we can move it to Arg Geom.

Best regards,
-ben

> --

[Ben Houston]

Hi SteveGalle.

> Ben, if you're still watching this thread I contacted Helge before I started on our solution to find out if ExoCortex
> were willing to share the schema you used in Crate, but I never heard back. Without worrying about
> implementation details, if multiple UV set descriptions will indeed remain outside of the standard schema it
> would be best for the community if we could at least synchronize on the schema. I have not pushed our solution
> into production or back to Autodesk yet so if it makes sense to do so there is still an opportunity to match what
> you guys came up with.

It is likely best to contact me regarding schemas on Exocortex Crate /
Alembic. I am always happen to share things. :-) Unfortunately,
Helge didn't forward along your inquiry so I was unaware of it. Argh.

I haven't seen your implementation but I do suggest storing a list of
uv names as an string array property.

We can add multiple code paths to our plugin to handle your location
and our location if you prefer to keep it in arbGeom, and we can
update accordingly to match yours.

I guess the weird thing is that one uv is outside of the arbGeom but
the others are inside arbGeom, which is a bit unfortunate.

Best regards,
-ben

[Steve LaVietes]

Would it be feasible to store the uvset name/order as part of the individual GeomParam's metadata instead of as a separate array?

In any case, we'd definitely want the additional uvs themselves to be within arbGeomParams so that they'd be picked up by applications which don't care whether they're uvs or not (like prman).

-stevel

> --
>
>

[Lucas Miller]

Or the name of the specific set could be the name of the Arbitrary Geom Param.

For something as application specific and light-weight as a special index number into a big array of uv sets, the meta data seems like a reasonable place to store this.

Lucas

--

[Steve LaVietes]

Lucas also rightly points out that GeomParams already have names -- so unless it differs in some way from the desired uvset name, we may need only the index.

-stevel

[SteveGalle]

Lucas, it sounds like this is how my implementation handles it currently; ArbGeomParams with names that reflect the uvsets they describe, along with a piece of metadata that 1) indicates that the param is a uv set, and 2) indicates which of the uv sets was the 'current' uv set at the time of export. One hiccup is that the primary uv parameter does not (that I can tell) support associating a name with the data. To address this I ended up making a concession and storing all of the uv sets in the arb params, and then additionally packing the primary uvs into the standard uv element of the geom. With this arrangement any implementations that don't support multiple uv sets continue work the same as they always have when reading the produced files, but updated importers can read all of the UV data in a consistent manner, and have access to all of the original properties. 

Steve

[SteveGalle]

Ben, thanks. You know, I had seen this thread, but completely spaced that it was you who had started it. I got Helge's name from the ExoCortex site and just went from there. In any case no worries, I'll be sure to ping you directly moving forward. 

For the sake of sanity it's be nice if we can come up with something that works for all of us and avoid anyone needing to support multiple code paths for alternate implementations. My code hasn't been pushed into production; without data in play I'm not overly attached to my implementation. I'm fine working with whatever standard we settle on; as long as it satisfies Steve, Lucas, and maintains the same set of uv set properties (name, index, 'currency'/which is primary) I'm happy. 

The point you bring up about one uvset being handled differently than the rest is what was bothering me as well; handling different instances of the same data type differently doesn't feel right. Like I was telling Lucas, I decided to put ALL of the UV sets into arbgeomparams, and then also write the 'current' or 'primary' uvs into the standard uv parameter. I don't believe the data ends up duplicated in the file, and going this way allows me to treat all of the uvsets the same at import time while maintaining compatibility with implementations that don't support multiple uv sets. I suspect this choice will be met with some skepticism, but it serves a purpose. 

Steve

[Lucas Miller]

If the name of the primary UV set is an important part of your workflow you could place it in the Meta data of the OPolyMesh object.

The primary UVs shouldn't be put into arbGeomParams, even if Alembic's data deduplication makes this cheap.

Lucas

--
 
 

[Ben Houston]

Steve Galle:

If you can share a reference Alembic file that has multiple UVs in the
form you support, which I can then inspect via HDFView and also test
with, it we can adopt our plugin to match in the next two weeks. We
will support multiple read paths because multiple UVs via our plugin
is already in production use. We have developed over time a way to
efficiently handle multiple code paths for backwards compatibility, so
this isn't that much of a challenge.

Lucas:

We do prefer to have a name for the default UV set as we do support it
right now in Maya even if there is only one UV set. 3DS Max does
request a specific channel number to load back in a UV set into the
approach location and it changes even if there is only one UV set.
Softimage also can name its default UV set to something arbitrary.

Back to Steve Galle:

Did you want to add a metadata name to your default UV set in your
reference implementation? Then I can follow yours instead of both of
us implementing something that may end up conflicting.

Best regards,
Ben Houston

[SteveGalle]

Yeah like I said this solution was a concession, but handling one UV set differently from the rest just adds seemingly unnecessary complexity to the import and export code, and this was a way to mitigate that while remaining compatible with current code. Utility functions that take/return vectors containing all (primary + additional) UV parameters (with consistent metadata, etc) could certainly abstract the discrepancy in the handling of primary vs additional uv sets, if that's an option you'd consider. At the end of the day I don't really care where the data resides in the file, but if possible it'd be great to avoid as much duplicated effort; there's no reason for Max, Maya, Nuke, Vray, and whichever other implementations will support multiple UV sets to each have to independently deal with the logic.

Steve

[Steve LaVietes]

I'm in favor of utility functions to abstract, discover and interpret these conventions.

-stevel

--
 
 

[Lucas Miller]

Originally all UVs were going to be part of arbitrary geometry parameters.

We decided to include an optional place on the schema to store them, because it can be annoying to look through all of the arbitrary  geometry parameters for those tools and workflows that only care about the primary UVs.

Lucas

On Tue, Jan 15, 2013 at 5:44 PM, SteveGalle <steve...@gmail.com> wrote:

--
 
 

[Jonathan Gibbs]

What makes a "second UV attribute" different from any other non-core attribute? I guess that there is an implied use as mapping coordinates for textures. But can't any 2- or 3-tuple attribute be used in that way?

--
 
 

[Steve LaVietes]

Yes. There is no difference between GeomParams (our term for what RenderMan calls "primvars") used to describe texture coordinates and those used to describe anything else. For most renderers, it's up to the shader to decide where to look and how to use any of it.

Our early internal debates were about whether uvs deserved any special designation at all. We settled on making the primary uvs a "first and a half class" member of the schema because it clarified the common interchange conventions.

The self-describing nature of GeomParams within arbGeomParams allows additional uv sets to be defined without being tied to the specific requirements of any individual application. What's a bit under-specified in practice is how that data (beyond its core definition) may map back into specific applications. In my mind, this is a good use case for metadata conventions -- backed by supported utility functions rather than schema-level changes.

-stevel

--
 
 

[Jonathan Gibbs]

Yes, I agree with Steve.

--
 
 

[SteveGalle]

Ok, back looking at this after being pulled away for a bit of other work, and then catching the flu. Can we talk about and try to nail down the metadata conventions? It would also be nice to settle on a set of utility function prototypes, but I'm less interested in that right away; my main goal is to try to be sure that I can write compliant data by the time production demands this be pushed into the pipeline. 

When I left this task a few weeks ago I was storing *all* of the uv sets in the arbitrary parameters. I was naming the parameter based on the uv set name, and I applied a metadata tag called 'currentUVSet' (or something similar) which did double duty, 1) indicating that the parameter was a uv set, and 2) if set true, indicating that the uv set in question was the 'current', or 'primary' set. Additionally I was storing the primary uvs in the standard schema. Data deduplication caught this, and only one instance of the data was stored. The positive side of this was that I could treat all of the uv sets consistently codewise, and the files I wrote were compatible with current readers. The main negative aspect as far as I can see is that Lucas is against the data duplication. Fair enough; a utility function in the library that returns all of the sets can abstract the discrepancy in storage strategy, so the consistency of code argument can go away. With that in mind, how about something along the lines of: 

primary uv data: written into the standard schema slot. Add a metadata parameter called 'uvSetName' to store the name of the uv set (what should it default to?). We know that it is the 'current' or 'primary' uv set data because it is stored in the allotted slot.

additional uv set data: written into ArbGeomParams. Add the same metadata parameter called uvSetName described above. Don't need the currentUVSet metadata item I am currently using since that is implied by where the data is written. Could name the parameters uvset##, or retain the uv set name based naming, but that seems redundant; if we have the parameter for the name we might as well express the index in the parameter name I suppose.

Thoughts?

Thanks, 

SteveG

[Lucas Miller]

I'm not aware of any V2f or V2d geom param with a scope of vertex or varying that are NOT UVs.

So there probably isn't a need to explicitly flag them with extra meta data indicating that they are UVs.

I would only store uvSetName (in the object meta data) if it differs from the applications default name. (and you are actually writing this data)

The name of all of the other uv geom params should reflect their name and not their index.

If index is important to some of your workflows, then you should store it in the meta data for those geom params. (key should be named uvIndex, value should be the index number)

What is the difference between a "primary" uv set and a "current" uv set?

Lucas

--

You received this message because you are subscribed to the Google Groups "alembic-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ben Houston]

I do like the idea of saving the main UV data set twice and then
letting it be auto-de-duped -- really cool solution.
-ben

[Lucas Miller]

It's not an ideal solution for the readers since a lot of them would end up reading the data twice.

[SteveGalle]

Lucas, hi. I wonder if someone might want to do something strange in the future like store sceen space motion vectors, or something else where a V2f might come in handy? The extra overhead of flagging them is minimal and feels like a good call to me vs. making the assumption that any V2f is UV data. 

I thought about not storing the name if it's default ('map1' in the case of maya), but reconsidered because that would mean that if I exported a cache from maya, and then read it into another package, the uv set name would change to whatever the target package's default uv set name happens to be. This seemed counterintuitive to me. 

The reason I didn't propose it that way around is that it would mean that in the case of the primary uv set I'd have to get the name from metadata, but in the case of additional uvsets I'd have to use the parameter name instead. I was trying to minimize discrepancies between the primary and additional uv sets. 

There is no difference between 'primary' and 'current', I've just heard them referred to as either, so I used both terms while referring to the same entity. 

Steve

Lucas

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discussion+unsub...@googlegroups.com.

[Lucas Miller]

Letting the app decide what it wants to name it's primary UVs isn't counter-intuitive, for many applications this is EXACTLY what you want to happen.

I wouldn't want to try and force an applications intrinsic property naming convention (when it has one) on any other application.

For example, I'm not sure that Houdini users would be very happy to have their UVs suddenly be called map1 when an Alembic file written out of Maya is loaded into Houdini.

Lucas

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.

[Jonathan Gibbs]

On Fri, Feb 1, 2013 at 9:39 AM, Lucas Miller <miller...@gmail.com> wrote:

"I'm not aware of any V2f or V2d geom param with a scope of vertex or varying that are NOT UVs.

So there probably isn't a need to explicitly flag them with extra meta data indicating that they are UVs."

I think it's nice to have a metadata field indicating the "type" of the param beyond it's storage type. For instance, a "v3f" could be a position or a vector. A "v2f" could be texture coordinates or a screen-space vector. OK, it's almost for sure texture coordinates, it's really the "v3f" case which could be many things.

So, perhaps some "type" attribute which is a string, with some standard types like "uv"?

I prefer this to a boolean "isUv" because it becomes undefined if you end up with "isUv" and "isVector" both on.

--jono

[Lucas Miller]

You can already differentiate between Normals, Points, Vectors (and Colors) in a similiar way (which uses metadata)

For the curious see:

http://code.google.com/p/alembic/source/browse/lib/Alembic/Abc/TypedPropertyTraits.h

Lucas

[SteveGalle]

Fair enough. So if and only if the primary uv set name is not the default, the application writing the cache will provide the name on the metadata tag 'UVSetName'. 

Are you still against a metadata tag explicitly declaring that a given parameter represents UVs? If we name the parameters to reflect the UV set name then the metadata can be lighter weight than storing the name there.

[Ben Houston]

We save out the names of all UV sets and then we have custom logic in
each app to either use the name or to use a default name depending.
Thus I do advocate saving out names for everything and letting the
importer decide whether or not it wants to use it. Also some logic
such as mapping Maya's map1 to Houdini's default texture name on
import is also useful.
-ben

> --
> You received this message because you are subscribed to the Google Groups
> "alembic-discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to alembic-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Lucas Miller]

The whole purpose of not naming a default UV set is so that you don't have to worry about any remapping logic.

Lucas

[Francois]

Was there a common resolution to this issue or is everyone handling multiple UVsets their own way ?

Would be a very good thing to have a common way of storing/reading them so we can have compatibilty

across the board.

Francois

On Tuesday, February 5, 2013 11:26:22 AM UTC+13, Lucas wrote:

The whole purpose of not naming a default UV set is so that you don't have to worry about any remapping logic.

Lucas

On Mon, Feb 4, 2013 at 6:04 AM, Ben Houston <neura...@gmail.com> wrote:

We save out the names of all UV sets and then we have custom logic in
each app to either use the name or to use a default name depending.
Thus I do advocate saving out names for everything and letting the
importer decide whether or not it wants to use it.  Also some logic
such as mapping Maya's map1 to Houdini's default texture name on
import is also useful.
-ben

On Fri, Feb 1, 2013 at 5:48 PM, SteveGalle <steve...@gmail.com> wrote:
> Fair enough. So if and only if the primary uv set name is not the default,
> the application writing the cache will provide the name on the metadata tag
> 'UVSetName'.
>
> Are you still against a metadata tag explicitly declaring that a given
> parameter represents UVs? If we name the parameters to reflect the UV set
> name then the metadata can be lighter weight than storing the name there.
>
> --
> You received this message because you are subscribed to the Google Groups
> "alembic-discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to alembic-discussion+unsub...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Best regards,
Ben Houston
CTO, Exocortex Technologies, Inc.
http://www.exocortex.com

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discussion+unsub...@googlegroups.com.

[Lucas Miller]

The primary UVs should be set on the mesh via setUVs, other UV sets should be stored as V2f geom params in the arb geom params.

Lucsa

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.

[Francois]

And any naming conventing for the other UV sets names ?

like uv_<uvSetName> ?

Francois

> email to alembic-discussion+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Best regards,
Ben Houston
CTO, Exocortex Technologies, Inc.
http://www.exocortex.com

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discussion+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discussion+unsub...@googlegroups.com.

[Lucas Miller]

Special naming conventions are currently unnecessary as any V2fGeomParam with a scope of vertex or varying will be a UV set.

Lucas

To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.

[SteveGalle]

Lucas, Francois, hi. I don't think a naming convention is the way to go, but I also don't agree with the idea that it is not necessary to somehow tag properties as representing UV data because there's nothing else that they would be. As a developer the assumption that any vert or varying V2fs are UV sets places a limit on the utility of that param type forever moving forward; it means that if future me comes up with something creative I want to do with them I'll either be constrained from doing so, or break assumptions that have been expressed in the code base. 

Earlier in the year I went through a couple of implementations, for the sake of discussion here's a description of what they were and of what's our current implementation.

From a coding perspective it would still be easiest to deal with the whole multiple UV thing this if all UV sets were handled in a homogenous fashion, but that notion has been met with resistance for reasons that have been explained further up in the thread (and in practice didn't impose as much chaos in the code, at least AbcImport and AbcExport, as I thought it might). Given this constraint my next solution was to save the primary UV set as it has always been saved before, but to also include the primary set with the rest of the UV sets. This retained compatibility with import code that has not yet been modified to read multiple UV sets, but allows updated import code to read all of the UV sets via a single code path. Due to data deduplication the files are basically the same size, besides minimal property and property metadata. This solution was also met less than favorably, so in the end I implemented a hybrid solution (from memory but I think this is accurate): 

on export: 

• Primary UVs saved as they always have been. 
  
• V2fGeomParams  created for *all* UV sets (including the primary set - this is needed because the default schema does not preserve the current uv set name. not storing duplicate data) 
  
• param name is uv set name
• every UV set Param has the attribute 'currentUVSet' 
• import code uses the presence of this attr on the metadata to identify that the param is a UV set
• this is true for the current UV set param

on import: 

• In NodeIteratorHelper:
• Loop through V2fs, checking for 'currentUVSet' attribute on metadata, push them onto a vector, and passed along with the color sets and mesh.
• in MeshHelper (most changes to setUVs):
• push the standard UVs onto the end of the vector of UVs
• loop through the vector, if the currentUVSet is 1 then store the name for when we get to the default UV set
• for each UV set do what the original setUVs code did, except pass UV set name to setMeshUVs.
• once done looping through call SetDefaultUVSetName on the ioMesh.

So that's roughly where we are today, besides little tweaks and whatever details I'm forgetting. The changes to AbcExport and AbcImport were actually more localized than I thought they'd end up being going in; whether the changes would be as easy in other implementations or not I really don't know. One last thing to point out is that we found it desirable to be able to enable/disable writing additional UV sets at export time in addition to the current ability to either export or not export UVs altogether.

Steve

[hvera]

I was curious to hear if there has been any resolution to the various issues raised in this discussion.

It certainly seems that the ability to identify, by some form of typing, that a particular set of V2fGeomParams are "uv" data would be helpful, along with the ability to preserve any "naming" that they have been given.  In addition the ability to identify the "default" uv set for the surface and ensure it can round-trip through various applications is a requirement.  Ultimately, wrapping this into a helper utility library would be a nice way to codify whatever convention is agreed upon, to Steve's L. point.

So, given that, I am curious how much, if any, work has been done to actually arrive at a more "official" convention?  It sounds like DD, through Steve Galle's work, has done a proprietary implementation.  It also sounds like ExoCortex Crate has implemented multi-uv in the method described above, by extending the PolyMesh class.  So, while it appears that we have a generic capability to store V2fGeomParams, and several different proprietary conventions, there is no "official" means that would help ensure at least some minimal amount of interop.

Henry V.

[Francois]

Here we use a convention very similar to what Steve described , V2f being interpreted as UV sets, we also add a uv_ prefix to the name to prevent

clashing in the future if we ever have V2f attributes that aren't UVs.

[Hans Baldzuhn]

Hi every one !

I'm currently integrating multi-uvSet support into our pipeline and I'm facing a rather big problem.

I successfully import and export uvSet data for static mesh (storing them in V2FGeomParam inside .arbGeom with the name of the uvSet)

But when I import an animated mesh, it is passed to the DG as a kMeshData, and the MFnMesh::createUVSet() only works for kMesh.

Did you find a simple way to handle this case ?

If I want to create a temporary kMesh to create the UV, I should do a big modification in the code to get the kMesh from the DAG.

Best
Hans

[Lucas]

Hi folks,

Just wanted to mention for those that might have missed it, multiple UV sets are more clearly supported in the main Alembic library since version 1.5.2 via a few utility functions mainly:

SetIsUV, and isUV utility functions in AbcGeom/GeometryScope.h

For backwards compatibility, and as mentioned in an earlier post any V2fGeomParam of varying, vertex, or facevarying scope is recognized as UVs.

SetIsUV can be used to explicitly mark something like this as NOT a UV.

For applications that support giving arbitrary names to the primary UVs use the setUVSourceName member function on OPolyMeshSchema and OSubDSchema prior to setting any of the UVs on those shapes.

To see if any source name has been set on your primary UVs, you can use GetSourceName in Abc/SourceName.h. if none has been set a blank string is returned and one should use the default UV name for the particular application.

Unfortunately support for these functions has yet to extend to AbcImport/AbcExport in our repo.

Lucas

[Hans Baldzuhn]

I found a solution for my createUVSet probleme,

There is an hidden methods in MFnMesh (not in the documentation) :

MStatus        createUVSetDataMesh(MString &uvSetName);

It's doing the exact same thing as the createUVSet  methods but works for kMeshData.

Tanks to rivierakid on this creativeCrash post:
http://www.creativecrash.com/forums/api/topics/createuvset-failure

[Hans Baldzuhn]

I every one !

With the release of maya 2025 I have now access to compiled library of alembic 1.5.0 so I'm updating my custom maya plugin with the newer version.

There was realy few changes in AbcImport and AbcExport source code so It was pretty quick.
But I'am having a severe performance issue without any change in my code.

My modification to allow the writing of all uvSet gives me an increase of about 20x in export time on a production asset.
It's a polygonal building made with many small object (and lot of duplications) : 4099 shapes for 2 300 000 triangles. and ( it doesn't even have multi uvSets !)
With my modification on alembic 1.2.0 it took around 30 seconds.
Now with 1.5 it takes around 640 seconds to export.

Both exported alembic are valid and are correctly re-imported inside maya.
And it works exactly the same (same performance) on 1.2.0 and 1.5

Only the alembic export is getting this huge slowdown.

I was really surprised because there was no change in the MayaMeshWriter source file on your side.
And my modification is only a simple loop over your original code.

I only reused the MayaMeshWriter::getUVs() but inside a loop over all uvSet for currentMesh.

On the old version, I was building the Alembic::AbcGeom::OV2fGeomParam an setting the sample inside each loop.
So it was made before the call to MayaMeshWriter::writePoly()
So I tried to build a std::vector< Alembic::AbcGeom::OV2fGeomParam::Sample > with the loop and then settings all properties in a new function right after the call to writePoly()
But there was no changes at all.


I don't know what to do now, I will continue digging the code to know where the overhead occures but I don't see how there could be such difference without any change on my side.

Hope someone can help !

Best,
Hans

[Hans Baldzuhn]

Alright, my bad,

there is absolutely no probleme with the writing of uvSets ...I'm sorry for bothering you before having made sufficient tests.

The guilty part was the -writeFaceSet ! 

I made it mandatory and this was causing the overhead. I don't know how this could take so much time, this would take no more than a few secondes in mel to list all shading assignment to this mesh !

I will look into it when I have time.

Thanks every one and sorry for the useless posts ...

Best,

Hans

PS: using alembic 1.5 and the export time drops to around 20 sec in hdf and 15 sec in ogawa !