search

GafferHQ / gaffer

Gaffer is a node-based application for lookdev, lighting and automation
http://www.gafferhq.org
BSD 3-Clause "New" or "Revised" License
957 stars 206 forks source link

Filtered Node Graph for Executables #1010

Open andrewkaufman opened 10 years ago

andrewkaufman commented 10 years ago

This should be a new pane which only shows the Executable nodes (or boxes containing and exposing Executable out plugs) with their requirement in/out nodules visible but the other nodules hidden (e.g. ScenePlugs).

@johnhaddon let me know if you'd rather this just be in Caribou, or if you're ok to have it in Gaffer.

johnhaddon commented 10 years ago

I'd like to discuss the requirements and use cases a bit before figuring out where it's best done.

The NodeGraph does already have the capability of filtering out certain nodes, but that's not exposed to the user right now (we do use it in Jabuka though). In that mode, no nodules are hidden though - any connections into them are just drawn as stubs instead. Additionally, the layout stays the same, so you would potentially see a very sparse graph of Executables a long way away from one another. Could you tolerate visible but stubbed nodules? Were you imagining a more compact layout?

I did wonder about having something similar to what you mentioned in the Dispatcher UI somewhere at some point - so it would only show the nodes being Dispatched, not all the Nodes. It might make a nice natural place to show the progress of local dispatches as well. Are you thinking of similar use cases to this or something else entirely?

andrewkaufman commented 10 years ago

Yeah, its for last minute verification of your per-node dispatcher settings, without the clutter of the whole graph. Personally I'm fine with the stub connections, but I think a more compact layout would probably be essential.

johnhaddon commented 10 years ago

So are you planning on using the auto-layout algorithm to produce this more compact layout? Currently there's only one node position per node, which would present a little hurdle to that approach. I guess we'd also want the compact layout to be very similar to the full layout in terms of left-to-right ordering of nodes etc? I'm not sure that would be particularly straightforward either…

Has a simpler "list of nodes" interface been considered at all? What would be the disadvantages of that over a graph for these pre-dispatch checks?

andrewkaufman commented 10 years ago

Do you not recall talking me out of the list of nodes approach? I've since pitched this to Yuta and talked him out of the list/table as well. Basically the issue was what info to represent in that list, and how to represent it when there are all sorts of executables (not just renders).

I guess I was hoping the autolayout would pick a nice ordering based on the requirement connections, and that would most likely match what the user had done manually, or be an even clearer representation. But you're right, I don't have a good idea how to get around the one position per node issue...

johnhaddon commented 10 years ago

I recall talking you out of the table of nodes approach, because for non-homogenous nodes it doesn't make much sense. Just now I was thinking about a list of just the node names, from which you could pick a particular node to view in a NodeEditor. Which would make some sense, but perhaps not be as nice as a graph. That's assuming the graph layout wasn't so different that you no longer recognised it - you'd only need one crossed connection in your manual layout for the auto-layout to be inclined to go another way and to potentially be a bit confusing.

I guess we could deal with multiple node positions by either making a separate dummy node graph to mirror the original, or by making it possible for each GraphGadget to store/manipulate a different set of positions. I think the latter would be a bad thing if we exposed it via the NodeGraph, but it might be justifiable at the API level for enabling this kind of thing. I'm not sure how I feel about a dummy graph - on the one hand it seems a bit odd, but then again it might be quite handy if we want to go further with what we display in there - maybe each ExecutableNode could even be a box and you could go in it to see the individual tasks or something?