Page Comparison

...

2. MaterialX in Hydra
(visualization, viewport, runtime, rendering)

There are (at least) two possible rendering workflows. 

1. The translation process to UsdShade and back to MaterialX is undesired. UsdShade allow for resolving of  inputs only. That is optimally rendering can occur from
   1. the source MaterialX reference or
   2. shader code can be independently (pre)-generated from MaterialX (or other source) but is associated with USDShade nodes  (e.g. code references per node in OSL).
2. A translation process is required for UsdShade.

If MaterialX is required then CodeGen (or ShaderGen) functionality is available.

...

Ideally this would be outside of Hydra (which is not the current case) 

Therefore an application may be required to maintain MaterialX for rich material authoring workflows and translate to UsdShade networks for rich runtime visualization workflows. Often, an application might need to revert back to MaterialX for rich transport of material assets.
This dual mode operation requires unnecessary Shader Code regen such as during:

...

We want to continue to use USDShade as the native runtime in Hydra but we want MaterialX as the ground truth and not have static snapshots in Usd form as they are duplicates that can get out of sync.

GoalGoals: Improve MaterialX - UsdShade updates (both topology and inputs), USDShade with MaterialX source code, Hydra independence Translation / ShaderGen independent from Hydra. 

This includes improving performance issues due to shader recompilation, handling updates to materials, material topology changes. We may also need to introduce Hydra and/or MaterialX APIs to report material input and network updates.

...