You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
Version 1
Next »
Clarify and Define Separation of Concerns
Features
Ownership
- Who owns data value resolving. (USD)
- Who owns usd<->mtlx synchronization (USD observability)
- Who owns the mtlx->usd conversion. Can this is separated out with formal synchronization. (Recent work from Jerry and others for component dependency logic should be discussed). Needs USD to be more open.
- Who owns the usd->mtlx conversion. Is it the same as 1. (I don't think so). Needs USD to be more open.
- For 3/4 can this be opened up so USD does not own this completely.
- Who owns validation (USD)
- Who owns reference definitions, who owns implementations (MTLX). Even USDPreviewSurface.
- Who owns code generation access.
- Who decides what is common material metadata. This has caused "friction" as usdshade and mtlx are not 1:1.
Alignment and Feature Parity
Lossless interop
- Applicable USD limitations
- Assignment expressions
- Round trip:
- Mtlx -> USDShade -> Mtlx
- Mtlx -> USDShade -> *USDShade (e.g. shot override) -> *Mtlx (with the changes)
Other
- Dependency tracking, compatibility, and versioning
- Cross referenced documentation
- End-to-end colour management
Fast and Robust Hydra Rendering
- Improve MaterialX - UsdShade updates (both topology and inputs)
- USDShade with MaterialX source code
- Translation / ShaderGen independent from Hydra
Fit for Purpose - Extensibility
- Strive for standardisation but empower diverse workflows
- Standardise new shading models
- Support workflows relying on custom USD schemas and MaterialX node definitions
Guide Community
- Promote MaterialX as a material description in USD
- Curate test and validation assets
- Promote and document best practices
- MaterialX blackbox references, with MaterialX overrides expressed in USD?
- General pipeline considerations