Page MenuHome

Define VFX Reference Platform Policy
Open, NormalPublic

Description

Starting with CY2020, the VFX Reference Platform uses Python 3.7. This gives us an opportunity to align with it. We should decide if this is something we want to do, and what that means exactly.

The goal would be to align all releases in 2020 to the CY2020 platform, which in our cases would be for Blender 2.82. If we upgrade to a too new version of a library in 2.81 we can't downgrade easily though.

The VFX reference platform is currently for Linux only. It is planned to be extended to Windows and macOS in CY2021.

Being compatible with the reference platform does not mean we have to use all the exact compiler or library versions listed. What matters is effective API/ABI compatibility, and file format compatibility. There are a few different considerations.

GCC and glibc

We are already compatible with the required glibc version 2.17.

We can use newer GCC or Clang versions that produce more optimized code, as long as they are ABI compatible with the stated GCC version.

C/C++ Compatibility

We currently do not have a public C/C++ API, and are also not exposing any of the external libraries as an API.

A change we could make is to hide symbols by default. We currently hide some symbols that are likely to conflict, but not all. This is already automatically done on Windows, but not on Linux or macOS. Plug-ins can generally handle this on their side too, but we may as well make it easier to not conflict.

Python Compatibility

To guarantee full compatibility, we'd have to use Python 3.7 and Numpy 1.17. Python scripts written for 3.7 should generally work fine in 3.8, but not the other way around. For extensions there is a stable ABI, but it's not clear this is widely used and so extensions would be incompatible.

The downside is that we'd have to wait a year use Python 3.8 after its release. As the Python ecosystem moves to 3.8, we then deviate from the rest of the Python community that are not following the VFX reference platform.

For example on Windows the default version to download from the Python website in 2020 would be 3.8. But this means it would not be compatible with Blender or give PYTHONPATH problems.

File Format Compatibility

Libraries like OpenEXR, OpenVDB and OpenColorIO read and write files. We want those versions to be new enough that we can read files written by other software. Further, using a newer version can give files that other applications can't read.

Note for example that the OpenVDB file format remained compatible across some major versions. In such cases we can use a newer library version, if it contains functionality that we need.

On the other hand OpenColorIO 2 is breaking compatibility. It contains improvements that are quite useful to us, but is only planned for CY2021.

Details

Type
To Do

Event Timeline

i never was a major fan of VFX reference platform as it chooked stuff for many many years. so i would say to follow it on API side but not on internal one.

also correct me if i am wrong but.. if u write plugin in python A version... it will not work with other apps... even if they support python A? right? so what is the point of beying on same python.. if it is not that u write 1 plugin and it works for all others DCC...

file formats okey fine. that is very logical. but other stuff i think should be newest?

There are two reason for using the same Python version:

  • For add-on developers creating extensions specifically for Blender, it would be most convenient if that could use the same Python version as other software. This is not a major issues in my opinion, installing multiple Python versions side by side is not that difficult and the number of developers doing this is not that high.
  • For a user of multiple softwares, it helps to have a single Python version for which they can install Python packages and use them across all software. This is the more important consideration, for technical users and studios that use Python scripts for their pipeline. Dealing with multiple Python versions here is problematic.

However, Python 3.8 will the default Python version to download from python.org in 2020, and so for Windows it's not going to be convenient if Blender uses a different version.

The few times i have interacted with people asking about the VFX Platform, it was always these things

  1. The python version

But when you asked a little further, they only reason they cared about the python version because they really wanted to use

  1. QT/PyQt/PySide

which required py 2.7

  1. the glibc version, we jumped too soon to a too new glibc, locking out our binary for the redhat/centos guys, naturally these people were not super thrilled. Not sure how many actually cared about the VFX platform but if it's your only piece of ammunition, you're gonna use it.

3 is already addressed, aligning our selves with the python requirement of 1 shouldn't be too hard, but 2... yikes.... that's gonna balloon our distro size significantly for a thing has come up only sporadically sofar

About Glibc... aren't newest redhat 8.0 comes with glibc 2.28...

@LazyDodo (LazyDodo), we are not going to include Qt as part of trying to match the VFX reference platform, I have only libraries we already ship in mind here.