Yet another reminder that technology, even fast technology, can move slowly.

Siggraph has become an important gathering point for the open-source community. Many of the developers creating tools for digital content creation are working at studios serving the movie industry or at companies working with the studios. Naturally then, Siggraph is the site for the Academy Software Foundation (ASWF) meetings to provide updates on the organization’s work over the year. The ASWF was founded in 2018 by the Academy of Motion Pictures Arts & Sciences to further the development of open software that’s developed primarily for the motion picture industry.

This year, the organization announced major updates for its first accepted projects, OpenVDB and OpenColor IO and both updates spotlighted the need to add and enhance GPU support as a major motivation for development.

OpenVDB spawns NanoVDB for GPU acceleration

OpenVDB is one of the first open-source tools to be accepted into the Academy portfolio. It was first used by Dreamworks to create water, fire, smoke, clouds, and other effects.

The more complete definition for OpenVDB is: an industry-standard C++ library with a novel hierarchical data structure and a suite of tools for the efficient storage and manipulation of sparse volumetric data discretized on three-dimensional grids.

The technology was developed at Dreamworks by a team led by Ken Museth. Its early showcase was in several Dreamworks films including Rise of the Guardians, and Puss in Boots, and was open-sourced in 2012. For more detail, Museth has published a paper on OpenVDB.

It is now widely supported in DCC products from Autodesk, Blender, Foundry, SideFX, Pixar, and all the major renderers including Arnold, Chaos Group, Clarisse iFX, Redshift, Guerrilla Render, Maxwell Render, etc. So, if you’ve admired any lava flows, and animated clouds, raging fires, and explosions, OpenVDB was probably used in their creation for its ability to manage file sizes and speed processing.

Enter the GPU

Ken Museth has since gone to Nvidia where he is Senior Director in Simulation Technology and has been able to pursue his interest in putting GPUs to work on OpenVDB; the resulting NanoVDB was announced at Siggraph 2020 during the Academy’s Open Source Days.

NanoVDB is a simplified representation that is compatible with the core data structure of OpenVDB. Information can be converted to and from NanoVDB and OpenVDB data structures. Nvidia has a more detailed explanation and mini-tutorial on its site.

In addition to making use of GPUs, a major motivation for the team’s work on NanoVDB is to enable realtime rendering, but even though this effort was led by an Nvidia-based team, they were working within the ASWF’s OpenVDB project and NanoVDB is resolutely open. It works with different graphics APIs including CUDA, OptiX, OpenCLB, OpenGL, and DirectX. (More accurately, though, OpenGL and DirectX are on the way.)

NanoVDB has been adopted into the Academy’s OpenVDB project and can enable GPU acceleration of OpenVDB workflows including ray tracing, filtering, and collision detection. NanoVDB is compatible with the core OpenVDB data structure and existing pipelines. It supports both point data and voxels.

The ASWF says NanoVDB will enable faster performance, easier development, and GPU acceleration.

New OpenColorIO (OCIO) adds performance, more ACES, and support for GPUs

OpenColorIO was developed by Sony Imageworks in 2003 and was introduced to the public in 2010. It was developed for post-production color pipelines in visual effects and animation to enable consistent color transforms and image display across different graphics applications and to ensure a consistent user experience across supporting applications. It also allows back-end configuration options for advanced production use because the ability to customize color is an absolute industry requirement. The idea is that there is the freedom to define the color system but then make it easy for artists to apply.

OpenColorIO is compatible with ACES (Academy Color Encoding Specification) and is LUT-format agnostic. Basically, OpenColorIO ensures the consistency of color across applications, which is not at all as simple as it sounds.

OCIO won an Academy Sci-Tech for its original developer Jeremy Selan and was accepted into the protective arms of the ASWF in 2019. The development of OSIO v2 has been a long ongoing project and it was unveiled at the ASWF’s Open Source Days at Siggraph 2020.

This is a significant update to the project and according to a paper by Doug Walker of Autodesk, Michael Dolan of Epic Games, and Patrick Hodoul of Autodesk, who say it represents over 10 “developer years of engineering effort.”

During their presentation introducing OCIO v2, Doug Walker and Patrick Hodoul said the development of OCIO v2 was a response to the changes in the VFX that have taken place in 10 years since its introduction.

The primary motivations for the new work were the increasing use of GPU, especially for rendering final pixels, changes, and advances within ACES and the increasing complexity of color management. The developers wanted to improve the user experience for artists. And, as a strong indicator of technology shifts, the increasing interest in OCIO for adjacent industries, which are concerned with color management including renderers, game engines, and design software.

ACES is central to OpenColorIO project, but it adds a significant level of complexity. For example, the ACES OCIO config has over 300 color spaces and the arrival of HDR television is going to up the ante.

Through the work on OCIO v2, the working group strove to ensure the existing OCIO configs would continue to work and that it would be simple for clients of existing APIs to update.

The new features include:

Improved rendering: The group has replaced the former OCIO GPU renderer so that it processes pixels in the same way as the CPU does. In addition, the CPU renderer has also been enhanced. The developers say that due to their enhancements, the renderers can be 20× faster for some common cases.

Improved user experience: New tools have been developed to enable config authors to organize color spaces, create hierarchical menus, and also hide color spaces most artists won’t need. New file and view rules have been developed for config authors to make it easier for them to specify default behaviors.

Improved ACES support: The developers of OCIO v2 have improved the OCIO config for ACES to better and more efficiently support ACES workflows. In addition, the ACES has developed an industry-standard color transform (LUT) format, Now, OCIO v2 supports the ACES common LUT format (CLF).

Analysis tools: OCIO v2 now has new command-line tools for evaluating LUTs, converting to CLF, serializing OCIO processors, and more.

Too many words about display color spaces

The OCIO v2 project also tackled the issue of display color spaces, which has always been tricky but with the arrival of wide-gamut displays and HDR TVs is even more complicated. OCIO v1 sidestepped the issue by mostly concerning itself with “scene-referred encoding,” which stays within the realm of the content creation pipeline. But as OCIO strives to be relevant beyond the movie industry and be useful for any professional who needs to deal with color management, it had to come to grips with display-referred encoding and create a bridge between the two worlds. OCIO v2 has added new components that will better align OCIO with current standards for color management and displays:

• The addition of a display-referred reference space
• A new section of the config for display color spaces
• A new section of the config for view transforms
• The ability to define a display/view as a view transform plus a display color space rather than as a single monolithic color space

More for GPUs

The ASWF has got plenty more cooking, but these two initiatives stood out for a couple of obvious reasons. The expand the worlds where GPUs get to play and they better allow the CPUs and GPUs do what they do best and in some cases allows for more interoperation between them. This has always been a desire for customers who are not really interested in the intricacies of microprocessor operations but who’d really like to see their software getting all the advantages advanced microprocessor design has to offer.

What do we think?

Lesson number 1 for vendors from the Open Source: let the customers tell you what they need. Better yet, let them build it for you and then you can integrate it in your programs, create better user interfaces, and accelerate it in your hardware.

Seems obvious, but this is a pretty new phenomenon. Steve Jobs said, “some people say give the customers what they want, but that’s not my approach. Our job is to figure out what they’re going to want before they do. I think Henry Ford once said, ‘If I’d ask customers what they wanted, they would’ve told me a faster horse.’ People don’t know what they want until you show it to them. That’s why I never rely on market research. Our task is to read things that are not yet on the page.”

God, I miss that guy. It’s so nice having people tell us what we don’t know. In this industry, customers are creating the future, and they’d appreciate a little help.

Open source organizations are accelerating that work and as it progresses developers are learning how better to encourage growth but also harness and maintain the beanstalk vines of creativity.

In fact, maybe Jobs was becoming a man out of his time because digitalization is turning the customers into the creators and the tool makers. Perhaps if he had gotten the chance, he would have problem led the charge, but if not; if protecting turf was what he really cared about, he would not be alone.

The ASWF Open Source days, as always were exciting—if a teeny bit of a strain on the brain. If you want to know more do be sure and read the papers mentioned in this article. They’re well written and accessible.