There is some interesting code in usdMtlx ParseElement that automatically adds the main primvar “st” (or whichever primvar is declared in the USDMTLX_PRIMARY_UV_NAME env var) for all nodes of type ND_texcoord_vector2.
While this handles more that 95% of the cases, it would be interesting if this could handle cases where the index attribute is not zero. I see no easy way for _GetPrimvarNameAttributeValue in usdImaging to actually be able to compute a secondary primvar name (st → stX, uv0 → uvX) from an integer VtValue without creating an expression language or storing a functor to help deal with an int variant that can be either be appended or applied to the main UV set name.
I am a bit unsure how to proceed from here, but would be willing to provide an implementation if we agree on how to store and process the information.
srf1: ND_standard_surface_surfaceshader with inputs:base_color connected to img1 outputs:out
img1: ND_image_color3 with a valid file to display, and inputs:texcoord connected to tex1 outputs:out
tex1: ND_texcoord_vector2 with inputs:index set to the integer value "1"
This network requires the primvar “st1” according to the current naming convention. I had code that noticed that and added “st1” to the list of primvars my HdMaterialDelegate required, however, the HdMesh my render delegate received only had “st” cached because that’s all it had to cache according to the info provided by ParseElement.
I have joined a scene that currently renders a straight grid in UsdView based on the “st” primvar. Yet the scene describes use of UV at index 1, which should be the 45 degree slanted UVs found in “st1”.
Very belated, but if there’s community consensus, mapping index “N” to “stN” seems fine to me, although mapping index 0 to “st” remains nice. UsdMtlx will create a node definition with referenced primvars, and you can just use TfToken(TfStringPrintf(“%s%d”, primaryUvName, index)) to generate the primvar name there. If there’s a string-named primvar, you’d want to pass that through as-is, though.