ASWF TAC Meeting - September 08, 2021

Video Conference Link

Voting member attendance

Other Attendees

Andrew Grimberg, LF Release Engineering
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Carol Payne, Netflix / D&I WG
Rachel Rose, ILM / D&I WG
Sergio Rojas, Arena World
Scott Wilson, Rust WG
Matthew Low, DWA
Nick Porcino, Pixar
Robin Rowe, UN WHO
Eskil Steenberg, HxA
Mitch Prater, Laika
Shannon Deoul, RazPR (PR for ASWF)
Deke Kincaid, Digital Domain

Apologies

Sean Looper, Amazon Web Services
Cory Ormand, The Walt Disney Studios

Agenda

Hi to Shannon Deoul, working at PR agency RazPR, have been working with ASWF for almost a year, taking over PR duties in the interim for Rachel, new #public-relations Slack channel, can post announcement worthy updates to that channel, based in LA, can email at shannon@razpr.com
Project / WG updates - especially: are we good with cross-project syncing (i.e. VDB + EXR) for VFX’22
- OpenEXR (Cary)
  - First attempt at supporting OpenEXR / imath 3.1 to OpenVDB, misses some stuff but can be used as a basis. All projects need to support multiple versions, which can be challenging. OpenEXR would like to help in any way possible, but hitting limits of knowledge of how OpenVDB is built. But want to help move the process forward. Kimball is raising the issue since we don’t want to miss the window of opportunity to get OpenVDB 9 in VFX Platform 2022 with OpenEXR 3.1
  - Ken: have you heard any response yet? Cary: there was some discussion on the PR about things that the PR doesn’t address. But should mostly just be taken as a indication of how to do this. Ken: wasn’t able to take part in TSC meeting yesterday, but will loop back with other members, should be a good starting point. In previous version of OpenVDB, was shipping independent / bundled version of ilmmath, do we still want to do this? Trying to eliminate as many dependencies as possible from the library, was able to do that with older version of OpenEXR by just copying half.h, used to have dependencies on many parts of OpenEXR, but only part that was part of the core was half, other dependencies was just for command line tools.
  - Kimball: in 3.1 there’s a header only implementation of half. Ken: so in principle could just include this header file as part of the repo to avoid having to build ilmmath as part of the dependency? Larry: is it internal to repo, or part of public API? Ken: right now it is internal, but thinking about making it public. Use it to write sparse grids to disk with compression, and decompress to full precision on read back. But clients want half float grid type at runtime, so will have to go into the API.
  - Kimball: probably best to have your own type then. We pulled out iMath to allow more people to use it without having to pull all of OpenEXR. But imath introduces ABI with a versioned namespace, so changes its namespace between releases (unless you use the C layer), but the C++ classes are namespaced. This is under discussion inside the group.
  - Nick: might make sense for OpenVDB to have its own type, make a note that it is IEEE half type compatible, as well as imath. But no real reason to have an exposed dependency / copied header? Ken: may have to do this now that it will be part of the of the public API.
- OpenVDB (Ken)
  - Still discussion of nanoVDB adoption, lots of experimentation with compile time template instantiation, trying to coordinate with OpenEXR to learn from experience there. Prototype is looking promising. Concern is to be able to still support custom voxel and tree types, how to balance the requirements, template instantiation of most of what OpenVDB uses, but still allow customization. Still trying to get this into OpenVDB 9. Still on track to release v9 by end of October to make VFX Platform deadline, including imath discussion.
- MaterialX (Jonathan)
  - Charter approved by Disney, so should be able to vote on that
  - Looking at upgrading to pybind11, which will allow Python 3.9 (for now limited to Python 3.8)
  - New release with shader translations and color space improvements.
  - Apple proposal for HTML element tag called “model”, designed to support 3D models in any browser without any additional support than what the browser supports natively, uses USDZ for geometry and MaterialX for shading. May affect choices we make for ASWF assets.
- OSL (Chris)
  - TSC meeting last week: good discussion with OCIO and their support for OSL, led to discussion about texture calls, will be handled by OCIO, but not clear where exactly that goes. Also some debate between people in large studios with rigid color pipelines with pre-prepared files, vs smaller studios and packaged apps that use JPGs, still figuring out best place for color management.
  - Larry working on input/output placement API for OSL, alternate ways to get data in and out of the shader, if you know your memory layout, can be compiled natively to avoid queries and get better performance. Extended eventually to shader globals, so won’t have to rely on struct layout in OSL API.
- OCIO (Michael)
  - Released 2.1 and 2.0.2, last day of August, so good to go for VFX Ref Platform 2022. Supports imath 3.1, OSL shader emitting code (still WIP / beta feature, but usable).
- OTIO (Josh)
  - Approval for TSC charter, one or two questions still to be resolved. One core TSC member out for 2 weeks, but should be able to vote on it soon.
  - Had productive meeting with Autodesk about proposed schema enhancements about image bounds, placement and layout in the timeline.
  - Open questions about VFX Platform, can we drop older versions? Claim to support back to 2016, but does that still work?
  - Nick: hoping that reading of VFX Platform of “current + 3 past years” means we can concentrate on C++ 14, against the available CI
  - Nick: have a substantial incoming PR from Autodesk, hierarchy of 2D transforms and objects representable in OTIO, decided to take towards using iMath instead of internal math library. Some discussion about what it means to integrate imath, may require new functionality from imath.
- Assets (Eric)
  - TSC meeting last week, formed TSC, Eric elected project chair, adopted the charter.
  - Presentation from Animal Logic on the ALab asset.
  - Other assets in the queue for consideration, sign up to come present to the group. Make the group familiar with the asset, what are your plans for it, how does it represent “film complexity”.
  - Next week, will vote on whether to accept Alab to next stage (“in progress” stage, still defining those).
  - Kimball: some discussion on the next ASC StEM?
- USD WG Update (Cory, via email)
  - We discussed last week about changing up leadership of the group going forward. Alexander Schwank (Apple) will take over the primary chair role, with Michael Min (Netflix) and Nick Porcino (Pixar) acting as co-chairs, helping to wrangle meeting logistics, allowing for vacation outages without cancellations, etc. The group seemed happy with this direction. I am meeting with these folks later this week to work out initial logistic for the next regularly scheduled meeting next week. I will definitely continue to attend, both in support of the group leadership and as a community participant.
  - There was some conversation about whether the USDWG fits the definition of a ASWF “Working Group” – I mentioned this briefly at the last TAC meeting. It would be great to get some guidance as to how groups of this kind fit into the organization. How do the longer-term goals/deliverables of the USDWG compare to other long-term working groups like D&I with regard to the definition of a “Working Group”. Is this more of a “User Group”?
  - We also had a brief discussion spurred by Autodesk around USD/Material X integration, gathering interest for break-out sessions.
- Rust WG (Scott)
  - OpenEXR bindings on crates.io, people have started to play around with that. Next meeting on Friday, how do we want to announce the project officially.
  - Looking into handing over the bindings to the OpenEXR project, need to have a discussion as to how that works, what are the requirements on both sides.
- D&I (Carol)
  - Just had monthly meeting: updated the group on recent discussions with the board, internal focus on D&I for the ASWF organization.
  - Finishing up summer learning program, end of September. Mentors should have received emails with survey.
  - Rachel: talked about some more initiatives; blog posts, ambassador program which has been discussed in the past, will become primary focus for the group.
- CI (JF)
  - Updated Docker container 2022 platform has been released, used by OCIO
Continue discussion we abruptly ended last time around Eskil’s HxA project to wrap that up
- HxA is a on-disk and in-memory format, most existing formats are very complicated, HxA is meant to be simple. Has turned out to be a boon for personal projects. If it is going to be interoperable and used by others, it needs a home, and ASWF could be such a home. “A file format you can implement in an hour”.
- See description from 2021-08-25 TAC meeting notes, also see YouTube video presentation.
- Needs an actual specification, currently it’s mostly code, could use help with that (hxa.h mostly self documenting).
- Larry: no “industry risk” with a simple format if the project goes away. But why not just make it an open source project and promoting it as opposed to a foundation project? Eskil: it’s already Open Source, for it to be really good, need conventions for various use cases, and have to think hard about those use cases. Having people who can figure out details of how to store particular kinds of data, that would be valuable to have from a group like ASWF TAC.
- Nick: do you have support for time varying data, or strictly a sample in time? Eskil: can have infinite layers, so for instance for geometry can have blend shapes, or sequence of baked out animation. Can also store weights and animation data for rigging. Can also use tags to store bones system. Not sure how much of that want to define. But need a convention of how we want to store that. Don’t have convention for a flip book style geometry, but could just “do it”, put as many layers as you want and use those as frames. Nick: have a FBX converter on the GitHub site, so getting blend shapes and animation clips for animation from a FBX asset is always a stumbling block, for instance for USD migration. Eskil: agree, but there are so many use cases for storing geometry and images, you can find an expert on “skeleton animation” for instance, and have them figure out how to store that information. Hopefully we can have a simple format to get data in/out, and separately semantic understandings defined by experts. Ken: when you have parity / overlap with existing formats (say Alembic), have you done benchmarks? Eskil: HxA is probably slower, will often require fancy compression, “smaller is better”, but if you have to read a 500 page document to read a file… OpenEXR has lots of compressions, and if you need that, you might use the OpenEXR implementation to turn image into HxA file, and then use HxA to load into a quick hack, save to HxA and then back to advanced compression supported by OpenEXR. But that way you don’t have to parse OpenEXR. In terms of performance, “it’s fast because it’s simple”, but it’s not the most efficient way. For instance if you have animated geometry but where some data doesn’t change at every frame, that becomes complicated, and is great if you are intending to have a single implementation. OpenEXR can be complicated since it’s the definitive implementation. But ACES is supposed to be reimplemented many times, sometimes inside the camera, so simplicity is key. Usually hardware is fast enough to deal with large datasets, even if we have large scenes, we can do these in parts. Making conversions easy makes it easier to share pipeline steps, and avoid large dependency graphs of “big systems”.
- Joshua: older systems have a lot of these attributes: EDLs, OBJ. Lasting a long time is very useful for archival purposes. Need the proper balance between “too simple” and “too complicated”.
- Big question right now is whether adding half float is needed or not.
- Kimball: how does it compare to GTO from Tweak Software? Eskil: looked at a bunch of formats, they seemed to all have a couple of problems. Too big, and a lot are only for delivery, like GLTF: all vertices are baked down, and discusses how to render. But maybe you want to load ML data into a GPU, could be completely different use case. There is already an Odin implementation from JengaFX, want to store 3D textures in 3D space. Nick: ILM / Lucasarts used GTO for a number of years, but ran into issues with time series, which led to Alembic format.
- Nick: The lucas-patch can be applied on top of the ILM patches at git object f53fbb07f69a217a38da38250b5fadf81063eea7. The patch creates a new variant of GTO with a smaller header and some other changes to optimize its size. It’s unclear if applying this patch could be useful to anyone outside its original context.
- Eskil: talked to Alembic team, they are working on documenting it, hoping to write Alembic implementation for HxA.
- Joshua: if ASWF had existed when GTO was having issues, do you think that would have gone in another direction? Nick: yes, GTO got snagged on the fact that it was a proprietary format that was shared, but what would be the future direction, and would any local changes ever be supported. The “sharing mindset” didn’t exist back then. Joshua: GTO was “in use”, but there was a support problem, whereas HxA is brand new and looking for implementation. Nick: GTO hit the sweet spot for a game developer, had nothing fancy.
- Kimball: some people should go away and take a closer look. Eskil: will also share email if anyone wants to reach out directly. Kimball: whatever ends up being the final decision, we want to support new project proposals.
- Kimball: action item to look at how it fits in the mission of ASWF, don’t want to cause confusion with existing formats, even if we like and appreciate the goal of simplicity. Eric: would be good to have committee guidance about the definition of software layers. The “termcap problem”: very flexible metadata formats can’t be consistently read by different software (if at all). Larry: any project can assemble its own TSC, even outside the scope of ASWF. Projects can incubate somewhere else, emulating ASWF project structures. ASWF TAC is definitely the right place to pitch the need for such a project.
Related, revive discussion around software / project / working group lifecycle and review
- Want to do yearly reviews for projects and WGs
- Will probably start next time by wrapping up the Python 3 WG, then move on to other projects / WGs.
- Robin: is there time to propose new project?
  - Not sure where it should go?
  - WHO has a project to create 10K models for an open source medical library: human body, medical equipment, hospitals… WHO is an NGO so it can be open sourced, have budget, but need to find 3D modellers, is there an umbrella organization that could be over that?
  - Kimball: we would need to think about that, it’s not clearly under the mandate of ASWF, can you write up a proposal so we can think about this?