kodra
APEX's "graphs editing graphs" nature gives me the same vide: code as data, little to no type safety, passing strings around, passing dict as parameters around, extra layer of indirectness...

graph = loadDataIntoGraph([json, yaml, binary, hou.Geometry, Whatever]);
input = {string: "hi"};
result = runapex(graph, input);

how you build data also don't matter, right now, sidefx present apex as being capable of writting apex graph, that one way of writting data, there is an infinite way you could write apex data :
use python to make an apex graph
use vex to write an apex graph
use an apex graph to wriet an apex graph
use javascript to write an apex graph
use an AI to write an apex graph
go on indefinitely.

Have you ever opened the node editor in maya ? what do you see ? node, node with connection, that all you see, there nothing else, it just a bunch of node with a bunch of connection, similar to apex, maya core is the dependancy graph, maya is also a input-output engine.

kodra
Even if you call Apex "data", it's still something that needs to be "executed" at some point, just like Python code. A Python script is string, it can be saved to the disk as a plain text file, but it's still code because the purpose of a Python script is to be executed by Python interpreter.

kodra
The main issue about this (among the other issues) is that it separates where you generate "something" and how "something" is evaluated. Which makes debugging much harder. For example, if your Python throws an uncaught exception, it will dump the whole call stack for you and you can know which line causes this exception immediately. But if your Python code is generated by another Python code, you can't pinpoint the problematic line without carefully traversing the whole code generation logic.

kodra
Perhaps for rigging/animating this kind of evaluation engine is necessary, but I absolutely don't want it to be "the new SOP". If it's the future of Houdini, I hope SideFX makes it clear, so I can cut the loss and completely stop using it now. As I said, the cleanness of SOP is the main reason I chose Houdini. If it's gone then I'm gone. I fully understand people have different mileages, and those who like Houdini for other reasons can continue using it, just not me.

Jacquesf
I didn't called apex data, I called data 'data'
why apex is not a programming language unlike python ?
python : you know how your code is gonna execute and when, each line after another
apex : there is not definition of how when a node is gonna be executed, you start by the output, and you build a list of node you will execute in a specific order on the fly based on the input and output needed

that make apex not a programming language, it a smart graph that compute which node need to be execute in which order and pass the data around.

you can run your apex graph using the invoke apex graph tool and use the output ERROR mode, that how you know where your apex graph have an issues, so I don't see what the difference between debugging in python and debugging an apex graph. you don't have to use the default "Apex autorig component" as they don't give you a trace :

kodra
You've probably forgotten how much modern programming languages are optimized. It's quite common that a compiler starts with output traverse backwards and delete unused code,

kodra
1. APEX is quite low level, which means in most practical cases, you will need higher level tool to generate it. autorig component, Python, AI, whatever... it doesn't matter which tools you use, but you need some tools to author those 5000~10000 node rigs. Hand-authoring APEX graph is like writing assembly directly.

kodra
2. Make autorig and rig script node smarter so it keeps a "codemap" in metadata that can be used for debugging later. This is a doomed path imo, as the complexity and man-hours needed are skyrocketed... but SideFX has some smart guys so perhaps they can make it work.

kodra
Anyway, SideFX probably has the roadmap internally that will prove all my concerns are redundant. Perhaps they already have a better solution than what I randomly typed. But I don't think the issue of APEX is at "just need some more learning materials and UI tweaks" level.

Jacquesf
that up to your workflow, you could keep complaining about the need to make high level tool, or you could ... you know , start making these high level tool now ?

kodra
If SideFX could be more clear like "how an APEX graph is stored as geometry is not an internal implementation detail, but a public API that is intended for users to manipulate directly. The whole spec will be documented once APEX is out of Beta."

Jacquesf
there is a few 'hidden' debugging tool that tell that it possible to get all the state of an apex graph as it being worked on, so I have no doubt we'll be able to see in realtime what an apex graph do as you build it (and if they don't, I'll do it myself).

edward
If you have just an APEX Invoke Graph SOP, then the steps to try out the APEX Debug viewport state prototype are:

Jacquesf
one idea I had to make debugging easier would be to "link" the active stash/edit graph panel that currently being worked on with a remote invoke node that 'use' the graph, so the panel where you edit the graph become at the same time a remote debugger.

Jacquesf
seeing it as 'visual coding' is a mistake

Andy_23
One other thing…

While looking at existing graphs, I can see some outputs are __output__ while others are __binding__
Can someone speak to the difference? Because I cannot create bindings in the APEX Network view.

Thanks

Jacquesf
'binding' is in vop, you're probably looking at vop graph which translate to vex.

tamte
I see it also in some graphs used instead of __output__, but I guess it's likely that __binding__ is just an old name for __output__ callback, so it may be hidden now