Insight from a VFX pipeline because I work on that 2 days a week.
All code we are writing has to be py 37 compatible because of the mix of software we deal with. For QT we use a shim so we can be somewhat independent of the QT version.
It is still a headache to deal with all the permutations and upgrading is a lot of work so in fact we are always behind the VFX reference platform.
Thankfully we got rid of py27 this year
4 Likes
The platform lagging on certain deps is an on-going issue, the py 2.x->3.x update literally took years of “it’ll be next year, aww… beans…well uhh…next year! promise!” , TBB had been stuck on TBB2020 for 4 years due to a common problematic dep that’s not even on the platform (USD), we don’t ship it but the story for MKL is pretty much the same (although unsure why that got stuck, and the platform doesn’t feel a need to justify/clarify their choices most of the time)
it is very much a pattern rather than a one time thing, and i think we’re just gonna have to accept “that’s what they do”
Ahh, OK. I guess since the big Studios tend to move or change things somewhat slowly, it just doesn’t bother them. Given that as pointed out, they have significant resources, so if it really was an issue, someone could solve it.
I wonder and this could be totally unworkable, impractical and just plain stupid, but what if only the LTS releases lined up with the reference platform and out side of that, some more freedom/leeway is possible for Blender.
I mean the LTS release is yearly, so if the timing of that release was more aligned with the reference platform schedule, then it may work. Or not, for a bunch of other reasons.
I had considered it, but you’d end up in the weird situation that blender 4.4 would ship with python 3.13 and then blender 4.5 which is an LTS release would ship with python 3.11, and 5.0 would ship with 3.13 again, which would be confusing for everyone involved.
3 Likes
I’m a tools and pipeline technical artist in the AAA game industry.
My studio isn’t explicitly aligning itself with the VFX Reference Platform, but every time I find out that an app is aligning itself with those standards I breathe a sigh of relief.
We use Blender, Maya, Substance Painter, Photoshop, Unreal Engine 5, PySide, Custom stand-alone Python apps, and more. The biggest battle I have at work is how each of these apps have different Python environments.
Some libraries that we use such as the FBX SDK Python bindings must be pre-compiled for each specific version of Python. So each app that doesn’t align with the VFX Reference Platform introduces issues with these libraries.
I could speak more to this, but in short, I’m a fan of sticking with the VFX Reference Platform.
10 Likes
Thank you for reaching out. Really nice to have some more examples from other users like you and ChristophLendenfeld.
How many of the programs/libraries that you use are on the same VFX platform version?
As your studio is not aligning itself to a specific VFX platform release (say 2023), and instead picks software from what you want to use at that moment. It seems like it would be hard to get the same python version even if all programs you use are following the VFX platform to some extent. (Because the python version and other library version are supposed to change each year for the VFX platform)
Do you try to pick specific versions to make them align or is library versions matching more of a happy accident that is discovered after the exact program versions has been picked?
The general idea of using the VFX platform is the reverse in that the studio is meant to pick the VFX platform version first and then pick software versions that are on that specific version.
I’m very interested in what your approach to this is as when I worked with locked down versions like this, it usually evolves into a mix of different library versions despite of this as people want new and shiny things. IE if you picked VFX platform 2022, people would want to get in software that is from 2023 and up, which kinda defeats the purpose of picking the 2022 version and sticking with it. (As you still need to make it play nice with the newer software that was pulled in).
A lot of the time, it comes down to how easy it is to bootstrap a Rez environment for a particular combination. If the combo aligns with the VFX reference platform, or at least comes close to it, you’ll generally already have (or intend to build) the right packages needed to piece something together.
Rez enables a ton of flexibility and it’s helped studios get away from pinning their DCC versions for 3-5 years at a time, but there’s still a fair bit of labor involved — especially for software that doesn’t align with the VFX platform. If a software package’s requirements diverge from the reference platform and it isn’t a mission-critical tool, it often doesn’t make financial sense to build out support for it in the middle of the year. It’s easier (and financially safer) to simply wait and see if the stars will align for the next version.
While it might feel like the VFX platform is perpetually out-of-date, in practice it helps justify the labor costs of incremental updates that studios wouldn’t otherwise keep up with. Being 1-3 years out-of-date is an improvement over being 3-5 years out-of-date, and following the reference platform’s update schedule makes it easier to cherry pick those new and shiny things from the future.
3 Likes
It’s more of the latter. I’m not in a position to dictate the apps our team uses, I just make the tools and the bridge between them work, and I’m taking any random win I can get. As more apps align themselves with the VFX reference platform, those random wins seem to be more common.
As a video game studio, the game engine (Unreal) comes first. We pick other tools that the artists need to get art into the engine. We compile the engine ourselves and make lots of engine edits on an almost daily basis. That said, we integrate the latest engine features from Epic every few months (at least for now, when we enter full production we won’t be taking engine integrations anymore). Recently we integrated many new features from Unreal 5.4 which now uses Python 3.11. Hooray for me, since this lines up to Blender!
This particular engine upgrade was tough because it removed support for PySide2, and I had to upgrade all of our tools to work with PySide6.
Since not all of our apps align to the VFX reference platform and/or some of our apps are out of date anyway, this is a real challenge. We’ve found some tools that help add a layer of abstraction such as QtPy: GitHub - spyder-ide/qtpy: Provides an uniform layer to support PyQt5, PySide2, PyQt6, PySide6 with a single codebase which can help us run the same PySide code across several different Python versions. It’s not perfect though, and it’s always easier if each app is on the same Python version (3.11 in this case).
5 Likes
I feel that we are getting more specific feedback now about studio VFX Platform hurdles/requirements than we ever had (publically at least). Thanks everyone for the specific examples.
3 Likes
As a followup: Formal official decision from Blender to keep following the VFX platform: VFX Reference Platform Statement
2 Likes