ASWF TAC Meeting - April 07, 2021

Video Conference Link

Voting member attendance

Other Attendees

John Mertic, Linux Foundation
Andrew Grimberg, Linux Foundation Release Engineering
Rachel Romoff, Linux Foundation
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Mathieu Mazerolle, Foundry
Rob Fanner, Foundry
Rachel Rose, ILM, ASWF D&I WG
Van Bedient, Adobe
Anders Langlands, WETA
Rob Blau, Autodesk
Mitch Prater, Laika
Nick Cannon, VFX Reference Platform
Francois Chardavoine, VFX Reference Platform
Robert Fanner, VFX Reference Platform / Foundry
Robert Vinluan, VFX Reference Platform / Side Effects
Tiago Carvalho
Patrick Hodoul, Autodesk / OCIO
Vladimir Potapyev, Adobe
Nick Porcino, Pixar

Apologies

Eric Enderton, NVIDIA
Ashley Whetter, Python 3 WG
Joshua Minor, OTIO

Agenda

Slack Crisis?
- From last week, hitting the 10K message limit
- Brought up by Larry
- Looking at what Linux Foundation would do with other projects, investigating another solution, Matrix
- Andy has been looking at getting ASWF into PoC, can we invite team to present at next TAC meeting? Andy: yes, we can invite them.
- Status: ASWF is an option for LF PoC, but needs to be presented
- Larry: do we even know that? Can we just set up an instance to try out?
- Andrew: setting up a single Matrix instance to be offered to LF project, need to see how much load it can handle, so need to onboard projects in a controlled way. Not looking at how to handle users in China (due to firewall issues). Looking at standing up a federated China-specific Matrix instance. Down the line, looking how to federate to other Matrix instances, and how to bridge into other protocols (Slack, IRC…).
- Some services will be offered free to projects, some charges for specific features, although ASWF may already be in tier that would get us the all the features (TBD)
- Matrix team confirms will be able to present at next TAC meeting
- Larry: 2 / 3 to 3 / 4 of our quota is Direct Messages, so automatically generated public channels are not a huge contributor / drop in a bucket
- Rachel: still open to paying for Slack? Kimball / Andrew: Matrix will be a fixed cost (Slack is expensive when pricing around number of messages / users). Kimball: can we transfer membership from Slack to Matrix?
- Larry: many of use have multiple Workspaces in Slack, so splitting into multiple workspaces is not that big a deal.
- Wave: yet another desktop IM client is also an issue
VFX Reference Platform Guest Speaker Discussion (Francois / Nick / JF?)
- NickC: Sunset Dates, other things, how better to collaborate
- Preview of VFX Platform 2022
- Qt5 / Qt 6
- How to better collaborate between TAC and VFX Reference Platform
- CY2022 Preview for ASWF TAC
  - macOS: minimal is 10.15 (was 10.13)
  - Windows: Minimum platform toolset VS 2019 (was VS 2017)
  - Python 3.9.x (was 3.7.x)
  - NymPy: 1.20.x (wa 1.19.x)
  - OpenEXR 3.0.x (was 2.4.x)
  - OpenVDB 9.0.x (if released)
  - Boost 1.75 (was 1.73)
  - Intel TBB: 2020 Update 3 (was 2020 Update 2)
  - Intel MKTL 2021 (was 2020)
  - Will only put in the platform things that are already released (missed the delay in OpenEXR 3.0 release for 2021)
  - No change on compiler, C++ 17, Qt (too much work to go to Qt 6)
- Kimball: we should have fallen back to OpenEXR 2.5 (which was released) instead of 2.4, how to better collaborate
- NickC: software vendors made the call to stay on 2.4, issues with QA window where they are locked into versions. Schedule allows them to do the development and QA before release
- Kimball: better collaboration should help
- NickC: different release schedules between commercial products, open source libraries are a channel. Maybe ASWF projects can have a release cadence that can make it easier to sync up with the platform and make sure the platform represents the current versions, want to encourage the community to stay current with latest work.
- Cary: challenge to keep a finger on the pulse of the user community and keep track of what the community is using. VFX Platform can provide information on some of the major consumers of these libraries. Francois: biggest challenge is to get info from users in studios, or vendors? The Platform is for Software Vendors, studios can also use it as well. VFX Platform isn’t meant to be prescriptive for the studios, more for the vendors. Cary: users are free to use whatever version they want, OpenEXR would argue there’s no reason to stick with 2.4 since 2.5 has no breaking changes, just bug / security fixes. Criteria used to bump 2.4 to 2.5 may have been over conservative, without full understanding of downstream consequences.
- NickC: Platform has WG, 2 reps from VES Tech (Francois/Nick), 2 each from Foundry, SideFX and Autodesk. feedback@vfxplatform.com as well as public mailing list: build engineering community, low traffic. Process starts in January, quick first past. Answer “what’s current?”, then WG discussions to figure out how much work is involved in moving to latest versions. Different tradeoffs are considered within the WG. Broaden discussion in May.
- Cary: this better understanding of the VFX Reference Platform release process would have helped make better decisions.
- Francois: Sept 1st is the decision point after the SIGGRAPH BoF discussion, give 4 months for vendors to do testing / QA, in time for a January release. Have made exceptions with OpenVDB which traditionally releases in Early Oct, vendors were OK with it.
- Can always make exceptions if there is consensus, sometimes even in the middle of the year if it won’t lead to compatibility issues. But target is Sept 1st
- NickP: what’s the expectation of support for previous years of support? An issue for OTIO due to having to maintain Python wheels for old versions. Do we still need to support CY2015?
- NickC: there hasn’t been an explicit expectation set, was previously brought up by Larry. Larry: as a practical matter, it leaves everyone hanging if we don’t know this. NickC: VFX Platform can look at providing that guidance, on the website there are archived and current versions. So we could state that anything archived is no guarantee. In studios, some projects can go on for 3-4 years and require locking of versions. So we need to figure out what’s an appropriate window of support.
- Larry: two considerations: format support, and CI / build infrastructure.
- NickP: there’s an expectation that pip “just works”, and that’s hard to support to figure out what version of VFX Platform. Blender users “pip install” typically doesn’t work. Do we need to introduce other concepts around Python packaging to make it clear which platform we are targeting. Would allow modernising infrastructure.
- Francois: major vendors are unlikely to backport new version of packages into old versions of their software, what would it mean to set a “supported until” guideline if it’s not a mandate?
- Cary: informal policy about backporting fixes is “upon request”, but won’t pro-actively back port new bug fixes to older releases. Major code complication issue when trying to backport fixes written with newer C++ version into older version which uses an older C++ compiler.
- Francois: would be happy to incorporate guidelines coming from ASWF and other groups. Larry: VFX Platform may be in a better position to specify what to do, if major app vendors aren’t backporting new versions of ASWF projects into older products. Would be good to get “old version support policy” from vendors.
- Nick: anything that can be shared from vendors?
- Robert Fanner: in similar situation to ASWF projects, want to be forward looking, don’t want to have to support ancient versions, but if an important / project needs a fix to an old version, may have to go back and patch it. May be specific to a customer / not wide release. What’s unlikely to happen would be to update the version of OpenEXR used by an old version, bigger changes are unlikely to be ported to old versions, smaller changes more likely. Large customers on air gapped network may care less about CVE / security fixes. Makes sense for VFX Reference Platform to put together tentative guidelines and run those by TAC. May take more conservative view of security fixes / CVEs.
- Robert Vinluan: similar position, tend to support 4 years back, support last 2 major versions of Houdini releases, anything that would require to be patched to old versions would be on request only (showstopper for a studio), but only minor / small changes, would not be looking to bump an old version of Houdini to a new version of OpenEXR for instance. Larry: less concerned about back patching old versions rather than what needs to be supported for current versions. Studios will build an ecosystem around specific versions, so may need to support older formats even in current releases.
- Robert Fanner: it is possible to work around lack of library namespace / versioning.
- Nick: great feedback, will take this for discussion and come back.
- Cary: need to do a better job to integrate the VFX Platform timeline into our projects.
- Nick: most studios are open source licensees for Qt5, no more patches from The Qt Company, KDE has come with arrangement with Qt Company where they will produce patches critical patches (security + fixes) that isn’t a fork, which can be a path to keep using Qt 5.15 without having to live with serious security issues.
- Patrick: supporting multiple C++ versions (for instance) adds significant costs to CI infrastructure, supporting all combinations of platforms / C++ compilers can be quite heavy / expensive. For OCIO thinking of moving to 2.1.x for next year, but nothing is decided yet, so will let VFX Platform now.
OAM Presentation (Rob)
- Rob Blau, product manager at Autodesk for Shotgun
- Open Asset Model (OAM)
- Asset Structure + Asset Behavior + Plugin Architecture
- Build asset management features
  - Structured Data
    - Assets (not files)
    - Dependency tracking
  - Automation
    - Scene building
    - Quality Control
  - Collaboration
    - Parallel contributions
- Asset Structure
  - USD-defined asset types:
    - Layers, properties, variants
    - Versioned
    - Extensible, shareable
- Asset Behavior
  - Implementation defining:
    - Asset creation
    - …
- Plugin Architecture
  - Provide an abstraction over workflow details such as editor, storage, and asset structure
  - Enable an ecosystem of workflow plugins that work across multiple studios
- Workflow ecosystem
  - Known and standardized asset types
  - Standards as running code, not just documents
  - Known ways to interact with assets from DCCs
- Target is Open
  - Able to commit to open sourcing the results
  - Currently in a private GitHub repo separate from other code and targeting ASWF compatibility (and people being able to partner with it) (not enough in repo to show publicly yet)
- Partnering
  - Building partnerships with studios, vendors, and industry groups
  - Collecting example workflows and asset schemas
- There are WGs that are somewhat overlapping with some of these ideas, happy to follow up outside, or here
- Mathieu: working on a similar effort at Foundry, would love to collaborate, so should connect. More generally, how are Movielabs efforts impacting this (software defined workflows). Rob: yes, have been interacting with Movielabs, also security efforts, cloud efforts, one of the industry groups involved in OAM.
- Mathieu: what’s the main problem the system is trying to solve? Rob: common representation, in particular being able to define those standard representations in an open ecosystem where no single vendor owns the representation, and doing it in a way that’s programmatically accessible so it doesn’t get reimplemented everywhere, but instead can use a standard / reference plugin. For instance how to reference a cut object (OTIO). Also help represent how a block of data represents an asset instead of just a bunch of files and directories. Mathieu: seems we have the same intentions, ideally can help build something common.
- Kimball: have you been discussing with Asset WG? Rob: have been having internal conversations, WG seems to be more about “standard assets” rather than “asset standards”. Wave: yes, that’s correct. Could be interesting to see how to represent assets gathered by the WG could be represented in an OAM schema. A library of standard assets could be “converted” to an OAM schema. Michael Min: looks really interesting and exciting. Gordon: wanted to share with the group to get connections, these concepts exist in a lot of studios, so an opportunity to get more people engaged, see how it could fit their needs. Rob: yes, anyone who is interested in knowing more can reach out to Rob. Gordon: want to do this in the open, not having a data model to reason about assets limits what types of systems can be built. Makes it possible to connect DCCs, production management… Rob’s email contact: rob.blau@autodesk.com
- Anders: are you targeting specific asset kinds first? Rob: heart of post / vfx pipeline: assets with a rig, simple shot work, animation, lighting, comp. Then a bit deeper in editorial, flow of plates through editorial, time based disciplines. Going broad at first to get a good representation. Also collecting cases where it falls over, where production changes requirements at the last minute, multiple versions of an asset with same dependencies, designing around edge cases where if you don’t take those into consideration early, it gets ugly. Wave: what’s the relationship with OTIO? Rob: don’t want to be the assets themselves, want to wrap around the assets. So OTIO can be the standard asset for representing time based information.
OpenCue deep dive (time permitting, otherwise push to next meeting)
PRs from John:
#241 - Make TAC Repo into a site ( https://github.com/AcademySoftwareFoundation/tac/pull/241 )
#242 - Proposed working group changes ( https://github.com/AcademySoftwareFoundation/tac/pull/242 )
#243 - Proposed adjustments to the project lifecycle ( https://github.com/AcademySoftwareFoundation/tac/pull/243 )
Vote on Asset WG charter to make it an official WG:
- https://wiki.aswf.io/display/ARW/Asset+Repository+WG+Home