# Accessing secondary indexed primvars in HdMaterialNetwork with MaterialX ND\_texcoord\_vector2
**URL:** https://forum.aousd.org/t/accessing-secondary-indexed-primvars-in-hdmaterialnetwork-with-materialx-nd-texcoord-vector2/482
**Category:** Hydra
**Created:** [August 28, 2023, 4:16pm UTC](https://forum.aousd.org/t/accessing-secondary-indexed-primvars-in-hdmaterialnetwork-with-materialx-nd-texcoord-vector2/482 "2023-08-28T16:16:24Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@jgamacheADSK](https://forum.aousd.org/u/jgamacheADSK)
#### Post date: [August 28, 2023, 4:16pm UTC](https://forum.aousd.org/t/accessing-secondary-indexed-primvars-in-hdmaterialnetwork-with-materialx-nd-texcoord-vector2/482/1 "2023-08-28T16:16:24Z")
There is some interesting code in usdMtlx [ParseElement](https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usd/usdMtlx/parser.cpp#L475) 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](https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usdImaging/usdImaging/materialParamUtils.cpp#L147) 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.
What would you recommend?
Thanks!
Jerry Gamache
Autodesk
---
### Author:  [@tomc](https://forum.aousd.org/u/tomc)
#### Post date: [September 5, 2023, 6:57pm UTC](https://forum.aousd.org/t/accessing-secondary-indexed-primvars-in-hdmaterialnetwork-with-materialx-nd-texcoord-vector2/482/2 "2023-09-05T18:57:14Z")
Hi Jerry,
Would you mind posting an example network and how you think it should work? That would help me figure out how we could best route the data.
Thanks,
Tom
---
### Author:  [@jgamacheADSK](https://forum.aousd.org/u/jgamacheADSK)
#### Post date: [September 5, 2023, 7:50pm UTC](https://forum.aousd.org/t/accessing-secondary-indexed-primvars-in-hdmaterialnetwork-with-materialx-nd-texcoord-vector2/482/3 "2023-09-05T19:50:37Z")
The simplest network would be:
```auto
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”.
[Texcoord\_1.usda](https://forum.aousd.org/uploads/short-url/rtNKbCrlxRM3jf4Kj6OYHcRRkI4.usda) (1.7 KB)
---
### Author:  [@tomc](https://forum.aousd.org/u/tomc)
#### Post date: [September 20, 2024, 6:26pm UTC](https://forum.aousd.org/t/accessing-secondary-indexed-primvars-in-hdmaterialnetwork-with-materialx-nd-texcoord-vector2/482/4 "2024-09-20T18:26:48Z")
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.