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.
The Calendar Year 2024 (CY2024) Reference Platform is the target for all major software releases in 2024.
3rd November 2024 - CY2025 updated to confirm the planned new releases for ACES, OpenColorIO, OpenEXR, and OpenVDB.
2nd September 2024 - CY2025 is now Final and will be effective from January 1st. Confirmation of versions for ACES, OpenColorIO, and OpenEXR will follow by early October, and OpenVDB by early November pending the timely release of new versions. As always, if any major issues are discovered with CY2025 then they will be shared with the community to decide whether a late change is required.
2nd September 2024 - New report published! The 2024 VFX/Animation Studio Workstation Linux Report is now available giving an insight into the current state of Linux on studio workstations.
18th August 2024 - CY2025 Draft updated. OpenEXR release window extended until Oct 1st. Minimum version of Visual Studio bumped to 17.6 (note the limited support window of the "long-term servicing channel"). Python reluctantly reverted to 3.11 due to a compatibility issue with Qt 6.5. Upgrades to Qt 6.8 and a newer Python are planned for CY2026.
16th June 2024 - CY2024 and CY2025 Draft updated to Windows SDK 10.0.20348 due to compatibility requirements of Qt 6.5 WebEngine.
14th May 2024 - CY2025 Draft published, with the main change being a move to Intel's oneAPI for TBB and MKL. We are currently soliciting feedback on this Draft so please either send to feedback@vfxplatform.com or share on vfx-platform-discuss.
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:
| CY2025 | CY2024 | CY2023 | CY2022 | CY2021 | |||
|---|---|---|---|---|---|---|---|
| Linux | gcc | 11.2.1 (New libstdc++ ABI) (see notes) |
11.2.1 (New libstdc++ ABI) (see notes) |
11.2.1 (Switch to new libstdc++ ABI) (see notes) |
9.3.1 (see notes) |
9.3.1 (see notes) |
Earlier Platforms |
| glibc | 2.28 | 2.28 | 2.28 | 2.17 | 2.17 | ||
| macOS | Minimum Deployment Target | 12.0 (see notes) |
11.0 (see notes) |
11.0 (see notes) |
10.15 (see notes) |
10.13 (see notes) |
|
| Windows | Minimum Platform Toolset | Visual Studio 2022 v17.6 or later |
Visual Studio 2022 v17.4 or later |
Visual Studio 2022 | Visual Studio 2019 v16.9 or later |
Visual Studio 2017 | |
| Windows SDK | 10.0.20348 or later | 10.0.20348 or later | 10.0.19041 or later | 10.0.19041 or later | v10 | ||
| Common Components | Python | 3.11.x | 3.11.x | 3.10.x | 3.9.1 - 3.9.latest | 3.7.x (see notes) |
|
| Qt | 6.5.x (6.8 planned for CY2026) |
6.5.x | 5.15.x (6.5 planned for CY2024) |
5.15.x | 5.15.x | ||
| PyQt | 6.5.x | 6.5.x | 5.15 | 5.15 | 5.15 | ||
| Qt for Python (PySide) |
6.5.x | 6.5.x | 5.15 | 5.15 | 5.15 | ||
| NumPy | 1.26.x | 1.24.x | 1.23.x | 1.20.x | 1.19.x | ||
| OpenEXR | 3.3.x | 3.2.x | 3.1.x | 3.1.x | 2.4.x | ||
| Ptex | 2.4.x | 2.4.x | 2.4.x | 2.4.x | 2.3.2 | ||
| OpenSubdiv | 3.6.x | 3.6.x | 3.5.x | 3.4.x | 3.4.x | ||
| OpenVDB | 12.x | 11.x | 10.x | 9.x | 8.x | ||
| Alembic | 1.8.x | 1.8.x | 1.8.x | 1.8.x | 1.7.x | ||
| FBX | 2020.2 - 2020.latest | 2020.2 - 2020.latest | 2020.2 - 2020.latest | 2020.x | 2020.x | ||
| OpenColorIO | 2.4.x | 2.3.x | 2.2.x | 2.1.x | 2.0.x | ||
| ACES | 2.0 | 1.3 | 1.3 | 1.3 | 1.2 | ||
| Boost | 1.85 | 1.82 | 1.80 | 1.76 | 1.73 | ||
| oneTBB/TBB | 2021.x (Move to oneTBB) |
2020 Update 3 (Move to oneTBB deferred to CY2025) |
2020 Update 3 (Plan to move to oneTBB in CY2024) |
2020 Update 3 | 2020 Update 2 (see notes) |
||
| oneMKL/MKL | 2024 (Move to oneMKL) |
2020 (Move to oneMKL deferred to CY2025) |
2020 (Plan to move to oneMKL in CY2024) |
2020 | 2020 | ||
| C++ API/SDK | C++17 | C++17 | C++17 | C++17 | C++17 | ||
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.
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.
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.
There is a known issue compiling TBB 2020 with MSVC 2017 that can be resolved with this workaround.
Please plan to migrate to oneTBB and have compatible releases published by September 1st 2024 to enable DCC providers to complete a planned move in CY2025. The original plan was to move to the oneAPI in CY2024 but more time was needed to migrate critical dependencies without impacting performance or introducing multiple conflicting thread pools.
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.