Can we write UV metadata to allow easier discovery of uv roles?

[koen-v]

When we need to interpret the uv sets in a usd outside of maya, the index of the of set is more important then the name.

I propose this as an extension of UsdMayaWriteUtil::WriteMap1AsST(). Ideally we would like to write all the uv sets as st, st1, st2 etc.

In order to enable round-tripping with maya, we can store some meta data, just like we do for the skeleton and interpret this on import. For example:

 texCoord2f[] primvars:st = [...] (
            customData = {
                dictionary Maya = {
                    int index = 0
                    token name = "map1"
                }
            }
            interpolation = "faceVarying"
        )

int[] primvars:st:indices = [0, 1, 2, 3, 3, 2, 4, 5, 5, 4, 6, 7, 7, 6, 1, 0, 1, 6, 4, 2, 7, 0, 3, 5]

texCoord2f[] primvars:st1 = [...] (
            customData = {
                dictionary Maya = {
                    int index = 1
                    token name = "my_second_uvset"
                }
            }
            interpolation = "faceVarying"
        )

int[] primvars:st1:indices = [0, 1, 2, 3, 3, 2, 4, 5, 5, 4, 6, 7, 7, 6, 1, 0, 1, 6, 4, 2, 7, 0, 3, 5]

texCoord2f[] primvars:st2 = [...] (
            customData = {
                dictionary Maya = {
                    int index = 2
                    token name = "my_third_uv_set"
                }
            }
            interpolation = "faceVarying"
        )

int[] primvars:st2:indices = [0, 1, 2, 3, 3, 2, 4, 5, 5, 4, 6, 7, 7, 6, 1, 0, 1, 6, 4, 2, 7, 0, 3, 5]

I have some code to enable this behavior, it's not quite ready for primetime. What would be a good way to allow you guys to look at this to consider it? Shall I create a pull request for this ( I dont know how to do 2 pull requests at the same time as I can only fork the depot once, I can do that after the other one is done) ?

Thanks,
Koen

[kxl-adsk]

@koen-v Can you describe a bit more the workflow that you are trying to implement? Why do you need to rely on the index? Is it something specific to your studio pipeline or others will need it as well? BTW. I almost wonder if we should start this as a discussion conversation first and then convert to an issue - something to consider for next time.

The best to show us the code would be a DRAFT pull request. You can create as many as necessary pull requests and draft pull requests from a single repository. In order to achieve this, you will create a feature branch per the pull request you are working on. This is one thing that is different from what I saw you did currently, i.e. you opened a pull request from your dev branch. The flow for you to try:

• checkout the dev branch (without any modifications)
• create a new feature branch out of it
• commit changes to this new feature branch
• push the branch to remote
• open PR

[koen-v]

Ha thanks very much for those last few steps, that's exactly the part I did not understand.

Sorry about creating an issue, I meant this as a discussion point. We have unnamed uv sets in the game, and in the asset manager you just pick 0,1,2 etc. In the current exporter, we follow the indices we get from Maya when defining the order in our custom format. For USD, I would like a similar workflow. To make an object with multiple uv's look the same when exported as a usd vs what we do now, I need to know a little bit more then just the name to make the connections on the other end, does that make sense?

For us, writing all the uv sets with a standard name (st, st1, st2,etc) works great and helps other tools make better sense of the sets. The meta data is there mostly to enable a round trip to maya with the original name. The index does not really need to be there, as we can derive it from the name, I might take that out.

Over time we could adjust out pipeline to allow users to pick uv sets by name in the asset manager, but we would first like to replace the old format without any tool changes and then start using the newly gained features.

Thanks,
Koen

[kxl-adsk]

If I understood it well, what you need is to preserve the original indexing when UV sets were authored in Maya. Exporter currently will export them in the same order as authored, so you should be able to use this order when presenting the list of options in your asset manager?

Another option would be to rename UV sets in Maya prior to export. This will allow you to use whatever naming convention you need, including st, st1, st2, stN-1.

[kxl-adsk]

FYI. I converted this issue to a discussion.

[koen-v]

If we dont change the name, I have to rely on USD to also present them in the order they where written when traversing the stage. I feel that can lead to some odd bugs where uv sets get switched around. We currently export maya uvset 1 ( regardless of the name) to internal uv set 1 etc. Now we add usd inbetween:

maya1 -> usd1 -> internal1

That second step gets much harder if we just have a name. It is a simple extension of the special case to write map1 to st.

This is what I am doing at the moment, and it works well for us. I am mostly curious if there is any appetite to merge something like this back.

in maya-usd\lib\mayaUsd\fileio\utils\meshWriteUtils.cpp

   std::string setName = name.GetString(); 
    
    // The name we remap to be st, st1, st2 etc, and we store the original name
    // in some custom data we can later access    
    if (UsdMayaWriteUtil::WriteUVAsST()) {
        setName = UsdUtilsGetPrimaryUVSetName();
        if (index > 0) {
            setName += std::to_string(index);
        }
    }

    // Set the name to the remapped name
    UsdGeomPrimvar primVar = primSchema.CreatePrimvar(TfToken(setName.c_str()), uvValueType, interp);
    
    // Store the original name
    primVar.GetAttr().SetCustomDataByKey(TfToken("Maya:name"), VtValue(name) );

[kxl-adsk]

I am mostly curious if there is any appetite to merge something like this back.

Export map1 to st is not the default behavior. We prefer to make as little change to legacy workflows as possible unless there is a common agreement that it will be beneficial for many. Let's see if there is anyone else interested in adding this support.

Cheers,
KxL

[koen-v]

Sounds good, we'll leave this internal for now.

As a side note, I also started to make decent progress on scaling the units on import and export, to the point where it works for models and rigs, but making that a generic solution is a lot more work. I doubt there is interest in this limited version, but I'd be happy to discuss in another thread.

Cheers,
Koen

[koen-v]

Hello KxL,

I started looking at fixing up the uv's set names outside of maya. I am not convinced the order is reliable.

For a less controversial change, would you consider a pull request that leaves the name alone but just adds the maya:index as custom data( much like the maya:generated on usdskel)?

Thanks,
Koen

[koen-v]

it looks like the uv sets are writing sorted in alphabetical order:

[dgovil]

I don't recommend trusting the order in the USD to be consistent. AFAIK order is not guaranteed since composition arcs may change things. Workarounds are to either do what you're suggesting and writing in the index as metadata or creating an ordered collection and relying on that.

…

On Sat, Apr 10, 2021 at 6:22 PM Koen Vroeijenstijn ***@***.***> wrote: it looks like the uv sets are writing sorted in alphabetical order: [image: uv_sets] <https://user-images.githubusercontent.com/4185553/114289038-9ccdc600-9a29-11eb-9b5f-52aa49438436.png> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1256 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB4XUWF2WA5WJY3XOEZACDTID2VPANCNFSM4ZHF3AEA> .

[koen-v]

Yeah, relying on the order seemed kind of dodgy. I have been able to move the solution to all the issues I had with the of the shelve exporter into an external script ( including a proper unit conversion for our use case. I had one in the plug-in, but that code is so much more complicated then just adjusting it in the usd after)

This is the one remaining problem I don't know how to fix without building our own plugin and it's such a small fix.

Thanks for the reply ( and all the code I noticed you have been fixing)

Cheers,
Koen

[koen-v]

Hello KxL,

I found a good reason to keep the index around. As I mentioned our pipeline is entirely index based. The UsdPrimvarReader however takes a name. When we have indices, we can guarantee consistent naming by renaming the uv maps or looking them up by index.

The reasons this is important is to allow sharing of materials between objects. If you cannot guarantee the uv map name, you will need to specialize every material per object to override the name of the uv set in the primvar reader. If you however link by index ( or a consistent name derived from the index) you can re-use most materials without modification.

Hope that makes sense.

Since this will be true in other pipelines as well, I hope you'll consider my pull request:
#1326

It won't change the names or break any current setups, it just add the index for people to use later.

Thanks,
Koen

[kxl-adsk]

Hi Koen. Can you share a test file - I would like to play with it a bit more.

Thank you,
KxL

[koen-v]

Of course, thanks for looking. Here is a file I use, with the export and a "fixed" version, that one fixes more things then just the uv's but it also illustrates the uv issue, especially the "gridMesh" object shows the problem.

Thanks,
Koen

unitTest.zip