It would help tremendously (for real this time), if the age old “multi-input in op” RFE could get a priority bump.
For starters, a CHOP version would be enough
Thanks!
Achim
It would help tremendously (for real this time), if the age old “multi-input in op” RFE could get a priority bump.
For starters, a CHOP version would be enough
Thanks!
Achim
in case we get a multiple select DAT, then a multi-input inDAT would be even more useful than a multi-input inCHOP
How exactly would this work? Wouldn’t you still need multiple In* nodes inside the COMP to access the channels, or would they merge them?
yes, they would merge. For
DATs:
appending rows should be enough (but if it’s not a big deal all options from the merge DAT in the multi-inDAT)
CHOPs:
just merging channels like in the merge CHOP, no other options really needed (but maybe the “align” and “duplicate Names” should be there)
Currently I would have no use for multi-input SOPs and TOPs, but if, then
SOPs:
just like a SOP merge, no options
TOPs;
hmm, maybe stuff all into a cache/texture3d?
This seems like duplication to me though. Why not just use a Merge before the In* outside the COMP?
yes, it’s a duplication, but an important one. If you publish a component, I don’t think it’s a good workflow to force your users to read it’s help just to discover that they need to manually create a merge op and wire it up to your component, … after all a component should contain everything needed to perform a certain task. Imagine that foreach blend SOP/blend CHOP you wanna use, you’d have to create an additional merge OP…
Another idea. A multi-input inOP wouldn’t actually make any data available. Instead you’d have to point an info DAT to it and it would give you the fullpaths to all connected OPs (or you use a new expression: “opinputlist” on the multi-input OP). Than this list could be used in a multiple-select OP to actually get the data from all connected ops. But that would require multiple-select options for all type of select OPs (maybe also some basic merge options). Just thinking out loud.
Say you always have one unconnected input. Then for In DATs you make a DAT Execute DAT point to the last unconected input (say it’s in2).
When an node outside the component is later connected to the input, then in2 will trigger the DAT Execute DAT to run, where you can merge in2 to a Merge DAT, add another In DAT, and point the DAT Execute DAT to it.