The VFX Reference Platform is a set of tool and library versions to be used as a common target platform for building software for the VFX industry. Its purpose is to minimise incompatibilities between different software packages, ease the support burden for integrated pipelines and encourage further adoption of Linux by both studios and software vendors. The Reference Platform is updated annually by a group of software vendors in collaboration with the Visual Effects Society Technology Committee.

Current Status

The Calendar Year 2022 (CY2022) Reference Platform is the target for all major software releases in 2022.

31st October 2022 - Late changes to CY2023 have been applied to OpenSubdiv, OpenVDB, and OpenColorIO which all completed major new releases before the extended deadline of October 31st.

9th October 2022 - Late change to CY2023 due to new OpenSubdiv release, and after community consultation. OpenSubdiv will be updated to 3.5.x if a compatible USD release is published by October 31st.

7th September 2022 - CY2023 is now Final. Confirmation of versions for OpenEXR, OpenVDB, OpenColorIO, and ACES will follow by early November pending the timely release of new versions. As always, if any major issues are discovered with CY2023 then they will be shared with the community to decide whether a late change is required. Please note the change to glibc may require a major Linux distro upgrade, and the recent recommendation for studios to migrate to RHEL, Rocky Linux, or AlmaLinux.

9th August 2022 - VFX Linux Distribution Recommendation Report (pdf) published and new Linux page added.

Previous status updates...

Reference Platform

Each annual reference platform is designated by the calendar year in which major product releases should be targeting that particular reference.

All versions should be considered exact required versions, except for those components where indicates that:

  CY2023 CY2022 CY2021 CY2020 CY2019  
Linux gcc 11.2.1
Switch to new libstdc++ ABI
(see notes)
(see notes)
(see notes)
(see notes)
(see notes)
glibc 2.28 2.17 2.17 2.17 2.17
macOS Minimum Deployment Target 11.0
(see notes)
(see notes)
(see notes)
Windows Minimum Platform Toolset Visual Studio 2022 Visual Studio 2019
v16.9 or later
Visual Studio 2017    
Windows SDK 10.0.19041 or later 10.0.19041 or later v10    
Common Components Python
(built with ucs4)
3.10.x 3.9.1 - 3.9.latest 3.7.x
(see notes)
(see notes)
2.7.9 - 2.7.latest
Qt 5.15.x
(6.5 planned for CY2024)
5.15.x 5.15.x 5.12.x 5.12.x
PyQt 5.15 5.15 5.15 5.12 5.12
Qt for Python
5.15 5.15 5.15 5.12 (with patch)
or 5.13
NumPy 1.23.x 1.20.x 1.19.x 1.17.x 1.14.x
OpenEXR 3.1.x 3.1.x 2.4.x 2.4.x 2.3.x
Ptex 2.4.x 2.4.x 2.3.2 2.3.2 2.1.33
OpenSubdiv 3.5.x 3.4.x 3.4.x 3.4.x 3.3.x
OpenVDB 10.x 9.x 8.x 7.x 6.x
Alembic 1.8.x 1.8.x 1.7.x 1.7.x 1.7.x
FBX 2020.2 - 2020.latest 2020.x 2020.x 2020.x 2019.x
OpenColorIO 2.2.x 2.1.x 2.0.x 1.1.x
(v2 in CY2021)
ACES 1.3 1.3 1.2 1.1 1.1
Boost 1.80 1.76 1.73 1.70 1.66
Intel TBB 2020 Update 3
(Plan to move to
oneTBB in CY2024)
2020 Update 3 2020 Update 2
(see notes)
2019 Update 6 2018
Intel MKL 2020
(Plan to move to
oneMKL in CY2024)
2020 2020 2019 2018
C++ API/SDK C++17 C++17 C++17 C++14 C++14


Support Guidance

Providers of software libraries focused on VFX and animation content creation should aim to support their releases for the current calendar year and the three preceding years with compatible updates. Studios and end users should have no expectation of support for older libraries.

The VFX Reference Platform strongly recommends open source project maintainers provide a level of support described by the FLOSS Best Practices Criteria, which is already a requirement for all Academy Software Foundation projects.



Notes - macOS

Minimum Deployment Target in Xcode

Xcode’s “Deployment Target” identifies the earliest OS version on which your software can run.

To set the Deployment Target for the compiler, use the option "-mmacosx-version-min=10.13“ to specify the APIs marked as available. For the linker, use the option "-macosx_version_min 10.13" to instruct the linker to create a key in the Info.plist file which marks the executable as being able to run or not for a given OS version.

The MACOSX_DEPLOYMENT_TARGET environment variable also sets the minimum deployment target and is used if the compiler option is not specified. The environment variable is also recognized by CMake.

Note: Despite the backward compatibility, it is still possible for runtime behavior to be affected by SDK and OS version, hardware etc.

More information on configuring developer tools is available in the SDK documentation.

Frameworks vs Shared Libraries

In general, the Frameworks approach is recommended over shared libraries for building and deploying components like Qt and Python on macOS.

UPDATE: May 22nd 2021 - CY2022 dropping 32-bit support

The move to 10.15 requires all apps to be 64-bit, with 32-bit releases no longer supported.

UPDATE: April 4th 2021 - Building Qt for macOS

Building Qt against C++17 requires a minimum macOS version of 10.14 otherwise Qt fails during configuration. If 10.13 support is needed then a known workaround is to build Qt against C++14.

Note - Python 3

Python 3 is a required upgrade for software providers from CY2020 onwards as Python 2 is no longer supported beyond 2020.

Note - gcc 9 and 11

For users of Red Hat Enterprise Linux and RHEL-derived Linux distributions (such as CentOS Linux and Rocky Linux), the Redhat Developer Toolset (DTS) offers gcc and other build tooling that provide increased compatibility and it is used by many software vendors and studios. DTS 9.1 provides gcc 9.3.1 for compatibility with CY2021, and DTS 11.0 provides gcc 11.2.1 for compatibility with CY2023.

For those who want or need to use llvm, some studios have been successful building clang with DTS and using that to build software that is compatible with vendor-provided libraries.

Since gcc 5.1, libstdc++ introduced a new library ABI that includes new implementations of std::string and std::list. In order to maintain backwards compatibility the old implementations are still supported in parallel with the new ones. The choice of implementation is made using the _GLIBCXX_USE_CXX11_ABI macro, and the VFX Reference Platform up to CY2022 used the older option so the compiler setting for those Platforms should be _GLIBCXX_USE_CXX11_ABI=0, although that setting may not be supported by some older Linux distros.

From CY2023, the Platform has moved to the newer implementation since all the major Linux distributions have made the transition. This is a major change for CY2023 that may require a rebuild of all software against the new ABI for those moving from earlier Platforms.

Note - gcc 6

UPDATE: May 10th 2020 - Redhat DTS 6.1 is no longer actively supported so availability may be limited. More information available on this vfx-platform-discuss thread.

UPDATE: November 26th 2017 - CY2018 changed from gcc 5 to gcc 6 due to integration issues discovered with the older version.

Redhat/CentOS systems can obtain gcc 6.3.1 by installing Redhat DTS 6.1. To install Red Hat Developer Toolset 6.1 on CentOS 7:

sudo yum -y install centos-release-scl
sudo yum -y install devtoolset-6

If you are looking for gcc 6.3.1 source code then a copy can be found in the CentOS Vault.

Since gcc 5.1, libstdc++ introduced a new library ABI that includes new implementations of std::string and std::list. In order to maintain backwards compatibility the old implementations are still supported in parallel with the new ones. The choice of implementation is made using the _GLIBCXX_USE_CXX11_ABI macro, and the VFX Reference Platform is still using the older option so the compiler setting should be _GLIBCXX_USE_CXX11_ABI=0. The Platform will move to the newer implementations in a future year once the major Linux distributions have made the transition. RHEL/CentOS 7 and Redhat DTS still use the original implementations by default.

Note - Intel TBB

There is a known issue compiling TBB 2020 with MSVC 2017 that can be resolved with this workaround.

Please plan to port to oneTBB for CY2024.


Any reference made in the VFX Reference Platform to any company or any other entity, or to their services or products, is not an endorsement or recommendation nor should it imply any such endorsement or recommendation of the quality or fitness of purpose of that company or entity, or its services or products. In no event shall the Visual Effects Society be responsible or liable, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any such content, goods, or services identified in the VFX Reference Platform or the Visual Effects Society website.