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.
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?
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.
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.
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
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?
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.
