Convenient Debug & Tuning, or just Running with Scissors?

We have a number of systems that are written in KL and hold their data within structures that can be accessed at run-time. The systems are generally fairly generic and are highly dependent upon the makeup of their data to be useful. We use the graphs do specialize and build out a particular use case. I quite frequently find myself in need of editing data that is hidden away among the nodes of the graph somewhere. * This sometimes requires a lot of graph navigation and makes performing these edits rather arduous, and it's not always easy to remember where a particular component lives - especially in the early stages of development, when there is a lot of flux.

So I've been thinking of ways to simplify this task. The ideal would be to have the Canvas UI generate multiple, individual value editors that each hold onto a specified graph node, regardless of the current selection. Since this doesn't [yet] exist, I've been looking at a poor man's solution to get me through the rough spots. It's by no means something that represents a full on solution - more of a curiosity combined with a "need fix now" problem. I'm posting this to kick off some discussion about the topic because managing, tuning and debugging graphs becomes increasingly difficult as they grow in complexity and focus.

As it stands right now, the attached graph operates on array variables, allowing the user to set values on individual indices within that array. There is a single function node that does the bulk of the work, but because variable access is functionality limited to the graph, there are some restrictions on its portability. For instance, it uses ports of Type $TYPE$, so it's fairly portable, but it needs to be hooked up to variable read and write nodes.

What would be useful:

  • If an IO port on a node displayed the NEW incoming values AND allowed editing them. You can edit them currently, but the UI is never updated to reflect their current content.
  • If multiple value editor UIs could be instantiated to point at separate graph nodes. This would be great for many reasons outside of this particular post.
  • If it was possible to interact with variables from within a canvas function node.

In brief summary, it's awkward and dangerous to use, but it does reflect something worth solving. I see this as a "running with scissors" tool largely useful for debugging and tuning.

Please chime in if you have any thoughts.



  • malbrechtmalbrecht Fabric for Houdini Posts: 752 ✭✭✭


    I full heartedly agree on all three points you raise. The last couple of days I have spent in Houdini creating a "state machine" for a semi-automatic rig (a rig that on-the-fly creates animations depending on the environment it is being moved through). The big problem in Houdini was/is, that it does not really feature a "variable" that you can carry from "cook to cook". I found a way to do this by using Python nodes - dirty, but I got my statemachine.
    Now, Fabric exactly gives me this variable. I actually HAVE access to stable, re-usable, editable variables - but I don't have "instances" of parameter/value interfaces (like I can have in H). When dealing with lots of variables, just like you describe, this is tedious and contraproductive.

    What I did in Fabric, when a situation like this came up, was to just throw together a single "value editor node" that got connections to all possible places throughout the graph. Since I try to keep my graphs as small as possible, using as much code instead of nodes as possible, this is "doable", but not elegant.
    The ability to "rip off" a value editor / parameter interface and keep it floating (or docked) but connected to its hosting node would be really helpful. I know, this is just repeating what you said - but I try to use different words :)

    The same applies to being able to "peek and poke" on editable values in the interface. This is something that irritated me from my first day in Fabric: I somehow expect to being able to edit values both manually AND through the node/code.

    I am sure that it would be possible to write an extension to Canvas, using Python GUI methods, that provides an "auto-adaptive editor node". I would love to try that myself, I will try to find some motivation for that ...

    +3 I say ;-)


    Marc Albrecht - - does things.

  • JudahJudah Posts: 64

    Thanks for replying, Marc.
    Sounds like we are doing some similar things in response to this problem. I keep on bubbling attributes up to gain access, but it's not really the right solution as it introduces a persistent alteration to the graph. I've also been considering generating some editing types to more easily facilitate this. For example, an aggregate struct comprised of all of the various attributes necessary to perform a particular edit. This would cut down on the duplication of effort initially, but I'm not crazy about having a bunch of these definitions lurking around in KL just to facilitate a temporary need.


Sign In or Register to comment.