Working Netboxes: part 3 — Get One.

What’s selected: A way to query selected network boxes is essential for the interactive shelf buttons, in oder for there to be an easy way to pass network boxes as well as nodes for operations. This is another one of those things we expect to do because we can with nodes, but cannot. We can however check if a netbox is selected…

# check if a network box is selected
my_netbox.isPicked()

… so we need to gather a list of network boxes and return only the selected one by testing via the isPicked() method. This was the motivation behind the creation of ui.py mod. It currently contains two more general functions

  • paneTabsOfType() — while there is a function that return the first panetab found this one returns all.
  • currentPaneTabsOfType() — builds on paneTabsOfType() but only return those active (pane tabs in the foreground)

… so selectedNetworkBoxes() is the new function to return a tuple of hou.NetworkBox objects similar to hou.selectedNodes() or hou.selectedNodeBundles() by gathering the network editor paneTabs, retrieving the network boxes shown and checking their selection status. Since the related provided methods exist at hou.* level, similarly in addition to existing in netbox.py its imported to the lib root as eyevexTools.selectedNetworkBoxes()

Since, unlike the provided methods for node selections, theres no reliable way to know what the last selected netbox is, a GUI dialog requesting which is the destination netbox was created to the merge button. This lead to the creation of the ui.py module where these specific dialogs are now stored.

 

eyevexTools selectNetboxFromListFormMerge dialog

eyevexTools selectNetboxFromListFormMerge dialog

A netbox has  more in common with a sticky note  than a node. While network nodes, like subnets, are a type of node that can contain other nodes — this is obvious when we use them. However subnets also contain network boxes. These are not considered children. and when listed ..

# list all child nodes of a network node
my_subnet.children()

… only hou.Node types are in the tuple returned, even when networks boxes are present. They however can be listed …

# list all network boxes in a network and store result
netboxes = my_subnet.networkBoxes()

…. we can then get the nodes within a box…

# store a tuple of nodes contained with in the 1st returned netbox
my_netbox = netboxes[0]
my_netbox_nodes = my_netbox.nodes()

if any of the nodes returned are also a network, its children could be listed in so on. If we want to go from one of the nodes in my_netbox (also a child of my_subnet – remember netboxes aren’t part of the hierarchy) back to my subnet we can grab a ref with a hou.Node method parent() which is the counterpart to children()

# get the parent network from a node found in a netbox
my_node = my_netbox_nodes[0]
my_nodes_parent = my_node.parent()

this makes logical sense, as if we can go inside, we expect to be able to get back outside. However there is no similar counterpart to networkBoxes() method of hou.Node, so while we can get membership from a netbox — we can’t find the network box from one of its members. We might expect that we could because of our previous dealing with nodes. Fortunately Houdini will allow us to make this happen.

Two new functions are introduced…

node.evt_networkBoxAround() — eyevexTools function (shown with the method prefix) returns the netbox which the node is a member Since it has no hierarchical  function this isnt really a ‘parent’ but can losely be thought of as a sort of Uncle.

node.evt_networkBoxAbove() — eyevexTools function (shown with the method prefix) returns the netbox above the node – the node is the boxes ‘under-node’ and ghosted out.

For networkBoxAround() we need to find a netbox from one of its members, we do this by moving up one level, gathering all the netboxes and the looking amongst each members untill a match is found. a similar technique is employed in methods mentioned in the last section to find under-nodes by checking if each at a level fall withing the bounds of a netbox.  These aren’t  very algorhymically efficent but in a common technique in practice when necesary to search for somehting. There is a practicality and the trade off in time invested and in noticable gain. And for the moment, it scales ok, and can be improved upon to scale better later.

networkBoxAround() and networkBoxAbove() along with layoutNodes(), nodesOverlapping() and nodesUnder() form the basis for which most of the other custom function buld on and are what allow us to get a networkBox

The last section will look at the shelf tool use….

 

Leave a Reply

Your email address will not be published. Required fields are marked *