So got around to using Blenders compositing features and think that there should be a fork where it’s just Natron nodes and GUI. Never attempted a marriage of two software like this before so wanted to ask y’all what
I should look out for in terms of hurdles and canyons.
We have discussed this in the community before, and personally, it’s a no. Here’s why I think so:
The reason Blender’s compositor is the way it is, is that it’s not meant to be a fully fledged compositor. It’s basic enough that everyone who’s familiar with the Blender nodes will know how to use it, and just good enough that you can do the bare necessities of post-production with it. Also the real-time compositor part is not WYSIWYG but that’s a discussion for another day. It’s a similar story with the VSE. This philosophy fits into Blender’s overall generalist (do-it-all) philosophy. It doesn’t have all the bells and whistles that a specialist compositing software does, and it’s fine because everyone who has been using Blender for long enough doesn’t expect it to.
Natron, similar to Nuke, Fusion (Studio), Flame, etc is a standalone specialist software, similar to how Autodesk 3Ds Max/Maya are for 3D CGI. They don’t follow Blender’s do-it-all philosophy. A lot of people (myself included) have been upset at the lack of proper (OCIO) color management in Blender’s compositor, and frankly that is why Natron (and other compositors) exists as a standalone application. Again, Blender developers don’t expect you to use industry standard workflows in Blender, which is why things like proper color management have been overlooked. Everyone who wants to do more complicated compositing tasks will use something like Nuke, Fusion, Aftereffects or Natron, where the more advanced tools, and capability for complex workflows exist.
Integrating Natron inside Blender will not only violate Blender’s philosophy, but also Natron’s. Blender’s compositor needs to exist as it is, or in some better form while still maintaining its current workflow and usability, and Natron needs to exist as a standalone application.
There is a reason no sane person in the industry wants Nuke integrated inside 3Ds Max/Maya. There is no reason to do it, it will not make the workflow any better (EG. take a look at how sh*t the Fusion workflow is in Resolve; there are so many incompatibilities and inconsistencies between Resolve and Fusion that half the time, doing anything in the Fusion page will essentially make it destructive for the Color page), it will add things to Blender that it does not need (it will be bloatware for a lot of people), and most importantly of all things, it will be a maintenance nightmare considering the frequency of recent Blender updates.
Overall, Blender’s compositor is easy to use for someone who is used to Blender’s nodes. It does the bare necessities well enough for most people, and the performance isn’t really as bad as many people make it to be. If anyone needs to do something more complicated, they probably already have Nuke/Fusion/Natron and the know-how to use it. And an industry standard interchange workflow (OpenEXR) already exists, and is supported by Blender’s compositor (RenderLayers + File Output node).
1 Like
Ok yes valid arguments you have as well as personal opinions. How about an OpenEXR based interchange between applications that supports updates after every parameter click drag and viewport ui tool change? Once you change something in one application the render display buffers feed automatically to both or multiple viewports?
Let’s put more stuff inside Blender ( "Jack of all trades, master of none ") 
On a serious note, there is not enough resources to even maintain Natron, so don’t expect development/feedback on this.
Both Blender and Natron supports Python (scripting), so … 
2 Likes
You’re missing the point of Compositing. It is a part of post-production. Even in Blender you can only use the compositor to it’s full potential after you have rendered the scene (which is the end of the production phase). Blender’s realtime compositor (compositing output in viewport) is close to useless, since it is not WYSIWYG, and is technically also applied on top of a render. It is more or less there to facilitate virtual production workflows which are the craze nowadays.
There is no reason to switch between Natron (or any other compositor) and Blender in an OpenEXR workflow. Once you have EXR renders, you’re done with production and are moving to post-production. You need not touch Blender again unless you need to re-render an element or the entire scene for any reason.