ASWF TAC Meeting - June 30, 2021

Video Conference Link

Voting member attendance

  • Kimball Thurston - Chairperson, Weta Digital Limited
  • Bill Roberts, Adobe
  • Gordon Bradley, Autodesk
  • Tony Micilotta, DNEG
  • Bill Ballew, DreamWorks Animation
  • Christina Tempelaar-Lietz, Epic Games, Inc.
  • Brian Cipriano, Google & OpenCue Representative
  • Sean C McDuffee, Intel Corporation
  • Larry Gritz, Sony Pictures Imageworks
  • Jean-Francois Panisset, VES Technology Committee
  • Cory Omand, The Walt Disney Studios
  • Daniel Heckenberg - Animal Logic Pty Ltd / Industry Representative
  • Eric Enderton, NVIDIA
  • Sean Looper, Amazon Web Services
  • Michael Min, Netflix
  • Michael B. Johnson, Apple
  • Greg Denton, Microsoft
  • Sean O’Connell, Advanced Micro Devices
  • Mark Visser, Unity Technologies
  • Ken Museth, OpenVDB Representative
  • Michael Dolan, OpenColorIO Representative
  • Cary Phillips, OpenEXR Representative
  • Joshua Minor, OpenTimelineIO Representative
  • Chris Kulla, Open Shading Language Representative

Other Attendees

  • John Mertic, Linux Foundation
  • JT Nelson, Pasadena Open Source consortium / SoCal Blender group
  • Carol Payne, Netflix / D&I WG
  • Sergio Rojas, Arena World
  • Scott Wilson, Rust WG
  • Deke Kincaid, Digital Domain
  • Jeff Bradley, Dreamworks
  • Nick Cannon, VFX Reference Platform / Disney Animation
  • Francois Chardavoine, VFX Reference Platform / Lucasfilm
  • Alex Meddick, Rising Sun Pictures

Apologies

  • Ashley Whetter, Python 3 Working Group
  • Cary Philips, OpenEXR

Agenda

  • Nick and Francois will be joining again. I would like us to do this a couple times per year so we can enhance the VFX reference platform collaboration.

    • Welcome François and Nick

    • Kimball: WETA struggles with how many VFX Platform years to support, currently supporting 5 in production, definitely a burden. Ken: definitely causing frustration. In OpenVDB decided to support current + 2 previous years of VFX Platform, posted on forum, didn’t get any objections. Some studios seem to be very slow to update. Francois: can you clarify “supporting an older version”? There’s a range of what “supporting” means: CVEs, critical bug fixes, back porting small features. ASWF could define what the policy is. Most larger studios support “every version that runs on the current OS”, also driven by versions of commercial tools. Larry: one more dimension exists, how far back in versions does OpenEXR need to patch, but also if OpenEXR is just building its current version, how far back in terms of the dependencies it has should it be able to build against. Ken: had a recent complaint that current version of OpenVDB 8.1 does not build with latest version of OpenEXR 3.0. That was decided because OpenEXR 3.0 is not part of VFX Reference Platform, but there was lack of understanding of why projects in the ASWF aren’t in lockstep. When 8.1 is released, deprecate everything in the code relative to version 5. Any changes to ABI, change the major version, but will keep the code (using #pragmas) so you can build version 8 with ABI 6. The cutoff means getting rid of that old compatibility code.

    • Francois: that’s definitely outside the scope of the VFX Platform, it’s about binary compatibility, which requires API and ABI compatibility for compiling and linking.

    • Nick: have been having conversations about sunset guidance, can get complex very quickly. More inclined to figure out what’s the simplest guidance we can give, and what’s the goal of this guidance. It’s about setting expectations with studios and consumers of software, and setting expectations of software developers of how long are expected to support versions. On vfxplatform.com site, specifying current year + 3 previous years is on the main page, and everything else could be moved to archive page. There are of course exception, but 3-4 years seems to be perceived as reasonable by large studios, even if they have projects that run longer than that. Once we get to BoF at SIGGRAPH, would like to be able to publish high level sunset guidance.

    • Kimball: it’s not so much the specific version number, but more the C++ support level (C++ 11/14/17), these major switches are where a project like OpenEXR typically has issues. Compiled plugins for old versions of Maya for instance. There was some discussion of switching of major compiler versions could also be coordinate with switching major compiler versions? C++ major release cadence has been on 3 year schedule. Nick: only last year CY2020 C++ 14 was still the version, so new sunset guidance would still expect those versions to be supported. Gordon: Maya USD plugin gets tricky, developers want to adopt new version of a C++ standard, will try to support any back versions as possible, but can have really bad impact on code quality.

    • Francois: hard to imagine practical guidance for ASWF projects to force latest code to compile against specific old versions of software, not asking for “Maya USD plugin to be compiled for Maya 2016”. Nick: clear high level guidance can be critical to help manage expectations, “this is the industry expectation / practice”. Kimball: if we say “patches for 3-4 years”, does that sound like a good proposal? Anyone have counter examples? Francois: off the shelf apps that ship with bundled libraries (statically linked / compiled in a special way), so even if ASWF projects get patched, commercial software may not be. Gordon: how do we provide security responsiveness for older versions vs how many versions of VFX Platform can be supported in a single software version? Internally have tools to track security issues, but can get tricky (for instance Qt 5 is already out of support window). How do we get a CVE plan in place for software that links statically. Had a chat with Cory to get more visibility on CVEs for USD, EXR does a really good job so could set the standard? We definitely have exposures as a community. For commercially released software, mostly target the current year, it’s just too hard otherwise. Kimball: would it make sense to publish package building scripts. For instance a script to build OpenEXR 2.1 (especially since most packages are using CMake). Gordon: trying to move distribution of some open source components to separate distributions (for instance Maya USD).

    • Kimball: CI WG has a couple of build solutions, and there’s Sony spk, this may be part of the solution. Michael Min: is there a “reference platform” for color / accuracy, different compilers can result in different mathematical results in renderer / color management libraries. Is there a consideration to the image fidelity of changes to VFX Platform projects? Nick: definitely not the primary focus, but we still see some of these issues today around details of floating point math. Kimball: when starting to substitute Clang for gcc, ran a suite of visual comparisons to make sure there weren’t issues. Michael: that’s an example from a large studio, so could be useful to present some general guidance. Kimball: a reason to have a compiler on the spec. Ken: responsibility of individual projects to have these regression testing. Changes are sometimes desired, sometimes not. Have to be an expert on the project to know if this is intentional or not. Gordon: OCIO has invested in testing, especially since changing the engine. Larry: all projects should be individually addressing and should not only include “CentOS 7 + gcc specified by VFX Platform” in their CI build suite. Just testing against VFX Platform releases is not sufficient. Kimball: OpenEXR has to be good about CVEs since it is now included in some OSes, which demand it. Gordon: USD team is doing a great job in their responsiveness, but it’s still unclear which version a CVE is fixed in.

    • Francois: policy around cutoff dates: publication date is the cutoff date, can add a note about future expectations, but when publishing at SIGGRAPH, expect the software to be released. There is always some room for community process to update a release for the next year, but the official date is SIGGRAPH. Nick: Sept 1st is hard cutoff. Ken: SideFX has been pushing for new major version of OpenVDB every year. Have been pushing the deadline. Francois: SideFX is probably vendor most dependent on OpenVDB, they are represented on VFX Platform group.

    • Kimball: 3-4 year window for maintaining patches seems to be in general agreement, we probably need to discuss this more formally.

    • We should do this more regularly. Nick: happy to be there, can bring other members of the VFX Platform WG.

  • Project / WG Updates (hopefully with discussion about what should be in VFX platform 22, any issues, etc)

    • Python 3 WG: Ashley: no updates

    • OpenVDB / Ken: not a lot to update since last meeting, released 8.1, minor release with a long changelog, but not a “key feature” to call out. Deprecated support for version 5, only support 2 previous versions mentioned on VFX Platform. Planning a major release, version 9, probably won’t make it for SIGGRAPH but before end of the year. Will include NanoVDB. NanoVDB was branched off an old version of OpenVBD, this will be updated this week, but not yet ready to merge into main branch. Have had discussions with VFX Platform, agreed that “we are all confused about the policy”, last TAC SIGGRAPH was mentioned, but the policy is not written anywhere? Kimball: that’s part of the purpose of the discussion with Francois / Nick today. Maybe have more formal meeting around SIGGRAPH timeframe to discuss this? Ken: believe that version 9 should be stable enough for VFX Platform 2022. Unwritten policy to try to do one major release per year. Nick representing DNEG is transferring to WETA, will continue to represent on TSC, grooming someone else to represent DNEG on TSC. Should we have a global ASWF policy about project version support policy, or stick with per-project policy?

    • OSL: Chris. No major updates since last time. For Open Source Days will do a joint update with MaterialX. Kimball: we should make sure Jonathan from MaterialX is invited to TAC meetings. OSL not part of VFX Platform for now.

    • Rust / Scott: still working on onboarding process, need to talk with OpenEXR project, gathering questions Rust WG wants to ask OpenEXR. Should be doing presentation at DigiPro, not a Open Source Days (not enough bandwidth for both events).

    • OpenEXR / Kimball: merged C bindings, in soft freeze. I/O optimizations. Would love to get statistics feedback for texturing applications in renderers. Does that have impact on Rust bindings? Major new feature in OpenEXR 3.1, no changes to C++ backend. Expect release in time for SIGGRAPH, and would like that to be target for VFX Platform 2022. Francois: ongoing industry discussions about camera metadata, perhaps via OpenEXR metadata, or OTIO. Camera metadata coming from camera manufacturers, as well as additional on set metadata. Conversations happening in ASC / MovieLabs / VES Tech Committee / … Kimball: Joseph has been working on a standard definition language, could just be comments in the standard header files and the documentation. Was trying to put it in as next round of ACES standard container spec, but may not be happening anymore. Not sure if it will end up in 3.1

    • USD WG / Cory: adoption round table at last session, as well as ongoing camera work. Michael Min: lot of movement in various project group around camera metadata. USD WG had round table discussion and some presentations, including Gordon at Autodesk about what is being done with USD, as well as various new studios. There was a recording, hopefully available. USD / CG Camera: activity on a number of fronts, trying to create continuity between on-set camera all the way through the pipeline. Involved in trying to get this metadata through various barriers through CG pipeline, and transferring into a CG camera. Get practical camera data through conform, ingest, into CG production, make it shareable. Information from onset cameras (spoken to all camera manufacturers, they are all enthusiastic). Getting 150Hz gyro data, richer data set than just 24FPS, get exposure to original, rich data set to get better motion blur for instance. Exposure to richer landscape of data, driving lots of conversations. Joshua: OTIO is very interested, questions about the right place to put the data, especially for data at different rate than the frame rate of the video, which may imply it doesn’t belong in the image data frames.

    • OTIO / Joshua: trying to “stay off the list” of VFX Platform for now, would be good to have a clearly written “policy” of what belongs in VFX Platform and why. Have policy to support back versions of OTIO (currently back to 2016). Asked about dropping Python 2.7 support in annual survey, answer was yes. Would like to be able to drop it in a newer version. Have a couple of speakers only for OTIO at Open Source Days, so interested in additional presenters about use cases.

    • OpenCue / Brian: working on updating scheduler, as well as Open Source Days talk

    • OpenColorIO / Carol: will release 2.0.2 with some patches before SIGGRAPH, 2.1 for VFX Platform by end of August. PRs for these features are under review. ACES 1.3 gamut compression, and new set of OpenFX plugins are main new features in 2.1, more cleanups, CMake, Python Wheels fixes. Looking good for end of August release. Working on Open Source Days presentation and SIGGRAPH course.

    • D&I / Carol: D&I accepted candidates (20) are now on Slack, they start their Gnomon workshop of choice next week. Mentor volunteers should hear back next week. Will be doing a couple of events over the summer to connect with ASWF members (coffee / mixer). Got more people interested in programming / scripting / TD aspect than expected, will try to pair with mentors accordingly.

    • Asset WG / Wave: getting very close to legal agreement. Fruitful conversation with ASC who are doing StEM 2.0 (test / evaluation footage), they have funding and initial hosting home in Azure, but there is interest in putting that in ASWF if we offer a repo. Gave them the legal agreement, they are interested in the same issues, Creative Commons license was original idea, but non commercial clause makes that tricky. Eric: rumblings of contributions soon to come from Amazon, they have made a short film and looking at release some assets. Similarly Animal Logic, Intel has some VDB cloud data (what resolution do we want?). Cloud assets have a clear application to a specific project where they are applicable. For general 3D scenes, we don’t have a general process for acceptance, how do we judge if something is “film complexity / quality”. Hope to have this problem soon. Wave: people involved with projects are encouraged to go to page to specify what type of assets a project would be interested in.

  • OpenSourceDays updates

    • Still working on confirming speaker slots

    • John: final schedule should be posted online next day or two

    • Ken: some emails went out today

  • Slack upgrade

    • Governing board has approved expenditure, will no longer lose Slack history