ouf this is too much, hiding things won’t help the readability of your setup, did you try using node groups instead ?
1 Like
No but it is planned. The exact design is yet to be decided. In any case I recommend using frames to lay all this out a little more clearly, I wouldn’t want to inherit your comp tree as it is haha
I’ve often wondered if there was a way to use grease pencil to lasso nodes to create a frame? It could be easier to classify regions based on pen colour 
instead of bounding box
I think that would fall under the umbrella of the UI module since this is common to all node systems. As such it is probably not the place to suggest it
1 Like
This is not a Compositor but Shader Editor…
Also that kind of questions belong to a #support section in blender.chat, blenderartists.org or blender stackexchange.
1 Like
I don’t deal much with compositing in blender. I move my render into photoshop and edit there. That’s because what I want to adjust would require me to download or create a complex node group. In contrast, such adjustments are built into photoshop and easy to use.
I am talking specifically about all the controls the “Camera Raw” filter in photoshop has, and blender lacks.
Here’s my right click select post about it:
2 Likes
Yes I’m aware that is shader editor, I just want to show a complicated wires like above image, that image above is basically a screengrab from one of the shader network of asset from CHARGE open movie which released recently.
Yes it is possible to hide those wire. Go to preference , theme and nodetree section. When choosing the wire colour you can reduce the alfa of that colour to your will.
1 Like
They’re asking for a way to hide specific node connections, not all of them. Not sure how you’d be able to work without node connections
Trying to summarize the thread so far.
I. Ideas:
1. Perfomance
- Faster compositor
- Caching system
- Avoid unnecessary refreshs
2. Usability
- Working with masks
– On screen controls for widgets like transforms
– Paint and roto as nodes - Working with nodes:
– Frame node paper cuts
– Better workflow to work with single node (e.g. isolate node then go back to full view quickly)
– Can’t zoom out far enough
3. New nodes
- OCIO nodes
- Time related tools, e.g.
– frame hold
– frame offset - Pixel expression node
- Grid/Spline warping
- Multi-channel support for nodes (e.g. Dialate/Erode)
- Support of arbitrary number of channels
II. Next steps:
Full-frame compositor (CPU) and real-time compositor have come a long way since this thread started. I think the next steps should be the following:
- Performance: Finish full-frame compositor and replace the old one (I can work on this)
- Usability: Revise the compositor workflow. Validate the workflow of working with masks with users using mockups or prototypes (I can also work on this)
- Performance: Caching system
- New nodes
So… what do you think? @Jeroen-Bakker any thoughts from your side on this? Especially next step 1 and 2?
14 Likes
The full frame compositor and viewport compositor are both sharing a similar architecture. The idea is that both compositor engines will be integrated in a single backend. Due to visual differences users should be able to select which on e to use. After this we should be looking into sharing code between the CPU and GPU implementation.
Caching in this term is mentioned many times, and eventually we might need it, just not sure when we have a very fast GPU accellerated compostor, how much benefit it will have compared to the effort it takes to create it. I do believe that there will be cases that we need it, but we should consider how this would work with the described architecture.
I have looked into the mask editing in the compostor and thought adding the same widgets to the node editor was an easy task. Just didn’t had time for the design and prototyping. Painting/Roto as nodes are bigger tasks and require more detailed design. Perhaps make it a separate section in the list 
Multi channel is also something that requires more detailed design and approval as it is different than we have now and should fit well in the ways how Blender works. Other compositors have it, but have designed their whole UI/Engine against that principle. Adding it on top of Blender current design might not be the correct solution.
Pixel expression node is often requested. Not only for the compositor, but also for shader nodes. Discussion here is which expression language to use and how to make sure it is fast.
- compile to node operations?
- Use HLSL?
There are currently 3 teams working on separate tasks I do think we should find a way to work together on these topics with a joined plan. I will check with the others to see how we can do that.
In the mean time improve performance, adding new nodes (within the current design limits), finalizing the full frame compositor can be done without much influence of the design.
17 Likes
@Jeroen-Bakker / @izo – I’ve tried to read back in the thread to see if this was discussed but I haven’t found it, so just adding this perspective for you as you develop new features in case it has not been covered already:
Currently, the compositor in Blender is not as useful as an external compositing application mostly for an easily-solved reason: you cannot quickly use it as a 2D->2D compositing app. What this means in practical use is that you cannot quickly and easily open a new scene, import a few 2D elements, composite them, and render out different 2D elements. You often need to mess around with Blender’s 3D environment to get what you want in the Compositor, and then rendering out multiple 2D elements takes a lot of juggling in the render settings. Also, you cannot easily render farm a .blend whose only purpose is to do some 2D compositing, especially if you want to render out multiple elements such as a composited beauty render and some custom mattes for use downstream.
This could be very simply solved by decoupling the main Blender render settings from the Compositor’s settings, perhaps by adding a Render node that allows one to set resolution, file type, bit depth, color, file path, embedded render layers, etc. per output, so the user can define multiple outputs from a single comp setup.
If this has been discussed and is being solved already, I apologize for not finding it above!
8 Likes