Academy Software Foundation Technical Advisory Council (TAC) Meeting - February 18, 2026

Join the meeting at https://zoom-lfx.platform.linuxfoundation.org/meetings/aswf?view=list&projects=aswf

Voting Representative Attendees

Premier Member Representatives

Project Representatives

Carol Payne - Diversity & Inclusion Working Group Representative, OpenColorIO Representative
Cary Phillips - OpenEXR Representative
Chris Kulla - Open Shading Language Representative
Daniel Greenstein - OpenImageIO Representative
Diego Tavares Da Silva - OpenCue Representative
Jonathan Stone - MaterialX Representative
Ken Museth - OpenVDB Representative
Nick Porcino - Universal Scene Description Working Group Representative
Rachel Rose - Diversity & Inclusion Working Group Representative

Industry Representatives

Jean-Francois Panisset - Visual Effects Society

Non-Voting Attendees

Non-Voting Project and Working Group Representatives

LF Staff

David Morin - Individual - No Account
Emily Olin - Academy Software Foundation
John Mertic - The Linux Foundation
Yarille Ortiz - The Linux Foundation

Other Attendees

Alyssa Alexis - SIGGRAPH
Bill Ballew - DreamWorks
Clifford Stein - Sony Imageworks
James Helman - MovieLabs
Jeffrey Mahovsky - DreamWorks
Jon Lanz - DreamWorks
Jonathan Swarz - NVIDIA / OpenVDB
JT Nelson - Pasadena Open Source consortium / SoCal Blender group
Karen Ruggles - DeSales University / D&I WG
Lee Kerley - Apple
Lorna Dumba - Framestore
Mark Jackels - Dreamworks
Ole GUlbrandsen - Sony Group
Olga Avramenko - Sony Imageworks / D&I WG
Paul Ramsey - DreamWorks
Randy Packer - DreamWorks
Tony Micilotta - Autodesk
Toshi Kato - DreamWorks

Antitrust Policy Notice

Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

Agenda

General Updates
- Open Source Forum #1273
- Membership Drive #1275
- Dev Days 2026 #1288
Add WG Charters to TAC website #1266
- John: will tag WG leads to help with that.
New Project/Working Group Proposal: New Project Proposal - MoonRay #1287
Annual Review: OpenVDB #480

Notes

General Updates
- Open Source Forum #1273
  - At Netflix studios
- Membership Drive #1275
  - David: a yearlong effort, will come back from time to time. Membership drive is going well, lots of meetings. No action items for TAC, but if you meet companies showing interest, ask “Any interest in joining ASWF” please refer them to me.
- Dev Days 2026 #1288
  - May 14th, Sept 17
  - John: projects need to go through backlog, label good first issues, getting started docs. TAC representatives, get connected inside your company, get positioned as stake holder. When there’s someone in the org who can be center contact, helps everyone in the company to participate.
  - Olga: if anyone has questions, please come to me. We’ve expanded our team, we have an internal outreach coordinator, she’ll be helping with project side of things. Her name is Prajna (sp?). Hopefully this year there will be more support for projects and companies. If anyone knows someone who wants to coordinate for a company, send them my way.
Annual Review: OpenVDB #480
- Ken Museth
- Presentation Deck
- TSC
  - Voting Members
    - Ken Museth
    - Andre Padhana
    - Jeff Lait
    - Dan Bailey
    - Richard Jones
    - Nick Avramoussis
    - Gregory Husrt
  - Non Voting
    - Jonathan Swartz, fVDB Maintainer
  - Changed meeting cadence
- Release Plan
  - Two minor releases per year
  - One major release per year
- Version 12.0.1 - April 3, 2025
  - Support for multiple GPUS to DeviceBuffer
  - UnifiedBuffer class that wraps CUDA unified memory
    - Powerful capability in the CUDA driver
    - Can reference instances regardless of where it resides in memory (host or GPU)
  - Example of Multi-GPU sparse 3D convolution
  - CUDA utility functions for device queries
- Version 12.1, August 2025
  - SDFs from tapered tubes (think 3D wireframes)
  - Anisotropic surfacing (elliptic particle footprints)
    - Stringy water splashes
  - Support for latest CLANG (requested by Apple)
  - Nanovdb::VoxelBlockManager for streaming compute
    - useful for compute on GPUs, opens a lot of applications
  - Moved AX to newer version of LLVM
- New in OpenVDB 12.1
  - tools::createLevelSetCapsule
  - tools::createLevelSetTaperedCapsule
  - tools::createLevelSetTubeComplex -Used for models of human lungs
  - tools::createLEvelSetDilatedMesh
- Version 13.0.0 - November 3 2025
  - In memory half support (requested by Autodesk)
    - A lot of tools had to be updated to support this
  - Removed read support older than VDB version 1.0
    - Confirmed with Dreamworks
  - NanoVDB is no longer limited to static applications (like renderers)
    - Can now be used for simulation
  - Dilate, merge, coarsen, refine, prune, inject
    - Now implemented on GPU
    - New GPU-accelerated topological operators
    - Orders of magnitude faster than on CPU
    - Added to support fVDB, but also useful for simulation
- fVDB
  - Public release of version 0.3.0, October 24, 2025
  - Developed and maintained at NVIDIA, but part of OpenVDB
  - Low-level SDK (build on NanoVDB) for spatial intelligence, e.g. sparse 3D convolution and 3D attention
  - Includes batteries: Gaussian splat training and segmentation
  - Early testers / adopters : BAH, Dolphin Works, MITRE, Miris, Lowe’s Home Improvement, Aperio, Code 19, Voxel51…
  - On a different landing page:
    - fVDB landing page
    - moved Maya plugin to separate repo
- Miris + fVDB course at SIGGRAPH 2025
  - Startup company, streaming content on mobile
  - Train gaussian splats
  - Training much faster / stable with fVDB
  - Better segmentation with fVDB
  - fVDB Reality Capture: built gaussian splat and 3D geometry with 177 drone images
  - Lots of existing projects for gaussian splat training, but fVDB claim is scale: demo of 1.2 billion gaussian splats
- CI for fVDB
  - Moved CI to AWS EC2 instances
  - From fractional L40 to multiple GB200
  - $650 total cost over 7 months
    - Misconfiguration in October
    - Typically $30-$75/month
    - NVIDIA is paying!
- CI for OpenVDB
  - Small on every commit
  - Larger on nightly builds
  - All on weekly basis
  - Turned off nightly builds
    - Hope to see reduction in CI costs
- History of VDB file format
  - OpenVDB acts as a file format as well as tools to manipulate
  - File format hasn’t changed in 10 years
  - But we “left money on the table”
- Future: new file format
  - Preserve backward compatibility
  - Enable read-support before write-support (opt-in)
  - Separate topology and values (cd NanoVDB)
  - Support lossy compression (cf NeuralVDB)
    - Everything had been lossless so far
  - Improve lossless compression
  - Replace Delayed Loading with Selecting Loading
    - Delayed Loading is not very useful since data doesn’t get evicted, so will run out of memory
    - Selective loading can achieve the same
    - Eliminate Boost dependency
  - Modular I/O codec architecture
    - Continue to read legacy format, no Grid ABI or API breakages
  - Improve lossless codecs
    - Faster by overlapping I/O with compute
  - Discrete Cosine Transform (DCT) is the algorithm behind JPEG/MPEG
  - DCT for images on 8x8 pixel data
  - DCT for voxels on 8x8x8 blocks
New Project/Working Group Proposal: New Project Proposal - MoonRay #1287
- Matthew Low
- Presentation Deck
- MoonRay: ASWF Contribution Proposal
  - Jon Lanz: Shading Tech Lead
  - Matthew Low: DWA TAC Rep, DPEL TSC Chair
  - Jeff Mahovsky
  - Randy Packer: Senior Manager
- Agenda
  - MoonRay
    - Overview, features, history
  - Open Source
    - Current status, resources, structure, architecture
  - Demos
    - Parallel architecture, multi-machine, multi-context, Apple, WIndows
  - ASWF Alignment
- MoonRay Overview
  - MoonRay High-end production path tracer
  - MoonShine Collection of layerable production shaders
  - Arras Cloud computation framework for local and distributed rendering
  - Multi-platform Linux, MacOS and Windows
  - OpenUSD & Hydra Pipeline & Render delegate
  - Utilities Supporting tools, testing, profiling, debugging, development
- MoonRay in Production
  - All of our films since How To Train your Dragon 3
  - We use the OpenSource version
- MoonRay overview: modern technology
  - Bundled architecture
  - Scalar, vector and XPU modes
  - Uniform and adaptative sampling
  - Render profiling viewer
  - Hydra render delegate
  - Interactive GUI
  - Deep Cryptomatte support
  - …
- MoonRay History
  - Proof of concept of bundled, vectorized architecture in 2014
  - Initially built for Rendering as a Service
  - Deployed to How to Train Your Dragon: The Hidden World in 2018
  - Open Sourced in 2023
- MoonRay at Dreamworks
  - Used on all feature productions
  - Weekly releases
  - Automated CI & Build
  - Automated regression testing with performance profiling visualization
  - Core team: 7 engineers
  - Additional contributors: 6 engineers
- MoonRay in the Community
  - Community Contributions
    - macOS / Metal build
    - Native Windows port
    - WSL support (in progress) (used as stress test by Microsoft)
    - Snap installer
    - Support for various distros (ArchLinux, Debian, etc)
    - Used by:
      - Production partners (validate look development)
      - Compiler vendor (used as test case)
      - Hardware vendor (used as test case)
      - Academic projects
- MoonRay Open Source Project
  - Apache 2.0
  - CLA and DCO
  - C++, ISPC, Lua, Python, CMake
  - GitHub and documentation website
  - Super Project w/ 19 submodule repos (4.5K stars)
  - Releases weekly internally, quarterly publicly
    - In progress to match cadence with testing & automation
  - Project Governance modeled on ASWF template
  - OpenSSF Best Practices: “Passing” in progress
- MoonRay Architecture
  - “Keep all the lanes of all the cores of all the machines busy all the time with meaningful work”
    - SMED vectorization with ISPC
    - NUMA-aware multi-threaded implementation
      - Optimized for hundreds of cores
    - XPU mode uses GPU as coprocessor
      - Object / ray intersection
      - want to move more computations on GPU
    - multi-machine rendering with ARRAS
- Bundled / Wavefront architecture
  - Vectorization achieved using Intel ISPC and MoonRay’s wavefront architecture
    - Conventional Path Tracing: one ray at a time
    - Wavefront Path Tracing: bundles of rays, process up to 8 operations in parallel. Bundles sorted to optimize memory access coherency
- ARRAS: Distributed multi-machine rendering
  - 4 types of processes, can run on a single machine, or distributed across multiple machines
    - Client process: in Houdini, Maya, Katana
    - Dispatcher
    - MCRT (rendering) process
    - Merge computation: one stream, sent back to client process
  - With large number of processes, can have have reliability issues. ARRAS implements better reliability and redundancy.
- Demos: Single vs Multi-machine comparison
  - 4 renders of Intel 4004 More Lane USD Scene
    - Standalone
    - Standalone + CPU denoising
    - 32 hosts multi-machine
    - 32 hosts multi-machine + CPU denoising
  - Multi-Machine with Light Path Visualization: ALab Scene
    - Overlay of telemetry information the help debugging
    - Light path visualizer, also works on distributed rendering
  - Multi-Context Distributed Rendering
    - Fast incremental updates as the camera is panned around
    - Artist can view asset under 4 separate lighting conditions
  - Multi-shot Distributed Rendering
    - Can render multiple shots in a sequence simultaneously
      - Used to verify consistent / robust lighting rigs
  - Apple Silicon / Metal
    - MoonRay working on Apple, with XPU using Metal
    - Leverage unified memory pool to render large assets, can render highly complex scenes on a laptop
    - All cores kept busy
  - Windows
    - Native port on Windows from 2 community engineers
    - Updates coming soon, with USDView
- ASWF Alignment - Render Landscape
  - Many renderers for Feature Production, many are proprietary / commercial. MoonRay is freely available.
  - Some open source options: Cycles, pbrt, MoonRay, Mitsuba 3. Several are used for non film production, MoonRay is the only production proven, studio scale renderer. eeve in Blender was used to render Flow.
  - MoonRay can bridge open source and feature rendering
- ASWF Alignment: Product Ecosystem
  - MoonRay integrates many ASWF projects
    - ACES
    - OCIO
    - OpenEXR
    - OpenImageIO texture subsystem
    - OpenVDB
    - Rez
    - MaterialX (in progress)
    - OpenUSD (Hydra delegation)
    - DPEL assets
  - Opportunities
    - OpenPBR
    - OSL
    - OpenQMC
    - OpenPGL
    - OpenCue
  - Adhere to VFX Reference Platform
  - Can be a “canary project” for integration
- ASWF Alignment: Member Engagement
  - Apple
  - Ubuntu (snap package supprot)
  - Microsoft (WSL integration)
  - Intel (embree, open image denoise, ISPC validation)
  - Also several studios
  - Collaborations have been in private, by joining ASWF we can make those public
- Thank you!
- Open Discussion
  - Michael: timeframe for MaterialX? Jon: in progress for about a year, but we are a small team. Making great progress, hope to start testing internally soon. Not merged in main branch yet. Will be in next open source release. MoonRay is not an OSL renderer, our shaders are pre-compiled, we’re implementing full MaterialX in MoonRay.
  - JF: do you work off the public repo? Jon: currently all main developement is done internally, we push updates to public quarterly, going forward we don’t have a good answer yet. Discussing what would be the best approach, ideally we would be working off the public codebase. We have moved deeply to increase our external updates to match our internal updates. Matthew: we have a set of regressions tests working on production data, removing Dreamworks IP to be able to run validation on public GitHub, that was a blocker. Once we can run tests to verify stability for production, that will help to target the open source version. Larry (chat): Most projects find that it’s an anti-pattern to develop in a non-public branch.
  - JF: excited about the “canary app” that calls most other ASWF apps for CI.
  - Cary: mentioned a TSC chair. Do you have non-Dreamworks contributors signed on? Randy: not yet, starting to make the outreach. Hasn’t been a priority since we open source, we’ve been working on automating our procedures, but we’ve started probing. So not yet, but we’re doing the outreach. Matthew: we’re hopeful that joining ASWF can diversify our outreach. That will help us expand the TSC. Cary: a natural evolution of the projects. The step of moving into ASWF is the time to bring in more contributors, we hope our projects are truly communally supported, not just tightly held by a single organization. But there is a chicken and egg. John (chat): I could also see the project in a vendor-neutral governance will help increase contributions; this was a big gap in early projects like OpenVDB, where it was really hard to contribute to these projects which were owned by specific studios and being an external contributor was very hard to do.
  - Gordon: can you talk more about what you hope to change by moving into ASWF? It’s already on GitHub, you already have an ASWF like governance model today. Other than visibility, what do you hope to get / problems you can solve? We want to know what kind of support / engagement. Randy: there’s a number of benefits, general ASWF mission statement of a “neutral home” helping collaboration. Also established procedures, engaging with projects, for instance OpenPBR, MaterialX. Until now a lot of our learnings have been us going at it alone. Matthew: nothing has prevented us from being more engaged, it’s been more challenging on our own. Some of the CI plans will help, Mac / Windows support, see how other projects have been doing things. Gordon: there’s a correlation between contribution and adoption. Neutral home is important, are there studios looking at adopting where a neutral home would help? Randy: not that specifically, but some people making slow inroads. A neutral home would help. There are private conversations that happen, we also have analytics, significant interest that is more important than what people are saying publicly. But we can only benefit. Matthew: some studios have said that being part of ASWF would help with adoption.
  - Cary: you would surrender a certain amount of ownership / control. So you need to be prepared with the situation where other contributors may want to take the project in a different direction than Dreamworks. Matthew: yes, we understand that. Randy: it’s like having a variety of productions with different “look” requirements. We already have some experience there.
  - Jonathan: want to highlight advantages of a reference implementation of a production renderer. Also a way to validate OpenUSD / MaterialX renders. We’d be excited about that. Previously we’ve thought about ways to build something from scratch, would be great to shift effort to an existing, open source production renderer. Would be great if MoonRay could support all parts of ASWF stack, including OSL, even if not ideal from performance perspective. Would be very powerful, and might simplify USD / MaterialX rendering framework. Excited about the possibilities!
  - John: from a TAC perspective, do we need to have more discussions, or are we ready for offline vote? Cary: discussion is more “how” to execute rather than “whether”. We should move to vote. Michael: do we have quorum? John: best to do offline, any issues? Larry: not voicing opposition, but everyone should feel it’s OK to discuss more. We don’t want to push this down everyone’s throat. Randy: happy to answer any additional questions.
  - John: if anyone has a concern. Eric: we could discuss in person for more discussions. John: hold the vote after that? Eric: would suggest after that. Cary: could be a nice thing to announce in person. Michael: we can also express in the vote. Cary: DreamWorks is such a core member of ASWF, and this is a mature project, chance that we would say “no” seems really slim. Major questions are just around working the details, not blockers / obstacles. John: will get vote going, quorum will show whether we need to talk in person.
  - Matthew: works for us!

Next Meeting Agenda

General Updates
- ORI follow up on Incubation #1167
- AGENDA TOPIC: AI code assistant policy #1195
- 2026 Security Reviews #1137
2026 TAC Priorities #1208