ASWF TAC Meeting - 12 July, 2023

Video Conference Link

Voting member attendance

Premier member representatives

  • Bill Roberts - Adobe Inc.
  • Brian Cipriano - Google LLC / OpenCue
  • Cory Omand - The Walt Disney Studios
  • Eric Enderton - NVIDIA / DPEL
  • Eric Reinecke - Netflix
  • Esteban Papp - Amazon Web Services
  • Gordon Bradley - Autodesk
  • Greg Denton - Microsoft
  • Jean-Michel Dignard - Epic Games, Inc
  • Kimball Thurston - Weta Digital Ltd / Chairperson / raw2aces
  • Larry Gritz - Sony Pictures Imageworks
  • Mark Visser - Unity Technologies
  • Matthew Low - DreamWorks Animation
  • Michael B. Johnson - Apple Inc
  • Roy C Anthony - DNEG
  • Sean C McDuffee - Intel Corporation
  • Sean O’Connell - Advanced Micro Devices (AMD)

Project representatives

  • Carol Payne - OpenColorIO
  • Cary Phillips - OpenEXR
  • Chris Kulla - Open Shading Language
  • Jonathan Stone - MaterialX Representative
  • Joshua Minor - OpenTimelineIO
  • Ken Museth - OpenVDB

Industry representatives

  • Jean-Francois Panisset - Visual Effects Society

Other Attendees

  • John Mertic, LF
  • Yarille Kilborn, LF
  • JT Nelson, Pasadena Open Source consortium / SoCal Blender group
  • Doug Walker, Autodesk
  • Robin Rowe, Cinepaint
  • Lee Kerley, Sony Imageworks
  • Stephen Mackenzie, NVIDIA
  • Laura Reznikov, Intel
  • Jean-Christophe Morin, Rez
  • Nick Porcino, Pixar
  • Danny Greenstein, Sony Imageworks
  • Tom Cowland, OpenAssetIO
  • Nathan Walster, Framestore
  • Lorna Dannielle Dumba, Framestore
  • Manne Ohrstrom, Framestore
  • Joseph Goldstone, ARRI
  • Alexander Schwank, Apple
  • Josh Bainbridge, Framestore
  • Daniel Heckenberg, Netflix

Apologies

  • Joshua Minor
  • Michael B Johnson (late)

Agenda

  • Updates
    • Close out https://github.com/AcademySoftwareFoundation/tac/pull/417
    • New #accessibility Slack channel from work in USD WG (Alexander Schwank)
      • In June brought up accessibility as a topic in USD WG, we are passionate about that at Apple, and so are others. Want to make USD as a format and as a technology more accessible, make tools accessible, store accessibility data. We want to help with what we carry in USD files. Had chat with other people in ASWF, they were excited about this. So instead of just launching a small sub USD group, decided to create ASWF-wide channel for #accessibility to raise awareness and help all projects be more accessible. There are small things we can do to make tools and software more accessible, but there could be efforts across our projects, use the same metadata to store accessibility information. We want to push for this, not sure where it’s heading, if it will be an actual WG like D&I, still figuring it out, but first step is to raise awareness for the topic, gather the people interested, and take it from there. We will try to write a blog post about this to raise external awareness as well.
      • Kimball: keen to hear more about this, thank you!
      • Alexander: anyone can join the channel, any feedback / thoughts, please join and post.
  • OpenAssetIO Project Review
  • OpenQMC Proposal

Notes

  • Close out https://github.com/AcademySoftwareFoundation/tac/pull/417 (John)
    • Any last minute changes before we merge the PR? Guess not, will merge it.
  • New #accessibility Slack channel from work in USD WG (Alexander Schwank)
    • In June brought up accessibility as a topic in USD WG, we are passionate about that at Apple, and so are others. Want to make USD as a format and as a technology more accessible, make tools accessible, store accessibility data. We want to help with what we carry in USD files. Had chat with other people in ASWF, they were excited about this. So instead of just launching a small sub USD group, decided to create ASWF-wide channel for #accessibility to raise awareness and help all projects be more accessible. There are small things we can do to make tools and software more accessible, but there could be efforts across our projects, use the same metadata to store accessibility information. We want to push for this, not sure where it’s heading, if it will be an actual WG like D&I, still figuring it out, but first step is to raise awareness for the topic, gather the people interested, and take it from there. We will try to write a blog post about this to raise external awareness as well.
    • Kimball: keen to hear more about this, thank you!
    • Alexander: anyone can join the channel, any feedback / thoughts, please join and post.
  • OpenAssistIO Project Review (Tom Cowland)
    • OpenAssetIO ASWF TAC Review 2023 Slides
    • A lot has happened in a year! Wanted to thank everyone for creating a space where a project can start in the open, have open conversations on Slack, first Sandbox project, and I advocate this.
    • An interoperability standard for the tools and content management systems used in media production.
    • TSC Chairperson: Town Cowland tom@foundry.com
    • TSC Members and Affiliations
    • Incubation Project review criteria
      • To be accepted at the Incubation stage, a project must meet the sandbox requirements plus:
      • Have gotten through a lot of the code quality requirements.
      • Community and contributor growth assessment
        • Todo: outline of the plan for the project to complete the requirements for Adopted Stage
      • Obtain an affirmative vote of the TAC
        • Proposing that we stay in the sandbox stage for a little while, we’re still in alpha, will be hitting beta around SIGGRAPH
        • Don’t have diversity of contributors yet
      • Contributions
        • 821 Commits
        • 160 issues resolved
        • 3 core contributors (Foundry)
        • 6 additional casual contributions from 3 orgs
          • Mostly documentation tweaks
          • We value all contributions
          • Hoping to put specific production examples and use cases
    • Organizations contributing and/or using in production
      • Foundry
      • MovieLabs
      • Ynput (OpenPipe)
      • OpenTimelineIO
      • Open Review Initiative
    • Key achievements in the past year
      • Added a new full time contributor
      • Migration to batch-first, traits based API
        • Only possible thanks to community input
      • Integrations (PoC / alpha)
        • OTIO Media Linker
        • OpenRV
        • USD Ar2 plugin
        • Foundry Nuke / Katana AssetAPI plugin
        • MovieLabs Sandbox Resolver
        • Ayon
        • MaxR EU XR Research Project
        • Each project highlighted things we hadn’t thought about before
        • Mix of open source and proprietary
        • We are very early in the adoption curve, people need “vision” to see where we are going with this
    • Areas the project could use help on
      • Anyone with spare time and C++/Python (g)RPC knowledge
      • Defining common types of asset (high level)
      • Build, CI, release tasks/tooling, documentation, examples
      • UI for Asset Management / Production Tracking
        • Technologies / strategies / integration challenges
      • Modern web engines vs DCC tools
        • Portability
        • Trying to get a modern web browser in an app is not easy
        • Fast update cycles, security concerns
        • 2-3 delay before new versions get picked up in production
      • Avoid “the menu in the corner” artists need to use for common tasks
    • TAC Open Discussion
      • Thank you for the support on the project!
      • Kimball: anyone has questions?
      • JF: do we need a vote to renew sandbox status? Apparently we do.
      • JF: what do you see as your MVP? Tom: first beta around SIGGRAPH, happy that the core API is fit for purpose based on integrations done this year. So users don’t have to worry about multiple changes after that. So if they write a plugin for the pipeline or vendors for their DCC, it won’t change too much. Language bindings for C++ and Python, so people can start picking it up. What will be called a v1 will depend on that phase. So next 3-6 months is good opportunity to start using it in earnest.
      • Kimball: do you see a UI for browsing assets in scope or not? Or tools to configure infrastructure (gRPC servers). Tom: vision is to have a common API of how to put plugins inside a tool. “Don’t use File/Save”! When you use software in production, you have to unlearn a lot. File/Open or File/Save should be possible to bring up a custom browser, we don’t want to provide a common UI, more about how we delegate a UI.
      • Eric: could there be some kind of abstraction layer like FUSE for filesystems? Tom: we think of it as orthogonal concerns, this specific project has a non UI layer that takes an identifier and turns it into usable data, like Ar2 in USD. Also some query layers. Specific case of File access, take UNC reference into URL, that’s the handoff to other systems. Trying to borrow what’s in OIIO for URL schemes. But don’t need to adopt the whole vertical stack. There are lots of parts of the solution, but don’t necessarily need to take all of these on in an opinionated fashion. Eric: seems like a smart way to break up the problem.
      • Kimball: motion to continue OpenAssetIO as a sandbox project? Larry: I’ll make the motion. J Goldstone: I second. JF: unfortunately we don’t have quorum for voting members. Kimball: we will vote over email.
  • OpenQMC Project (framestore)
    • Josh Bainbridge: head of rendering technology team, conceived the project
    • Nathan
    • Lor
    • Why are we here?
      • Introducing the OpenQMC project from Framestore
      • Putting this forward as a candidate for ASWF adoption at sandbox phase
      • Providing the information needed for ASWF to make a call
    • Background
      • Original idea for open source from 2018 ACM TOG on rendering
        • A question to the panel: when talking about open source and production rendering, what is missing? That’s a hard question, there’s already OIIO for textures, OSL for shading, OpenVDB for volumes, Embree, Optix… but a sampling library is missing, and OpenQMC is that.
      • OpenQMC is park of Freak, Framestore’s production renderer
        • Using Freak in production for over 6 years
      • Considerable amount of experience in this area
        • Had been developing before Freak
        • OpenQMC is latest iteration of this
      • Could benefit projects similar to:
        • Blender Cycles
        • MoonRay
        • Good time to bring it to community
    • Problem Case
      • Reducing noise in production rendering is expensive
      • OpenQMC is one way of making this more efficient
      • Applies methods from Quasi Monte Carlo (QMC)
        • Being very careful about which points you use, not purely random, so more efficient
      • Critical component to physically based renderers
        • Nothing novel / new, everyone is doing this, but that’s the point. Want to collaborate on this and centralize work / effort.
    • Results
      • Less noise with a single sample per pixel when working interactively
      • Converge quicker
    • Overview
      • OpenQMC includes:
        • Library for sampling low discrepancy points
          • C++ with no dependencies
          • Built for CPU + GPU
        • API for integration into production graphics engines
          • There’s already a lot of academic papers with sample code, some are used in commercial products, but there isn’t a framework where you can plug sampling technologies that can integrate into higher level sampling system, in a way you can use everywhere, and be confident the results will be correct.
        • Tools and testing for development and analysis
      • There are 3 primary aims:
        • Standardize a flexible sampler API
        • Deliver performant implementation
        • Provide high quality results
          • Implement latest papers
      • Non goals
        • Implement an exhaustive list of techniques
          • Allow users to pick the right solution for their problems
        • Provide educational implementations
          • Prioritize performance and quality
    • Summary
      • C++ library for graphics engines
      • Reduces noise and optimizes performance
      • A universal problem. No current standard solution
    • ASWF Sandbox Motivation
      • Framestore recently became an ASWF member
      • Common mission with ASWF:
        • Collaborate to build quality tools
        • Have an open forum for contribution
        • Provide governance for a standard solution
      • Benefit for the community
        • Provide a tested and high quality solution for point sampling
        • Document workflows for common use cases and integration
      • Project benefits from ASWF sandboxing
        • Provide exposure to a larger community to grow
        • Help steer the project to meet the community needs
        • Use the sandbox stage to allow for API breaking changes. What we have now works well for Framestore but may not work for others, so this is the time to find something that works for everybody.
    • Project alignment
      • Built from the beginning for open source
      • Based on the ASWF sample project
      • Issue tracking, meeting notes etc
      • Uses VFX Reference Platform
        • No library dependencies, but use the compiler
      • Contribution process
        • Apache License 2.0
        • DCO sign-off required
        • Digitallt signed commits
        • PRs and CI testing
    • Summary
      • Framestore are committed to contributing further improvements from production to this open initiative. We think the project’s mission to standardize such technology across our industry, together to collaborate and achieve ever greater tools for content creation, aligns with the goals of ASWF. We also believe that adoption of OpenQMC as an ASWF sandbox project to help us achieve this by bringing together in a single forum, and giving access and exposure to a larger community. Private repo, can ask for access: https://github.com/framestore/openqmc
    • Questions?
      • Ken: can you elaborate on API design philosophy? Josh: in previous iterations, we found it’s hard to determine where the points are distributed. You have specific systems for lights, volumes… You want points laid out in a way that doesn’t introduce bias. Hard to “keep in your head” when you have a large code base. We have a system based on domains for each problem, use hashing, only pay the compute cost when you ask for the samples. But statistically independent from other parts of the code base.
      • Ken: how do you support GPU with C++? Josh: we also use CUDA. This can all change, the ideas and design behind it are sound, but can iterate based on what other studios are using. Ken: we should talk, being able to embrace other graphics api through C99 is something we looked at in NanoVBD. Josh: we are interested in hearing about that.
      • Laura: would also be interested in having render kernel library team take a look at it, we could contribute for Intel support.
      • Larry: very interesting proposal. Can you share any documentation / what the API looks like so people can get an idea of how it’s used? Josh: yes, can create a PDF. Larry: that would be awesome to have our teams look at it. Josh: project comes with an example path tracer to show how it can be integrated.
      • Matthew: would look to forward to render team. Moonray could be potential opportunity, we don’t currently use QMC in our source, we did but had some issues, might have been an implementation detail. When we were using it, we found that a lot of techniques were patented by Mental Images, that got flagged (even though we were licensees). Not sure if this could be an issue? Are the techniques you are using fall under the patents? Josh: we have looked into it, some patents have expired, some have not. Would appreciate NVIDIA’s involvement to have a look at it. Our primary sampler we think is “safe”, but any input from other parties would be useful. Ken: happy to bring up internally at NVIDIA.
      • Wave: great presentation. Would love to get something I can pass on to GPU team at Apple, see how it could map to Metal. Also speaking as Blender foundation member, have you investigated that yet? Don’t know if it would be a straight forward fit. Josh: this is why we want to bring it as sandbox project so we can talk to them.
      • Chris: curious about analysis part of the project, what are you analyzing and how extensive is it? Josh: we have a standard battery of tests, make sure we aren’t introducing bias. Wrapped up in unit testing. Have a Python API that allows you to visualize a lot of the results. Also provide benchmarking, and want to grow and improve upon. Gives us a lot of confidence in the results. There’s also optimizers which we run offline, work on spatiotemporal blue noise. Outputs data that can be incorporated into the code.
      • Larry: who should we contact to access to GitHub repo? Lor: I can be point on that: lorna.dumba@framestore.com
      • Kimball: we don’t have quorum so we won’t be doing a vote today but will definitely follow up. That brings us to top of the hour, thank you and see you next time!