New Feature Request: Multi Input Comp Node

Hey all!

Just submitted a request for a multi-input comp node. It would have all the functionality of a comp node but with the ability to add additional inputs (much like in a MUX node). This would significantly streamline and speed up complex compositing tasks as well as simplify large comps. It would also include the ability to re-arrange the order of inputs if needed.

Softimage|DS used to have a multi-input compositing node (with limited number of inputs) and I really miss it ever since.

If anyone else thinks this is a good idea, you can add your vote here:{8fbadb72-c1b4-44ad-b55e-888e3fdc17e4}&t=0&fti=2&d={5d2d5379-eaad-4925-ad97-1f196b820499}


1 Like

Why not just use action?


Simplicity, to avoid filtering and Action always divides the pre-mult input instead of switching the “math” around (could be wrong on this). Comp node, to my understanding “properly” treats pre-mult inputs.

I had issues before with pre-mult sources in action because of this … blurs for example would push through those out-of-range edge pixels in un-mult front and cause bright spots.

I would also assume performance. Action is a 3D renderer. Comp is a fairly basic 2D operation. As you build complex node trees, that adds up.

I like the idea of a multi-input comp node. Maybe instead of expanding the existing one, make it a new one that uses the action style media inputs, priority editor (as you pointed out), and makes it easier to adjust the blend modes - would they all use the same blend mode, or can blend modes be different per input processed?

Upvoted it.

1 Like

Thanks @allklier … yeah Action style node would be great, I thought about that too.
All blend modes would be available per “layer” exactly like in the comp node now.
Mattes would also be combined based on priority order and selected operation respectively.

1 Like

New MultiMerge node in Fusion is a good reference. Like it even better than Nuke’s as you can have parameters per layer. Thinking about the mattes, reminds me of the Phill & Matt topic… not looking forward for that.

By default, I believe Action uses Linear surface filtering, which if the surface is not scaled/rotated/sub-pixel transformed, is essential un-filtered. Try it, do a diff from source to Action output, it is identical. Or switch to Nearest, and don’t move the surface at all.


If you’re not repositioning anything and are just layering things up, you can change the filtering to nearest and you’re all good, no? And I can’t say that I’ve ever noticed any kind of discernible slowdowns from actions vs. comp nodes.

Right … my bad, filtering would be a non-issue in that case.

Can’t this just be done with a matchbox?


I think 2 comp nodes are faster than one multi comp node.
When Action is not an option due to speed, setting up a multi comp node would take at least minimum as much time as just using x-comp nodes. In both speeds: the operator and the operation, using more comp nodes would be faster that way

1 Like

I’m not convinced action would be slower to either setup or render, so long as all the filtering is off and AA is set to 1.


The “Blend and Comp” node lets you comp 2 layers over a BG. That might be a start for you.

1 Like

I think there is a decent use case for a multi-input comp node. It may not be everyone’s cup of tea, and some may prefer other methods. But I don’t see any reason of not doing it for those who would prefer it.

It may come down to prioritizing dev resources, so we don’t spend them on this, when maybe some other feature would be more broadly appealing. But short of that, any reason why not?

Is there a reason I’m missing that this could not be a user MX? Putting devs on this seems like overkill.


Yes, I think there are more options for the user interface to make this an ergonomic node. And for what could be a very basic daily node for people coming from other apps, I think that would be worth it.

This isn’t about new functionality we need to backdoor in. It’s about making something exists more ergonomic.


Any multi input node will have to look like an action (cos fuck the ‘mux with ten inputs’ UI), and the layer UI will have to scale with the number of inputs, I don’t see much time saving happening.

This is before you factor in all the times you might want a repo, warp, or mask.

As for speed, I don’t know that I would feel the difference. Action is pretty fast, and by the time I’ve got a slow setup, it’s likely to be slow either way.



Has anyone actually tested the “action is slower than a comp node” thought that’s being talked about here? I just did a test on my machine (with a stopwatch keep in mind) but they were almost identical if not identical but thrown by my stopwatch hand. This was just front back matte on both.

My experience is that the “action is slower than comp” is like Nessie. Oft spoken but ne’er seen.