Blender and VFX Reference Platform Feedback

Will Blender 5 still follow the ‘VFX Reference Platform’ requirements?
If not, studios will NOT like the changes made, especially when dealing with Python.

There currently no plans to stop following the VFX Reference Platform.

That being said, it is quite hard decision to make. Blender following VFX Platform was supposed to be a short experiment, with an intent to evaluate whether it actually helps Blender or not. Unfortunately, we do not have any definitive feedback. There are some indirect speculation and guesses we can make, but it is not very compelling to base fundamental decisions based on such things.

Personally I think it is useful thing for Blender to follow VFX Platform, but I also see downsides of that. For example, the fact that CY2025 sticks to Python 3.11 is quite worrying: this Python release will not receive any bug fixes (all the support is limited to security only). This might put us in the situation when it might be harmful for Blender users who are not constrained by the reference workstation.

Such situation is something that actually happened in the past. It lead to some quite confusing situation, which I am not sure worth going into details in this thread.

Main point is: if you have user stories from the studios to confirm that our efforts and compromises to follow VFX Reference Platforms are widely useful, please let us know!

8 Likes

Hi,

Maybe do a ‘studio only’ related survey as well, and see what comes out of that?

I know from experience a lot of studios take a long time to implement new software into a pipeline, and meeting the VFXRP is a must, especially to keep compatibility.

I feel we have enough people hanging around here that work at studios starting using Blender in their pipeline.
These people can give useful information. Heck, some of them even presented at the Conference.

And afaik, the BF gets donations from bigger companies, another entry for different pipeline related questions?

The current survey will probably point more in the single freelancer/tiny studio/hobbyist than anything else, confusing the numbers for this discussion.

Could you elaborate on that?
We already have several ways of dealing with scripts run on start or opening a file. We now also have internet access for extensions. How would staying on 3.11 harmful as we’re running the same now? Or am I misunderstanding?

1 Like

Survey might work. But to my knowledge BF was trying to reach out to studios directly, with barely any response on this topic.
It might also be as simple as few studios reaching out to us via email (maybe to Ton, or to the Foundation) saying “Dear Foundation. You switching and sticking to the VFX Platforms REALLY REALLY helped us. Please keep doing this!”. That will already re-assure us that there is undeniable value to the effort.

Could you elaborate on that?

We’ve run into situation in the past where simple mistake in a script would crash Blender. It was a bug on Python side, so not something we could easily solve from the Blender side. The issue became quite wide-spread so we’ve made a decision to switch to a newer Python version much earlier than VFX Platform aligning to it.

So basically it is question of priorities: fixing a crash for users that will have easily measurable impact, or sticking to VFX Platform for which we currently can not measure impact.

It could also help if VFX Platform itself would be more proactive in switching to a newer Python versions. That would solve the main reason why we are “unhappy” with the platform.

To my knowledge the reason CY2025 did not switch to Python 3.12 is due to some bugs in PyQT/PySide. Maybe it is not impossible to organize some common “force” on fixing such stoppers?

P.S. It feels that this discussion does not strictly belong to this thread, but I can not think of a better place for it. And it is useful conversation to have. Maybe it would make sense to have “Blender and VFX Reference Platform Feedback” thread where we can continue the conversation, and involve other interested studios etc?

1 Like

They can’t, the way the release schedules from the VFX platform and Python line up they’ll always be a year behind, so even in “good years” where they do bump you’ll always end up with a significant portion of the year with just security fixes on python. That is unless either VFX or Python adopts a different release schedule, but I don’t see that realistically happening.

1 Like

They totally could, they are adding versions of some of the OpenXXX libraries before they are released. (like 2025: OpenVDB 12.x if released by Nov 1). Python is usually released early October, so…

But that’d be a fight for later. Current issue is the decision to stick to Python from 2022 (3.11) ‘just because’ there is an issue with another dependency with Python from 2023 (3.12, details here).

According to this mail thread, they could have switched to QT 6.8 to fix that issue, but in August it was already ‘too late’ for such a change.

This platform is totally oriented towards the ‘big industry’ and therefore moves very slowly. :frowning:

1 Like

If python was standalone, that would fly, but they need a mix of python + QT + Pyside to be harmoniously be working together by nov 1st, yet here we are nearly a year after py 3.12 released and that specific combination still hasn’t worked out the kinks, expecting them to get it together in the limited time between the python release and nov 1 seems unrealistically optimistic about the state of things with that many moving cogs.

To be clear: I did not mean switching to the latest Python version. If the CY2025 switched to Python 3.12 we would be feeling more relaxed about it, as it would mean we wouldn’t be stuck to an security-only version, and we’d received all the other improvements and optimisations.

It seemed to be the plan, but due to an issue with PySide it got rolled back to 3.11: https://groups.google.com/g/vfx-platform-discuss/c/yFbqXs2Pg_o/m/wBd7V8dsBAAJ

It would be really nice to see more proactive involvement of studios in such tech stack, and solve the issues. Maybe it is already the case, and it is just not so very well visible. I don’t know.

Another aspect which feels strange, is: final versions of ACES, OpenColorIO, and OpenEXR are confirmed in early October, OpenVDB in early November. All Python’s starting from 3.8 (that’s as far as the table goes on the Download page) are released in October. What stops Python from being treated same as OpenVDB and confirmed by November?

In any case, I am not sure this is the best place for this topic. For the Blender sticking to VFX Platform would suffice to have undeniable confirmation that efforts and compromises worth it. The exact Python or libraries versions is valid, but a separate topic, I think. That’s why I was asking about possibly making a separate thread.

That’s why I was asking about possibly making a separate thread.

I split the discussion, this is a separate thread :slight_smile:

Ah, lovely, thanks! Somehow I’ve missed that the topic is different when coming here from an unread messages notifications.

I’ll just give my two cents here:

While working with some end users that were not part of VFX platform following studios, the lagging python version of the VFX platform did put up some roadblocks as these “security updates only” python versions are usually not available for download on Windows (at least from the official python website). From what I can tell most up to date Linux distros also drop these quickly in favor of currently actively bugfixed versions.

This meant that they couldn’t really get the same python version Blender uses easily installed and deployed on their Windows/Linux setups.

From my point of view, usually the larger studios that follow the vfx platform has a tight grip on their pipeline. So I would expect these places to be able to compile and deploy Blender with the library versions they want to have. This is harder for smaller studios or individuals.

So the power balance here seems a bit lopsided to me where we are catering to organizations that should have the resources to solve these issues themselves.

Of course I’m not saying that we should go full bleeding edge mode. But I think we could probably be a bit more lose in exactly following the VFX platform, and still accepting patches/reports from studios that use this for their pipeline. (Kinda like we currently do for reports/PRs from Arch/Debian users about ffmpeg versions etc). When or if we deviate that is.

I think it’s unfortunate that Python was not upgraded in the VFX platform this year, and I think there were solutions if the companies defining the platform were motivated to find them and spend the effort.

Still I think it’s very valuable to stick to it.

When the VFX platform was abandoned last time, the feedback from studios was overwhelmingly negative even though there was little feedback before. If there is an idea to change the policy, I really hope there will be active gathering of feedback from studios to avoid repeating this.

3 Likes

Another vote to keep on it, just for consistency’s sake, none of the arguments against/for it we had in the past changed, and last time we ended up on following the platform. With none of the variables having changed, I don’t see why we would end up on a different position this time? Unless we want to admit we just roll a D20 every year to make this call.

2 Likes

It sounds like you already have the feedback from studios to avoid repeating this- if it was overwhelmingly negative last time, why would it be different this time?

2 Likes

You can not be loose. Either you follow, or you not.

Also keep in mind, it is not limited to just studios. Like it or not, but there are things like external render engines people like to use. And there is now extensions platform with wheels. So deviation will have an impact on regular users, or will add a lot of burden on people who maintain addons.

The Linux distros is kind of another topic. The current situation is that they do not really provide the same Blender (as a product) as what we want it to be. Having a .blend file which might not be compatible between Blender’s of the same version just because of the distro difference is kind of confusing. This is a different topic alltogether, but the point is: trying to align to the current state of how distros package Blender will lead to a messy situation.

I totally agree. That’s pretty much summarises my blurb from above.

It sounds like that Python being stuck on an older version for 2025 is more a one off glitch and in theory won’t be the case again in 2026.

So while a bit annoying for a year, it largely shouldn’t be an on-going issue.

Even tho Blender may not hear a lot when it does support the reference platform, if noise levels jumped up when it was dropped, then having support from a long term point of view must be a good thing.

1 Like

Cheers for all the replies peeps!

What I could suggest to everybody is:

  • if you work at a studio where Blender is used in any capacity, please let BF know
  • if you know people who work at a studio that uses Blender in any capacity, see if you can motivate them to let BF know.

Maybe that would justify a tailored survey to see what studios would like to see in version 5.

It is also good publicity if studio names pop up on the main website page…

my € 0.02 :wink:

1 Like

I don’t think anything will go differently if we drop the VFX Platform again. For the CY2025 I think it is too late to consider deviation from the Platform. There is no immediate need for it either: everything works just fine.

However, throughout the 2025 it would be very nice to put a clear end to the debates. Maybe someone just need to make an executive call based on the negative feedback we’ve gathered in a comments to a blog post.

My point is that both the python and Qt version in VFX platfrom 2025 doesn’t have support for non enterprise/commercial customers. Qt | endoflife.date

For the bigger studios that doesn’t really matter because they are enterprise/commercial customers. However for studios and user that are not, this will lead to issues.

So to me it seems weird to in a way enforce enterprise/commercial versions when the users that can use those versions should have the resources to solve this themselves.