Hey folks!
Its been a while once again since my last post. Life got in the way again, quite literally this time, as my son was born just after new years! Hes super cute and very demanding! I did have the occasional spot of time to continue working on this plugin though so heres the update.
I took a step back a little and developed a tool to manage my plugins (spoiler!). I was often wanting to toggle settings with a nice little UI when trouble shooting, so I bit the bullet and built this thing. The nice part now is the UI dynamically builds itself based on a .json file. That way I can easily add modules or settings without having to rewrite any UI. From here on named bwTools!
But back to the main topic...I did a sort of re-write once again. After struggling with ironing out bugs, my logic was becoming very specific. So I went back and tried to simplify how I reason about the graph. Now instead of making an best guess about what a lane through a graph should be, the plugin tries to figure this out itself. This results in much more structured and understandable layouts. I am still doing everything is passes though, as this lets me make some assumptions about the state of the chain, so it was more of less the logic surrounding what a lane structure is that has changed.
Briefly, I first order the nodes into a proper hierarchy, then consider any chains that are deep, to more likely on the mainline. Sprinkle in some awkward setups such as chains equal in length, connecting to numerous parts of the graph or belonging on a different lane entirely and you a logic nightmare to solve!
You can notice on the .gif below however, that the blend nodes do not always assume the middle input is the mainline anymore. The other inputs also respect location and shift accordingly.
So if it does consider all the branches of a given node to be equally important, it will now divide them instead of trying to make lanes
With this, comes proper support for any number of inputs
Height has also been implemented, but with some drawback, unfortunately. There is no way of knowing how many input and output slots are actually visible and a lot of nodes have visibleif statements setup. The only information the API provides is the total number =( Until this gets added, I just had to reason on a node, assuming all slots are visible.
Another big challenge came with nodes that output multiple numbers to the same node. So now I try to make an educated guess by weighting all the inputs/outputs relative to each other. At the very least, it gives me a single value to work with, making it much easier to position nodes consistently.
So I still have an awful lot of weird bugs and behavior to figure out. I am trying to keep the logic as node agnostic as possible though and the results are starting to feel a lot more natural I think.
Thanks for reading