> - Allowing the plugin API itself to not be beholden to GPL. This stops a lot of commercial plugin developers from supporting Blender.
Chaosgroup solved that problem by using the process boundary. They have an integration plugin in GPL and then execute a standalone version of their renderer that they offer separately.
Which works fine for a renderer where you're typically serializing the scene and transferring it over anyway.
It's not as tenable for things like deformers etc that need to feed data back in to the scene every frame. Well.. at least not without severe performance repercussions.
As long as it can be streamed or batched you can get pretty much the same throughput with IPC. Only latency suffers slightly (microseconds, still within a frame budget even for realtime use), but you only pay that latency overhead once per batched action.
- having a stable plugin API that is not Python based is a must for many studios that are working with large computations. A stable C or C++ API is a must for them, versus having to patch and recompile the entire application from source.
- Allowing the plugin API itself to not be beholden to GPL. This stops a lot of commercial plugin developers from supporting Blender.
- Better large scene performance. Right now blender absolutely chugs compared to commercial apps when your scenes get larger
- better undo performance because it's effectively saving a copy of the whole file again per undo.
- potentially more ingrained support for Pixar's USD toolset including a Hydra stage view. Which would open up access to a lot of commercial renderers, but also offload large scene handling to the Pixar stack instead.
The leadership have been resistant to a lot of these over the years. But they seem to be coming about to the value of playing well with existing toolsets rather than being the do-it-all that doesn't fit in well.
I am hopeful with their current trajectory after the revamp of the 2.8x series that it'll see further advancements in the areas I mentioned.