Motivation: (imo) Houdini's proceduralism is bottlenecked by the lack of manual input nodes, nodes that allow you to edit what you see in the viewport, place things where you need them to be without having to patch the network for every adjustment.
The handles and viewport interfaces that exist are either specialized (Curve SOP, Retopo SOP), or limited to single operations that end up scattered throughout the network. I often find myself in the situation where I spend more time navigating the node network, than making edits. HDAs are best at gathering parameters, not great at viewport editing interfaces.
You can always push this type of edit work to other software, such as modeling your network input geometry in Blender, but I find that good decisions come from rapid iteration, and the extra export/import makes for a low "quality-of-life" type experience.
The scope of the UI issue is obviously vast, with lots of opinions out there. I tried to address a Houdini limitation that involves editing elements (placement, adding, deleting, moving). Making the argument that having nodes that act as "single-node-editors" is a great way to integrate manual control with procedural networks, while keeping the networks clean and minimal.
The plugin/HDA:
The solution I went for enables an "Object" like editor at the SOP level. It works on packed primitives, as they can contain pretty much anything. The node then includes a python viewer state that implements Blender-like handles and viewport features to edit the packed primitives. This provides transform operations, and operations for adding, deleting, duplicating etc.
The node takes an input of named pieces `s@name`, and provides an interface for editing these. It's similar to a Copy to Points SOP, but with a built-in stash and editing features. It is light weight since the only data it stores is the point-cloud describing the composition of the instances. The node outputs either the instanced instances or the point cloud with instancing data. What you get is a way to edit the placement of the pieces, while keeping the instancing procedural.
You can be imaginative with what you pack. You can pack different initial conditions and use the node to compose them. Think fireworks, droplets, squabs or whatnot. You can kitbash, or you can do manual touch-ups on procedural network outputs. What the HDA does is gather the editing features into a single node and interface.
Since you can insert pieces through the node I had to deal with picking which instance to add. This led me to create a HUD palette in python states, it lets you pick instances without leaving the viewport. There's also an assembly feature, which is just compositions of instances. The nodes lets you either pipe in assemblies, or create them on the node. These are then available in the palette and lets you add sets of instances in a single operation.
The final feature is the graph-like connections that are created while placing instances on other instances. This is the origin of the name, B-System, short for branch-systems, referencing the branching data structure that emerges. The utility of this is that selection and editing can employ the connectivity between instances to quickly select groups, upstream or downstream, which again makes editing easier and a lot less selection intensive.
I hope this is of interest, let me know what you think! The HDA is available on Gumroad, it's free for now. Looking forward to your feedback~~~
https://ae43ae43.gumroad.com/l/bahri [ae43ae43.gumroad.com]
... it should be stable (fingers-crossed), I've been debugging the hell out of it.
