Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleClarify and Define Separation of Concerns

Features

  • Assignments
  • Lights
  • ...

Ownership

  1. Who owns data value resolving. ? (USD?)
  2. Who owns usd<->mtlx synchronization? (USD observability?)
  3. 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.?
  4. Who owns the usd->mtlx conversion. Is it the same as 1. (I don't think so). Needs USD to be more open.
  5. For 3/4 can this be opened up so USD does not own this completely.
  6. ?
  7. Who owns validation (USD?)
  8. Who owns reference definitions, who owns implementations (MTLX). Even USDPreviewSurface.MaterialX?), including USDPreviewSurface?
  9. Who owns code generation access.
  10. 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
titleAlignment 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

...