# Support different material binding purposes based on current active display purposes

**URL:** <https://forum.aousd.org/t/support-different-material-binding-purposes-based-on-current-active-display-purposes/2633>\
**Category:** Hydra\
**Tags:** rendering, cpp\
**Created:** [August 5, 2025, 2:07pm UTC](https://forum.aousd.org/t/support-different-material-binding-purposes-based-on-current-active-display-purposes/2633 "2025-08-05T14:07:13Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mithridates](https://avatars.discourse-cdn.com/v4/letter/m/aca169/32.png) [@Mithridates](https://forum.aousd.org/u/Mithridates)\
**Post date:** [August 5, 2025, 2:07pm UTC](https://forum.aousd.org/t/support-different-material-binding-purposes-based-on-current-active-display-purposes/2633/1 "2025-08-05T14:07:13Z")

</div>

## Problem Description

In the current OpenUSD implementation, a render delegate specifies its supported material via the `GetMaterialBindingPurpose()` function, which means only materials with a matching purpose are instantiated. An issue arises in `usdview` when attempting to switch the **Display Purpose** ; alternate materials fail to render because they were not created in the first place.

I would first like to validate with the community whether this is the expected behaviour, a bug, or a missing feature.

* * *

## Proposed Solution

I have devised a potential solution requiring minimal changes to the OpenUSD core and render delegate implementations (in case they want to support this feature).

The proposal involves introducing a new virtual function that allows a render delegate to return a vector of all supported material binding purposes. Hydra could then use this information to dynamically bind the appropriate material to each prim based on the currently active **Display Purpose**.