You know how Box#3 has the multiplier on the outputs… Something like that would help my MagmaFlows a lot. I have too many Invert and Multiply nodes. Just an idea…
- Chad
I’m not a fan of the “kitchen sick” approach, where these sort of features just get tacked in and over-complicate a node’s behavior. My philosophy is that one node should do one thing, and in general we try to stick to that. That being said, it is fairly straightforward to drop an invert node or a multiplication node and bundle them into a black-op to get this sort of functionality. It should be as simple as selecting the node in question, hitting ‘*’ then ‘f’, then selecting the three nodes and right-clicking and hitting [Blackop].
It’s just a matter of having 1/3 fewer nodes to watch/organize. By removing those incidental nodes, you end up with a cleaner, easier to read setup. If you can make a uniform, compact interface for it (not unlike Box#3?) it’s not obtrusive. Heck, when the arity/type isn’t changing (most of the nodes) it would be nice to have a Fusion-esqe blend slider, so you could better understand the affect of the node.
- Chad
Darcy is speaking from compiler’s point of view, not from the UI POV (that’s my area 
).
What he meant was that we wanted to keep internals of a node as simple as possible for two reasons - simplicity and speed. (KCMs are already almost 3 times faster than comparable Box #3 flows). If the node had a built in multiplier or other modifiers like invert etc., that operation would have to be performed by EVERY node even when the multiplier is just 1.0, or a condition would have to be built in to turn the behavior on or off which is typically even slower. We’d rather let the user add the multiplier when needed at cost of flow complexity, but get the best performance in the cases when multiplication is not needed. In this respect we are going more Nuke or TP than Fusion or PFlow.
Are the KCM’s reduced in any way before processing? Meaning, if I string together something like “((((x*2)/2)+5)-5)+7”, does that reduce to x+7?
And is there a penalty for leaving orphaned nodes, or passthrough nodes?
- Chad
There is no such optimization pre-processing, since we don’t operate on an expression like you provided above. The flow is compiled on the fly and every Operator that is on will be applied to the data. There should not be any measurable penalty for pass-through nodes (although I could be wrong). Orphaned nodes are completely ignored.
Darcy can explain much better how the compilation works.
In the version of KCMs that will ship at SIGGRAPH, there will be little optimization. Currently there is not even constant folding. We are in the process of migrating our back-end to use the LLVM compiler tools (http://www.llvm.org) which will significantly improve the performance and optimization options available.