Vfx Platform and blender dependencies.

Hi guys, is there any plan / interest on aligning blender dependencies to the http://www.vfxplatform.com/ ? (mostly CY2019 due to the change to python 3.5/6 if I’m not mistaken)

I know is mainly for plugins compatibility, but guess would be a nice sign from the BF to show interest in the vfx industry standard… and hopefully back.

Cheers.
L.

I think Alembic is the only important lib to make compatible in this list.

Python could have been, Shotgun is python 2.7 and you can’t import shotgun API into blender. But now that we are 3.5, let’s wait for 2019…
For other library in the list, I don’t see the need to be compatible with others , and many of them aren’t used in blender anyway.

From the link : “Its purpose is to minimise incompatibilities between different software packages, ease the support burden for Linux-based pipelines and encourage further adoption of Linux by software vendors.”
I don’t think installing or running blender as ever been an issue under linux too.

I’ve had a long think before posting this. And just for the record, I don’t know any of you and don’t know your history. So take this as a comment from someone who has been working with vfx for 20 years in many different studios around the globe.

If you think of Blender as a singularity this might be true. And I have also heard Ton saying many times that they make Blender for users and not to “fit in”… or something like that, you get the idea. Here lies the problem that I have with Blender being so off the map from the VFX Platform. We who are in the industry and doing high-end effects for blockbuster films, tv-series and also users who are at major league gaming studios are blocked from using Blender because of this.

For 10 years I have been trying to get Blender into various pipelines, but failed over and over again. Not due to that the company or users didn’t want it. But because you just could not get it into the pipeline. So what’s happening now is that the decisions to not follow the mainstream DCC applications has blocked Blender users from using it.
Just last month we were going to evaluate again how to implement Blender into our pipeline and workflow. This due to so many artists actually want to work in Blender or they want a chance to learn and use it in production. But since so many libs and especially Python being so far ahead from everyone else you just can’t get it in.

These days loads of companys are open to OpenSource in production, I mean… where do you think Alembic and OpenSubdiv comes from? OpenColorIO, EXR, etc, etc. I mean, LINUX! it’s OpenSource and used everywhere! We know it’s not free as in “free beer”, we need to maintain it ourselves and we need to be on top of the development and also contribute to the development. License fees are then transfered to development time instead. It’s the same $$$ that goes into it. And it’s not like Houdini or Maya are finished products, we spend loads of development time to add our own plugins and shaders to both of these softwares. And we have people on staff 100% of the time to just do that, even though we pay subscriptions and annual software fees to the vendors.

Blender has proven it self over and over again to be a very competitive alternative to other commercial alternatives. No one thinks otherwise. But if we can’t get it compatible with the rest…

So please don’t say that Alembic is the only lib that is important. That’s just being selfish and looking only at yourself and Blender as a singularity or it’s own island. We need to be compatible with a lot of things so that we (which I think would be hundreds of users around the globe) can start using it at work and that our work can be tracked and versioned by our in-house tracking system. That our work in Blender can be integrated with our in-house asset systems or our render farms dispatchers.

my $0.02

Thanks for reading to the end

best regards
stefan

I just can say that I completely agree with you Stefan.

Cheers.

:yes:

Me to.

Plus 1. :slight_smile:

Glad to see someone coming from a similar background and getting on the same conclusions :wink:

As you , I’ve been trying for years to have blender as part of the various production pipelines I’ve been working/developing with/in and one of the main problem has always been the library stack compatiblity. (still, I’ve been using it many times to sort out little issues.)

Thought this discusion wasn’t going to get anywhere, glad to see I was wrong.
Cheers!
L.

I’m afraid we are talking to deaf ears though. This has come up before but no discussions has risen from the devs. Maybe they don’t see the benefits.

regards
stefan

It could be great to have someone from BI here just to talk a bit about this

cheers

It looks like the devs don’t read this forum anymore, mostly, due to several reasons… also, in the last years the Blender Institute switched to an animation studio no more really interested in suggestions (and requests) from the community, they are doing the software they need for their own purposes, that is to produce animation cg movies and not visual effects.

Ok, sorry … and thank you for the explanation StephanA…

Can you be more specific on how not being compatible with these librairies cause issues ? For python I understand, I had to make blender and shotgun communicate and that was very limited because you can’t import shotgun API into blender. So I end-up executing python 2.6 scripts that fetch SG data and then read that back into blender , with a JSON text file as an intermediate.

I guess PyQT and QT not being into blender is another issue ? because many in-house tools use these libs. But I guess here it’s a dead-end because blender as is own library to display the interface, and it’s not QT compatible. I don’t know what amount of work is needed to bring it in. But if I understand correctly that would mean a major recode of the OpenGL library that display the interface, that as an influence on the whole software.

FBX is another special cases because blender can’t be opensource and use FBX SDK at the same time. Blender also can’t allow you to write C++ plugins, so I guess C++,Boost and other libs related to plugins development in the list aren’t relevant. And Ptex,ACES, OpenVDB aren’t there …

I guess it’s how blender is designed from the ground that make integrating these libs (QT,C++ API ect…) complicated and lead to having blender isolated and not being able to fit into an existing pipeline. But maybe at some point to be able to be compatible with these libs would mean rework a too big part of blender, leading all the other parts that need developments behind. Maybe blender isn’t enough funded to allow such a work.

Great thread.

  • I do agree some standards are still missing - e.g OpenVDB. Currently it’s very hard if not impossible to get certain voulmetrics to Blender. Clouds? Dust from Fragmentation/demolition? Spray/Mist of Fluid simulations - all of this is made very difficult.

  • I also agree that Python upgrades should be done with respect to the vfx platform standards. Currently It’s significantly clunkier to innerop with Houdini and also maya in some circumstances. They are on 2.7/2.8 and directly doing something like “import hou” will end badly. However it seems 2018/19 others will catch up. Problem solved?

-I use pyQT in Blender, but it was not easy. Some of the problems that I faced was that the Dialogues summoned are not native (just floats as always-on-top separate app with a lot of management needed to make it work(hide/alt-tab etc)), certain CONTEXTs are NOT accessible and require workarounds with communication with Blender being more difficult than it should (e.g often main script has to be in Modal ). I feel Developers should find time to make sure painless integration is possible and DOCUMENT it, something that currently is lacking.

These are the main areas that have affected me. I’d be more interested in hearing what others have to say. However I would like to praise development for Alembic and a lot of the other efforts that have made Blender more accessible in various pipelines.

This is mostly Linux platform nonsense, it’s a non-issue on other platforms. Linux distributions often make it difficult to have more than one version of a library installed (in the intended and supported way). Developers making the heavily misguided decision to rely on the distribution to provide these libraries must adopt their application for particular versions of particular distributions. In effect, commercial applications often only support a handful of distributions (in certain versions, often outdated), while free software often relies on the distribution package maintainers to provide the software (in certain versions, often outdated and often modified). It’s utter madness.

Blender instead ships its own version of these libraries, so there is no issue having them installed system-wide as well, plus the binaries work on most distributions, plus you can have multiple versions of Blender on the system. However, supporting this also comes with a development burden.

It’s actually a issue on all platforms. If you have different versions of various libs you can get into problems. Alembic, OpenVDB, EXR are prone to have different attributes in them. So if you don’t match these it will cause a problem when you share data between applications. Same goes for Qt and Python.
With Blender the biggest issue that has prevented me from integrating it into the production pipeline would be Python. That is a complete blocker, second issue would be the lack of Qt/PySide support. Third which is almost solved and fully featured now would be Alembic.
But the decision to go Python 3.x long before everyone else was a bit of a downer. This completely blocks me and the development time to get around it doesn’t make up for the value that Blender will bring to the production.
Also not having Qt/PySide support is a bit of a problem since many external tools uses it. And it would make things easier to have the same Tool UI in regardless what application you are using (this is mainly for data extraction/pipeline work).

It’s a real shame because I know a lot of artists that are willing to use Blender (in many different areas).

Another issue would be that Environment variables aren’t supported fully out. This is one of the backbones in production pipelines to be able to use Environment variables that you can change per shot/scene/project/etc.

Next iteration of the VFX Platform is going to include Python 3.x, so hopefully in a year or two there might be a sync between Blender and the rest of the world.

regards
stefan

Hi StefanA

>> Another issue would be that Environment variables aren’t supported fully out.
I fear I’ve been missing this one… do you ming elaborating ? eg… can I use REZ to setup my blender startup ?

>> Next iteration of the VFX Platform is going to include Python 3.x, so hopefully in a year or two there might be a sync between Blender and the rest of the world.

During this siggraph’s birds of a feather at has been decided to go for (Hope I remember right) 3.6 for CY2019
Guess it’ll be nailed later this year in the ML.

L.

The early move to p3k has been my showstopper to try to integrate blender nicely in pipelines.
(please avoid saying you can with py3 with subprocess solutions as company don’t like to mix an match these things)

This is a completely different problem (library authors being unwilling to maintain a modicum of backwards compatibility).

On Windows or Mac, it’s common to either have multiple versions of a shared library installed (e.g. side-by-side assembly) or to just bundle it with the application.

On Linux, there’s a misguided attempt to just have one version of a library system-wide. Developers who follow this path of peril end up needing to explicitly support different versions of different distributions with separate packages. There are efforts to provide a rational solution for this (e.g. AppImage and several others), but they’re the exception not the norm.

With Blender the biggest issue that has prevented me from integrating it into the production pipeline would be Python. That is a complete blocker, second issue would be the lack of Qt/PySide support.

PyQt (not sure about PySide) actually works within Blender, it’s just not so trivial to set up properly. Why do you need it to be a particular version?

Third which is almost solved and fully featured now would be Alembic.

Integrating a library into an application is also a different topic.

But the decision to go Python 3.x long before everyone else was a bit of a downer. This completely blocks me and the development time to get around it doesn’t make up for the value that Blender will bring to the production.

I don’t think the expectation when migrating to Python 3 along with the 2.5x refactor was that everyone would be that slow to adopt. Python 3 was a worldwide disaster though, can’t blame anyone in particular.

Also not having Qt/PySide support is a bit of a problem since many external tools uses it. And it would make things easier to have the same Tool UI in regardless what application you are using (this is mainly for data extraction/pipeline work).

Again, why does it have to be a particular version? If it’s the Python2/3 issue, then the point is kind of moot. Blender isn’t going to migrate back.

Maybe the problem is that there is no good example on how to do PyQt with Blender.

It’s a real shame because I know a lot of artists that are willing to use Blender (in many different areas).

If I had a dogecoin for every time I’ve heard this argument, I’d be a wealthy man.

Another issue would be that Environment variables aren’t supported fully out. This is one of the backbones in production pipelines to be able to use Environment variables that you can change per shot/scene/project/etc.

I’m not sure how that’s not possible, but if your pipeline relies heavily on environment variables then it is bad and you should feel bad.

  • 1 from me on aiming to comply with the VFX Platform. If nothing else at least Python. But I’m talking in 2019 when the platform upgrades, pretty sure it’s going to be 3.6. I’m in the process of writing a project management tool, the goal of which is to be accessible in as many DCC’s (3D and 2D) as possible. Right now Blender is the only application that can’t be supported until at least 2019 (unless experimental branches using 2to3 are made). Lack of built-in PyQt/PySide support is a bit of a bummer as well.

I’m interested in your reasoning for this. Pretty much all applications I use have environment variables for enabling/disabling/setting functionality, and they are the only truly cross-platform tool that I know of for maintaining environments. That goes for toolsets, storage, system management. If you have a solution that is more flexible, is cross-platform, and is incredibly easy to setup I think everyone in the industry would like to hear it. I have yet to see a pipeline not rely on environment variables. The PM tool I working on uses them extensively.

Environment variables are a pain to deal with and error-prone. It’s such a lazy and primitive way to do configuration that it won’t be enough for many use cases, so you inevitably end up with some other form of configuration next to it. At that point, you should seriously question their use.

Now, whatever “the industry” does and how well environment variables are (or need to be) supported is a different story. Of course programmers will be lazy and use them until they permeate the pipeline.

If you have a solution that is more flexible, is cross-platform, and is incredibly easy to setup I think everyone in the industry would like to hear it.

Those are too many conflicting requirements. First, ask yourself: Why do you need all these configuration variables in the environment? There are cases where they are “best” choice, but much more often command-line arguments and configuration files are the better choice. I’m not saying you should never use them.

You are absolutely right. And from my point of view (havin’ had 35 years in Database-Enviroment) I’d like to add, that enviroment variables in nowadays enviroments are outdated like steam engines on high-speed train tracks.

So what is the solution then if we are not using env variables?