# Passing UsdShadeInput metadata to Hydra

**URL:** <https://forum.aousd.org/t/passing-usdshadeinput-metadata-to-hydra/614>\
**Category:** Hydra\
**Created:** [September 7, 2023, 3:57pm UTC](https://forum.aousd.org/t/passing-usdshadeinput-metadata-to-hydra/614 "2023-09-07T15:57:45Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![nv-derek](https://avatars.discourse-cdn.com/v4/letter/n/e8c25b/32.png) [@nv-derek](https://forum.aousd.org/u/nv-derek)\
**Post date:** [September 7, 2023, 3:57pm UTC](https://forum.aousd.org/t/passing-usdshadeinput-metadata-to-hydra/614/1 "2023-09-07T15:57:45Z")

</div>

What would be the best way to handle the passing of metadata through to Hydra?  
To explain here is a specific problem that I am currently trying to solve.

Material X parameters can be tagged with a unit attribute:

_MaterialX allows floating-point and vector values to be defined in terms of a specific unit and unit type, and can automatically convert values from their specified unit into a scene unit of the same type specified by the application. This allows images and the quantities they represent such as displacement amount to be specified at an absolute real-world size, and then be converted automatically to the expected scene units of the application._

Presently the UsdMtlx plugin ignores this data and I have submitted a ticket and MR for this:

> <https://github.com/PixarAnimationStudios/OpenUSD/issues/2663>
>
> \### Description of Issue
> Certain Material X parameters, the user can supply \`un…it\` and \`unittype\` attributes.
> 
> \_MaterialX allows floating-point and vector values to be defined in terms of a specific unit and unit type, and can automatically convert values from their specified unit into a scene unit of the same type specified by the application. This allows images and the quantities they represent such as displacement amount to be specified at an absolute real-world size, and then be converted automatically to the expected scene units of the application.\_
> 
> Presently \`unittype\` can be one of two values.
> 
> distance: - with unit values of: nanometer, inch, yard, cm, meter, etc.
> angle - with unit values of radian or degree
> 
> The reader should be updated so that if the unit attribute is present it's value is stored as custom data.
> 
> \### Steps to Reproduce
> 
> 
> \### System Information (OS, Hardware)
> Windows
> 
> \### Package Versions
> USD 22.11
> MaterialX - 1.38.4
> 
> \### Build Flags

> <https://github.com/PixarAnimationStudios/OpenUSD/pull/2664>
>
> \### Description of Change(s)
> 1. Update \`UsdMtlx\` reader to store unit attribute… value as custom data.
> 2. \`TestFileFormat\` - add \`test\_unit\_attribute\` test and relevant test data.
> 
> \### Fixes Issue(s)
> \- #2663 
> 
> \<!--
> Please follow the Contributing and Building guidelines to run tests against your
> change. Place an X in the box if tests are run and are all tests passing.
> \--\>
> \- \[x\] I have verified that all unit tests pass with the proposed changes
> \<!-- 
> Place an X in the box if you have submitted a signed Contributor License Agreement.
> A signed CLA must be received before pull requests can be merged.
> For instructions, see: http://openusd.org/release/contributing\_to\_usd.html
> \--\>
> \- \[x\] I have submitted a signed Contributor License Agreement

In our Hydra delegate we are calling the MateralX-\>MDL code generator; however in order to generate the correct result we need to have access to the unit metadata.

This mimics another issue that we have internally and that is passing colorspace information to Hydra. Presently we have a local modification to to the HdMaterialNode to add an additional field like so:

```auto
struct HdMaterialNode
{
    SdfPath path;
    TfToken identifier;
    std::map<TfToken, VtValue> parameters;

    // local changes - pass color space metadata
    std::map<TfToken, TfToken> paramColorSpace;
};

```

I could make this a more generic solution and pass all metadata:

```auto
struct HdMaterialNode
{
    SdfPath path;
    TfToken identifier;

    // local changes - pass all metadata
    std::map<TfToken, VtDictionary> paramMetadata;
};

```

Is this a reasonable solution?  
If not any suggestions as to what would be a reasonable solution are much appreciated.

Ideally we would like to remove custom/local modifications to the codebase so if it is reasonable is this something worthy of an MR to OpenUSD?