How we prioritise our objectives
We use a Mural board with a priority radar to discuss our shared priorities across different topics. Cards that are of primary importance are placed in the radar's innermost circle.
| Info |
|---|
Cards can be added at anytime to the categories on the left but we move the cards to radar as a team. |
Summary
| Expand |
|---|
| title | 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.MaterialX?), including 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.? There's not a 1:1 mapping between USDShade and MaterialX so how can we drive standardisation?
|
| Expand |
|---|
| title | 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
|
...