Jonathan Gardner

Hey Kodra,

In H20.5 there isn't a good way to print debug messages from an APEX graph (or from APEX Script) but we're aware of this gap and we're working on a Logcallback for APEX that could be used to log messages, warnings, and errors as well as throw custom error messages to our nodes which invoke APEX graphs.

Once the design of it is finalized, we'll add printing support to APEX Script.

In Houdini 20.0.618, we’re updating the APEX graph library to alter callbacks which worked with APEX graphs as geometry.
These callbacks were part of an old workflow that was never properly supported so we hope that these changes will open up new options for you without impacting your existing graphs.
Some of them were replaced with similar callbacks that work directly with APEX graphs while others were removed.

Here is the full list of altered callbacks:

Replaced:
The following callbacks had their signatures altered so that they could work directly on ApexGraphHandle types rather than on the geometric representation of those graphs.
Due to this change, these callbacks should be easier to work with going forward.

• graph::Layout
  
• graph::AddSubnet
  
• graph::PackSubnet
  
• graph::RewireOutputs
  

Renamed:
graph::AddSubnetNew was renamed to graph::SetSubnetContents.
This name change better represents what the callback does.
graph::AddSubnetNew has been aliased to graph::SetSubnetContents so this will not affect existing graphs.

Removed:
The following callbacks were removed from APEX:

• graph::MergeFromDisk - This callback existed prior to the implementation of subnets in APEX as a method of setting up an executable graph. However, it no longer works with the design of APEX and the idea that these graphs should simply be execution engines with results determined entirely by their inputs.
  
• graph::ProcessParms - Although this callback had a signature, internally it was a no-op.
  
• graph::InvokeCompiled - The graph input to this callback could only be set by the graph output of graph::ProcessParms. Since that output would always be empty, this was also a no-op.
  
• graph::SetTags - graph::UpdateNodeTags is the graph equivalent of this callback.
  
• graph::SetParms - graph::UpdateNodeParms is the graph equivalent of this callback.
  

Jacquesf
Hey! So I recently updated to a version of houdini introducing these change.
I had a concern about the dict::Build node, which use a in-place memory input, this node is often used to build dictionary from scratch, but now it require a Value<Dict> input systematically connected to it, I feel like this could be avoided completely if apex could simply detect that the port is not connected and automatically add an 'invisible' Value<Dict> node to it ?

Hey Jacquesf!

First, thanks for downloading the changes and giving feedback!
We've gone back and forth on this one ourselves and I do agree with a lot of what you've said. We had to update 40+ of Houdini's internal graphs because of the in-place input on dict::Build.
The primary argument I have for keeping it the way it is right now is just to ensure that in-place inputs are being used correctly. Although it would make a lot of sense for dict::Build to create its own dictionary when it doesn't have an input dictionary, I feel like that's the exception to the rule.
As an example, for the graph editing callbacks like graph::AddNode, I'd expect the callback to be adjusting a graph in the vast majority of cases rather than simply creating a graph with a single node. Since the burden of putting down a single Value<Graph> callback is pretty minimal, I think it would avoid a lot of potential headache to treat the missing in-place input as an error rather than to allow a potentially faulty graph to run.
That's just my two cents though. Part of the reason for bringing this change back now was to get feedback and if the community feels differently, this is one where I could see us using the invisible Value<T> solution and downgrading this to a warning.

Jacquesf
we also really need a way to differentiate in-place port and having the search (ctrl+f) feature working if we're gonna be forced to fix any missing or wrong connection.

Agreed! These are being worked on/on the TODO list.

Jacquesf
PS: I think the luchador & Chicken Rig scene example is completely broken now.

There should be a new version of that file in the content library for Houdini 20.0.592 and beyond.