ASWF TAC Meeting - August 25, 2021

Video Conference Link

Voting member attendance

Other Attendees

John Mertic, Linux Foundation
Andrew Grimberg, LF Release Engineering
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Carol Payne, Netflix / D&I WG
Sergio Rojas, Arena World
Scott Wilson, Rust WG
Alex Meddick, Rising Sun Pictures
Matthew Low, DWA
Nick Porcino, Pixar
Eskil Steenberg
Robin Rowe, UN WHO
Eskil Steenberg, HxA

Apologies

Agenda

Project updates (are we all good for VFX Platform 2022?)
- Rust WG: Scott. Small slowdown after SIGGRAPH, Anders adding support for cppmm under Windows, getting to a point where can hand over OpenEXR bindings to the OpenEXR project, need to coordinate with them so they have everything they need to take over ownership of the bindings. Reddit /r/rust thread about ASWF Rust effort.
- MaterialX: Jonathan. Published first shared / public translation graph for MaterialX, others developed for proprietary use at studios. Lots of work getting close to wrapping up. Autodesk developing ESSL and EGL viewer. Setting up testing for that, making sure there’s a web page on GitHub Pages that can visualize materials. Khronos is developing GLTF BSDF, Adobe is developing MaterialX shading graph for their standard shading model.
- OSL: Chris: no major news since SIGGRAPH, CI builds track latest VFX Platform
- OpenVDB : Ken: committing to releasing version 9 before Nov 1st for VFX Platform, otherwise will revert to 8. NanoVDB in review. Independent viewer will not be part of this release due to too many dependencies. Started having conversations with Autodesk Bifrost team, they have adaptive grid structure they want to contribute to the project. Looking at common complaint is long compile times when building against OpenVDB, was used in keynote at cppcon. Use template instantiation heavily, looking at instantiating templates in library files without breaking backwards compatibility to help client-side compile time. Kimball: OpenEXR ran into issues with symbol visibility, happy to share.
- OCIO: Michael. Releasing 2.1 on Monday for VFX Platform, releasing 2.0.x bugfix release for current release. Have Python packages set up, can be used automatically with CI builds, will be able to pip install ocio. Sub WG is working on new ACES configs, including a studio config, “color pipeline in a box”. Working with camera vendors to supply CLF versions of their camera transforms to share burden of support with camera manufacturers. Previous ACES OCIO configs have been widely used, some have struggled to use them since they didn’t have explicit license, Thomas Mansencal has gotten approval from all contributors, so ACES 1.1 and 1.2 configs can move to main OCIO repo.
- D&I Carol: working on summer program, sending out swag soon. Rachel & Carol & Kimball had discussion with ASWF board for long range plans, how to affect diversity in the makeup of the board, alternates, term limits… ASWF board can be affected, view TAC as longer term goal. Larry: maybe the TAC is more amenable to substitutions since Board deals with money / legal issues, so often only one person in the company is allowed to deal with those issues? Would be great to see more diversity on the board, but there may not be someone to substitute? Carol: definitely not trying to “overturn” the whole board at once. Hopefully can start training someone else / avoid single point of failure. Kimball: we should grow the summer learning program into a mentoring program for instance.
- OTIO: Josh. Also trying to get Python wheels built, making good progress towards that, trying to connect to OCIO to learn from their experience. Will make a lot easier to install, and reduce support load (lots of questions about compilation / installation). OpenTimelineIO was awarded the 2021 Pipeline Tool Award from the Pipeline Conference, congratulations to all contributors. https://thepipelineconference.com/2021/07/30/the-8th-pipeline-awards-winners/ Also may have “unstuck” legal issues to handing over repo to ASWF, specific question about moving repos from PixarAnimationStudios, also have some aux repos under an OTIO organization. So looking at moving main repo into OTIO organization, since may be creating a bunch more repos, which may be faster than having to “ask for permission” every time. But want to ask for feedback. Andrew: paid-for CI builders will be tied to ASWF GitHub organization, also JFrog, Docker Hub. Jonathan: was thinking of doing the same thing under the MaterialX GitHub organization? Is this the best way to do this?
- OpenEXR: Cary. In good shape wrt VFX Platform, 3.1 release out for a while, barring any disasters, that’s what will be in VFX Platform 2022. Focus to continue hardening that release, especially the new C core, in advance of others adopting it. Rust bindings will also take some attention. Someone (Aras Pranckevičius, one of Unity’s founders), contributed a suggestion of changes to ZIP compression levels with claims of more advantageous tradeoffs between file size and CPU usage / compression time, as well as issues to investigate a variety of new compression algorithms. All good and exciting, but how do we evaluate this, would be good to have a good set of benchmark images, we have some reference images, but don’t have confidence that they are presentative of what studios are likely to encounter. Get reports of build / runtime failures on architectures we don’t have access to. Not really CI related, but wish CI could reach more representative set of architectures that OpenEXR is run on. Larry: for test images, the Animal Logic USD scene has a huge EXR texture collection, not all the use cases, but it’s a big one, and there’s lots of large texture files in there, could be interesting for compression benchmarks. Ken: when reached out to VFX Platform about intending to release v9 end of November, they pointed out desire to support OpenEXR 3.1, so would like some assistance. Kimball: shouldn’t be too much of an issue? Ken: added a standalone version of OpenEXR in 8.0 so people could optionally compile library (dependency on “half”), but that’s now an issue. Can be discussed offline. Kimball: should be possible to completely inline the new half library. Cary: definitely don’t want this to fail!
- Asset WG: Wave: officially transitioned from WG to project, skipped last meeting due to SIGGRAPH, next meeting will be starting up as a project, will need to organize infrastructure. Can start spinning up real asset repo and start accepting contributions. Animal Logic USD asset is using the license from the Asset WG, Apple was able to download and examine the asset since license was already approved. Now we can stop talking about boring legal stuff and concentrate on exciting aspects. Intel, Netflix are offering up assets for acceptance.
- Cory: USD: positive meetings at SIGGRAPH, meeting next week, USD Camera and Web Vis, shifting chairmanship to someone else in the group is being discussed. Would like to get a fresh perspective, raises the point of whether this is a WG, or more a user group / interest group. Do we have anything like that in the organization? Kimball: we need to review the WGs and projects periodically, we can discuss that at next TAC meeting.
- OpenCue: Brian: work on improving version support, now support up to Python 3.9, makes it easier to support 2022 VFX Reference Platform, Needed to upgrade dependencies, PySide and gRPC, had to support versions with published wheels that support Python 3.9, also helps with cross platform support and makes it easier to install. Doing work around connectors that were written between OpenCue and Prometheus / Grafana / Loki, posted tutorial on OpenCue web site on how to use and integrate this. Wanted to highlight ability to connect to other services in a typical pipeline, as well as goal of publishing more context around the new features in OpenCue as they are released, and made those highlights of the Open Source Days presentation.
WG updates
CI WG charter proposal: https://docs.google.com/document/d/1e-pPsNTKIgx3OwiQLhO8E5AuDVQyhtJJM6fVno8DnCE/edit
- JF proposes, Wave seconds. All ayes, no opposes or abstains, motion carries.
HxA proposal by Eskil (attached below)
- A simple file format for assets
- Why would we?
  - Maybe we are a student learning graphics
  - Learning DX / Vulkan / OpenGL
  - A game developer building a custom engine
- Options:
  - Alembic: dependency only, not specified
  - FBX: dependency only, not specific, not open, C++ bindings only
  - USD: implementation only, scenes not assets. Companion format?
  - Collada: huge, XML, delivery only, dead
  - GLTF: huge, JSON, delivery only
  - OBJ: ancient, text, limited but implementable
  - What can I implement in less than an hour?
- Load bitmaps is hard too:
  - JPEG, PNG: are hard to implement
  - TGA and few others are trivial to implement
  - For graphics / GPUs we need 1, 3D, cube textures, arbitrary number of layers and channels.
  - OpenEXR solves part of this but not all. OpenEXR is not really implementable (ACES is)
- HxA at its root is a number of nodes
  - Number of nodes and array of nodes
  - Metadata only, Image, Geometry nodes
  - A layer is an array of UINT8, INT32, Float, or double
  - Use sign bit of integer index to indicate when a primitive ends, FBX uses same convention.
  - Can have a UV layer, edge layer (for creases), material ID
  - Metadata is a simple, JSON-like structure. Each object has a name, a type (INT64, double, node ID, text string, binary blob, or another metadata object). Can store anything.
- The format is simple, and should be “implementable in less than an hour”. Format was implemented from scratch in Odin in 45 minutes. So can be thought of as an RFC, can implement yourself, or find an existing implementation that meets your needs.
- What about everything else you might want to store? Can add “conventions”. If you have a special use case (say a physical simulation), can define your own convention, that way can share the conventions.
- Does the world need another file format? Obligatory xkcd about standards
- HxA is meant to reduce the code you need to write. HxA is a file format, but also an in-memory representation. So when we write an application, can use an existing loader that loads into memory. What if you want to massage the data, like triangulate it. A utility can be implemented that takes a HxA file that triangulates and outputs a HxA file, same for manipulating image data. Some examples:
  - Generate normals
  - Triangulate
  - Convert Types
  - Split vertices for GPU
  - Close holes
  - Validate
  - UV unwrap (“Ministry of Flat” implementation in HxA)
- Can use existing tools to build a pipeline. What’s inside these utilities:
  - Load HxA file
  - In memory
  - Utility function -> HxA in memory
  - Saver
- Why use external tool instead of reusing the open source function to operate in memory HxA -> in memory HxA
- What if the data isn’t in HxA? Can use a file converter that reads some format into HxA, so can plug file converter into application. So not using HxA as a user, but more to connect various serious components:
  - PNG loader /saver
  - TGA loader / saver
  - OpenEXR ACES loader / saver
  - FBX
  - TrueType
  - All in C, zero dependencies, more is coming
- Drop-in open source, fostering open source and interoperability
- What about dynamic loading? HxA dynamically loaded code that can operate on data structures.
  - One plugin many DCC tools
  - Integrated with native UI
  - Scriptable
  - Can run in cloud
  - Possibility to build rich custom tools
  - Universal loaders and savers
  - Integrate existing code
- Not a monolithic project
- HxA could benefit from
  - More components
  - More domain specific conventions
  - Community of some sort
  - Application integration
  - Sample code / documentation
  - Does not need broad industry support to be useful (but would be nice)
- A version of the presentation is available on YouTube
- Would be interesting as an incubation stage project, ASWF could create structure around the project that can’t be done as an individual. Would like to support implementations for a lot of the ASWF projects, ACES implementation was highly desirable. Looking to interact with other projects. Still very early on, looking for feedback.
- Kimball: we need to think about how we create more tools for the industry, HxA could be an interesting framework for that. Larry: would be good to address directly what the organization would get out of having this project as a member and vice versa.

Project name: HXA

Maturity level

Incubation

Project description

HxA is a convention for storing graphics assets. HxA is both a file format and an in-memory representation for graphics assets that is so simple that it’s reasonable for a developer to implement in about one hour.

The goal is to make a graphics format that makes it easy to exchange assets, but also to exchange code by having a common data format. The format can store 3D meshes with arbitrary surface attributes, texture and meta data. In order to be as simple as possible it does not employ any compression, or complex encoding.

While the format describes the fundamental building blocks, it relies on user conventions to store domain specific data.

HxA is not a monolithic opensource project, but a collection of algorithms using the convention. Each algorithm is independent, so the user can choose to grab any parts they want or choose to write their own. Most of the code is in portable C, but the intention is to make it so easy to make HxA implementations in any language (An implementation in Odin has been made independently)

A partial list of existing HxA components available:

File Loaders and savers
Text print outs
Hole closing
Triangulation
GPU optimizer
Normal generation
Validator
PNG loader/saver (Scratch written)
FBX parser (Scratch written)
OpenEXR loader (Scratch written)
True type loader (Scratch written)

A further part the HxA project is the goal of writing a Universal Plugin interface that lets applications dynamically load code that operates on the HxA data structure. This would increase interoperability and enable applications to faster adopt new formats and workflows.

ASWF Alignment

HxA is a project designed to foster collaboration, interoperability and opensource in the graphics community. HxA could make use of the robust organization that ASWF can provide to solidify and create processes for adding new conventions. HxA can also be a used to test and verify existing ASWF projects like OpenEXR and OpenVDB

Source Repository

https://github.com/quelsolaar/HxA

External dependencies

None, all existing code is self-contained portable c89

Project members

Me. With support from Nick Porcino and the jangafx team.

Mailing list infrastructure

None

Issue tracking

None

Best practices badge

Possible for parts of the project. Since the project is not a monolithic project but a collection of contributions, each contribution should probably get its own badge.

Website

Currently the website is the github page but the best up-to-date information is found in hxa.h

None

Release cadence

When ever a new utility is added.

Trademarks

None.

ASWF TAC Meeting - August 25, 2021

Voting member attendance

Other Attendees

Apologies

Agenda

Project name: HXA

Maturity level

Project description

ASWF Alignment

Source Repository

External dependencies

Project members

Mailing list infrastructure

Issue tracking

Best practices badge

Website

Social media

Release cadence

Trademarks