It would be great if some sort of multi-input support would be available for COMP operators.
Imagine situation where you would like to use GLSL Multi TOP inside of Base COMP. Lets say you are feeding 20 TOP inputs to this GLSL Multi TOP.
In case of GLSL Multi it is quite easy to work with these inputs. You can select all of them and connect them at once. However this is not the case with Base COMP. You have to create 20 input TOPs inside and manually connect each wire to Base COMP inputs (which is not convenient).
Let’s say you did all of this and manually connected 20 wires (one by one). Now you decide you want to connect different inputs. In such case you would have to manually disconnect each wire (I guess this could be only done by right-clicking on it and selecting Disconnect) and then manually connect another 20 wires. This could get difficult to control very fast.
I would suggest implementing two things that would make such situations very easy to manage. One of them would be some sort of Multi In TOP. It could have its own callback DAT (where anyone would be able to handle logic of connecting its output wires properly using Python). This way user would be able to connect all wires to COMP multi-input at the same time - just like with GLSL Multi.
Second tool would be part of network UI itself - capable of “cutting” wires. For inspiration please feel free to take a look at similar feature in Houdini, where user could hit Y and drag over wires to disconnect them.
Network Editor in Houdini - cutting wires
I believe these two features would make working with many wires much more convenient. Thanks for reading trough this
totally support this idea, im working on a project that I have to disconnect several wires from a comp to test somethings all the time and its really out of hand
+1 on this
I have ran into several situations where I wanted my developed component to dynamically handle arbitrary amount of inputs (of the same type).
+1 too, is there any update on this?
First off - is an option not using inputs but parameters? While currently a bit misleading, you can create a custom parameter for any operator family type, for example a TOP type, and specify multiple operators in it - say:
moviefilein1 moviefilein3 null4.
While the operator now has a warning attached, you can actually use the
myop.par.Mypar.evalOPs() to retrieve the operators for all the operators referenced in the parameter.
With this, inside a component, you could use Select OPs to fetch from the right locations.
Otherwise, to drive this idea a bit more forward and all of this being hypothetical
- you would still create In OPs inside the component
- In OPs could be “grouped” to create named multi component inputs.
- each multi input group has it’s own label
- each group could be exploded to again be displayed as individual inputs
- no python needed
- the workflow is as before
- you get the multi input ui for each input group.
- visually communicating when it is “full” or how many inputs are required
- you loose the idea of what goes where - you have to first explode the input group before it becomes a bit easier to analyze.
I would want to understand more specific use cases - can you guys describe where you see this requirement and why selects or parameters would not be the better match?
@snaut this sounds interesting - I didn’t know about
evalOPs(). However when dragging multiple nodes to a parameter of operator family type, only a single one gets filled in. It might be a bit tedious to write all operators manually there. Maybe it would be good if one could drag and drop multiple nodes into such parameter?
These custom parameters are not yet really made to support it — despite evalOPs working Ok—ish…
I didn’t know about
evalOPs(), which I’m trying out now. As for the hypothetical approach, it sounds like a pretty decent approach!
In my use case, I was building something like a composite TOP, where an arbitrary amount of inputs can be mixed together (with a script TOP). I’d be using
inputs list to iterate through all the connected TOPs in python code with
numpyArray(). If this becomes a COMP, I cannot feed in a multi-input connection from outside the COMP, into a multi-input TOP such as the script TOP.
For a while, I went with a workaround where instead I had a single TOP input, with an implication that outside the COMP it is immediately connected to a hacky “null” TOP with multi-input capability, such as composite or layout TOP. Then my code was going up the chain of connections with
inputConnectors and etc to read the
inputs of such hacky “null” multi-input TOP.
What I’d be concerned about with TOPs par type, is the cook dependency. Would a script TOP in such case know to cook in the same logic that regular dependencies through TOP connections would lead to?
I guess ideally, there would be a multi-input IN operators, and equivalent “input select” operators to select a specific single input from it. Finally, the icing on a cake would be if such multi-input IN operators could be directly connected to the usual multi-input operators.
+1 for this. I’ve had several effects I’ve wanted to “containerize” into bases for my palette, some of which could be even more useful/powerful with an arbitrary number of inputs.
Having an OP param is a poor solution because you have to type in each op’s name manually. You miss out on “I want to quickly select many OPs and drag them over as inputs.” I could maybe do something hacky with the drag-and-drop overrides? …but… yuck.
Do you have an example of this implementation?
find it here attached.
opRefExample.tox (1.5 KB)