Just a little rant here. As I was browsing through some example files, I noticed that stacking nodes in the network editor, particularly for Houdini, seems counterproductive, especially when it's meant for educational purposes. There's no necessity to compact everything so tightly. It took me a considerable amount of time to decipher and untangle it all.

before after

that much nodes just to find the distance between 2 joints, the pain is real

very subjective, I like tightly packed network, avoid unnecessery moving of the view constantly, I'd be mad about the lack of color coding tho.
Not sure where you even found that network, most of sidefx's exemple are fully colored coded.

Jacquesf
very subjective, I like tightly packed network, avoid unnecessery moving of the view constantly, I'd be mad about the lack of color coding tho.
Not sure where you even found that network, most of sidefx's exemple are fully colored coded.

It's a pillow rig example https://www.sidefx.com/contentlibrary/apex-pillow/ [www.sidefx.com]

In this particular case, isn't the problem these "Automatically renamed..." comments?

this simply don't look like a very nice exemple to follow, maybe try the luka & chicken rig exemple ?

the electra rig setup and LukaChicken were enough for me to fully understand how apex work and to now do my very own rig from scratch.

Jacquesf
this simply don't look like a very nice exemple to follow, maybe try the luka & chicken rig exemple ?

the electra rig setup and LukaChicken were enough for me to fully understand how apex work and to now do my very own rig from scratch.

I'm not... so sure about this. Luck Chicken example has some logics loaded from "lucha_and_chicken_subgraph_pack.bgeo". And that file's graphs look just as messy as what OP showed.

And honestly that you need to load subgraphs via an undocumented python function is... ad hoc at best, abominable at worse.

here the apex graph they made that generate their 'ik arm setup' in the lukasz rig file


but lets mention something here, Apex is a really new system, there little tutorial about, little people that know how to use it, and even less tool to make building apex graph easier.
anybody trying to use apex today should consider himself a pioneer, and like all pioneer, it gonna be hard.

if you consider it too hard today, I'd recommend waiting a few more month until sidefx release more material.
I personally been using apex for about 3-4 month and getting an absolute blast building my own rig entirely by myself today, but getting there was incredibly hard considering I had absolutely no resources back a few month ago. these luka&chicken rig were a godsend the moment they came.

good luck learning apex !

kodra
And honestly that you need to load subgraphs via an undocumented python function is... ad hoc at best, abominable at worse.

We are aware that portability is still an issue with subgraphs that are more intended for a local use. Uou can load them every easily without the python scirpt by putting the subgraphs into your home dir in an a folder called apexgraph/ then the subgraphs will be automatically picked up similar to the otl/ dir. Its a bit of a different story when that dir is relative to your hip file which means that you can not preload that subgraph before opening the file itself.

When it comes to stacking nodes. Yes some of that graphs are still be packed to tightly, which is more based on ui change for the node editor. Meaning nodes are displayed bigger now and some of the older layouts are now squashed. We will get to them bit by bit though and stretch them more out for better readability.

Jacquesf
if you consider it too hard today, I'd recommend waiting a few more month until sidefx release more material.

At this point, I think there is something wrong about APEX fundamentally, and it's not just the lack of documentations or tutorials.

It's not that "it's too hard". It's that it's designed in a way you need to "metaprogramming" the graph.

This is what I call "metaprogramming" (from Lucha&Chicken example):



General speaking, I think this kind of logic is what one should avoid when designing any kind of programming language: editing itself as data. These "AddNode", "FindPort" and "ConnectInput" are the equivalent of editing your Python script as a string in Python then evaluate it later. That's what every programmer (except Lisp ones. Lisp-like languages, while being very powerful, arent mainstream for a reason) has learnt to avoid.

It's not just an analogy: APEX has every drawback of string-based metaprogramming. For example, the lack of "type-safety": graph:AddNode takes a string parameter as the node name. It's a big no-no: not only it requires the user to memorize all the nodes' internal names, it also delays the error to the point of evaluation. It's an unbelievably bad design, and it's the very core of APEX rigging now: either this, or manually editing thousands of nodes. There isn't a third way.

At least APEX is only for rigging for now. If APEX becomes the de-facto way to manipulate geometries or even simulation, I expect in the next decade Houdini TAs are going to learn why it is a bad idea the hard way.

And while SideFX kept saying performance in HIVE and Keynote, this kind of architecture is bound to be computationally slow. Yes, evaluating the animation is fast, but building the rig graph from the rig template is and will be slow. If you build the Lucha's rig in Blender or Maya, every step would be in real time. But in Houdini, the last node in your rigscript chain ("build_rig" in Lucha example) will always take several seconds to cook: it's the nature of metaprogramming and no tutorial or document can fix this. More high-level tools will only make the last step even slower.

So far my opinion about APEX is the opposite of KineFX. When KineFX came out in 18.5 HIVE, I thought it was a weird gimmick, but once I understood how it works under the hood I were in awe of the elegance. When APEX came out in 20 HIVE, I were in awe of its flexibility, but once I understood how it works I started getting very pessimistic: not just about APEX but about Houdini as a whole. It's everything I hate as a professional programmer and an amateur artist packed in one. I didn't even expect someone is capable to make such a monstrous design...

(As a side note: In Blender the way you rig procedurally is to write Python to generate all the constraints. It's an unmaintainable mess... but still better than APEX at its current state by several magnitudes. At least Python code is much more compact and easy to debug than APEX rig scripts.)

I also think the current Apex node UI makes the job of reading the graph harder than it needs to be, other than that I love the direction where things are going.

kodra
General speaking, I think this kind of logic is what one should avoid when designing any kind of programming language: editing itself as data. These "AddNode", "FindPort" and "ConnectInput" are the equivalent of editing your Python script as a string in Python then evaluate it later. That's what every programmer (except Lisp ones. Lisp-like languages, while being very powerful, arent mainstream for a reason) has learnt to avoid.

If you haven't yet tried to build an entire rig by yourself using apex, you have no idea of how fast and performant it is so far.
All the rig I could only dream to do on Maya (and the one that I could but were suboptimal in term of performance), I could do them in apex like never before.
so far I approach the 600Bone and +1200 apex node in my rig and I keep a +120Fps realtime performance, even the generation step of my rig is realtime and I never expected a single ounce of slowness that you described.

There is not one way to build an apex rig, all the problem you mention don't even mean anything in fact, if you think about it, Apex is very similar to the maya node editor, with the difference being that maya use 'tool' to generate that network, where you select bone on the viewport and then hit 'constraint', and then you automate that process through python script who ultimately work by doing these manual selection aumatically. a maya professional rig has never been realtime to generate in maya.

Apex graph is only data, complaining that you need to use another apex graph to generate apex rig is so wrong because :

- nothing prevent you from generating your apex graph using python the SAME WAY YOU COULD DO ON MAYA.
- nothing prevent you from executing an apex graph in your own python code as you generate it : you can build your own debug tool that fit your style, I did mine and I have no problem building insanely complex apex graph today, why can't you ?

apex have a ton of different way you can rig and ship your character :
- you can either build an apex rig like you'd do on maya, save your character and ship it to the artist, incrementing the save file as - you update your rig
- you can ship your character in an HDA, giving you the possibility to add tweak to the rig through the HDA's parameter, letting the artist configure his rig the way that would matter for the task
- you can ship the rigscript that would generate the rig on the artist scene, allowing the artist to modify the generation process by substituing certain part of the rig by other.
- use a mix of these above, like I do


Apex is a low level framework, whatever tool sidefx propose today are only a suggestion, 'rigscript', 'component', if you don't like them, then do it the way you want, use python to generate your graph, or vex for that matter if that how you fancy it. heck if you miss maya so much then maybe just redo all of there pseudo tool like 'constraint parent, constraint point, curve', there virtually no difference to that 'meta programming' you described when you use python to generate maya rig , it mostly string based anyway.
Don't call yourself a programmer if you can't figure out the abstraction behind apex by yourself.

Apex share lot of similitude with the maya dependancy graph, in fact, there just a few key difference :

- not cyclic ( left to right execution, you know how thing are gonna compute, pretty much UE4/5 Blueprint programming )
- low level data manipulation ( you know what data you manipulate, geometry is on equal footing to a integer )
- saved as geometry ( fit with your character, easy to edit, virtually limitless way to generate these)
- it on houdini ( infinite potential)

Apex is a framework, there no one way to use a framework, you could redo the entirety of maya with apex, because that how similar they work internally

maya is maya because they choosed to do every operation through high level tool, under the hood, maya is also an 'Apex' framework. if you don't trust me, then you never tried to build maya node manually yourself (which is a nightmare because of this cyclic way of working.

to add some more.

I think Sidefx did a mistake by advertising APEX as a rigging tool. What I mean is that so far, sidefx presented the few sop node 'component, autorig, rigscript' as being apex, and people will associate apex as being these tool.

Apex is the low level framework that these tool are built onto, but apex by itself is not a rigging system, it an abstract system which is primary used for rigging on this version of Houdini.

it would be best if the distinction is made early on, because apex have way more potential than it look like on the surface.
I myself failed to see the point of autorig component and rigscript, they felt like a limitation to me, however, with a bit more of understanding of what apex is, the component and rigscript system make more sense, it simply a more convenient way to rig a character procedurally, but not the only way.

There is in fact a third way to create rigs: You can use the python api if you do want to avoid using graphs to procedurally modify your rigs.
Concerning the mentioned point about name dependencies: We provide a pattern syntax that allows you to filter nodes based on custom metadata, such a tags, properties, connection status, node type etc. that allows more flexible connection setups, so you are not bound to the initial string identifier as your only filter source.
The rig script can be very likely still be optimized in terms of performance. We can look into that.

Jacquesf
If you haven't yet tried to build an entire rig by yourself using apex, you have no idea of how fast and performant it is so far.
All the rig I could only dream to do on Maya (and the one that I could but were suboptimal in term of performance), I could do them in apex like never before.

I've migrated an rig from Blender, which is similarly to Lucha in terms of complexity. Just as I said, it's slow: animating is fast, but the "compilation" is quite slow. Again it's expected: it's the very nature of metaprogramming. C++'s template is slow to compile for a reason. (But C++ is type safe, APEX isn't... I digress)

You can argue it's a good thing since one only needs to "compile" it once: if you do it perfectly and never need to debug...

Jacqusf
Apex graph is only data,

This is... a really, really common pitfall when designing tools. I suppose you mostly work in VFX, and if you have programmers friends who work in other fields (like web/cloud) you can ask them for opinions on the "code as data" pattern. Github Actions is one of the most hated tools for a reason: it tries to treat arbitrarily complicated code as yaml data.

Think about DOP: DOP has a similar "delayed evaluation" nature, but most of the time we hand-build a DOP network and only procedurally manipulate attributes to adjust how the simulation looks like. Even it's possible to edit DOP network itself procedurally, it's not a primary way to work with DOP. To some extent, DOP is "code as data" too, but it (correctly) limits this pattern's scope and doesn't just be arbitrary.

Yes, code is data, but in most cases it's a dangerous idea to treat them as so. Perhaps rigging is a special case where there isn't a better way, but I really don't think it's a good general pattern. The more people talk about APEX's "potential" the more I'm concerned.

Jacqusf
nothing prevent you from generating your apex graph using python the SAME WAY YOU COULD DO ON MAYA.

esttri
There is in fact a third way to create rigs: You can use the python api if you do want to avoid using graphs to procedurally modify your rigs.

Well, this is a good point. I expect if I still use APEX in the long run, this is probably the way to go. It should be better than using graphs that edit graphs.

Of course the "advantage" of APEX graph being geo is that we can build our own SOP (a bit weird to call them SOP) that edits the graph. But the whole thing is undocumented: how do we know the current "spec" is final and out tools won't break in the next update of Houdini? Technically, how Houdini stores the graph's prims/attributes is an implementation detail until SideFX document them.

But at least this is a fixable problem. If SideFX cares. The whole kinefx python module is still undocumented today, so I don't know if they do.

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."

I myself failed to see the point of autorig component and rigscript, they felt like a limitation to me, however, with a bit more of understanding of what apex is, the component and rigscript system make more sense, it simply a more convenient way to rig a character procedurally, but not the only way.

At this point, I'm fairly confident that I understand how APEX works. I'm not saying I know what every single node does, but I understand 99% of Lucha&Chicken and am able to rig something similar from scratch.

I do think if the whole autorig component system were implemented with Python instead of graph:: nodes, I wouldn't be so negative about APEX. But yeah, realizing it's still an option makes me a bit more positive.

Still I don't think it should be the primary way to modify geos. The only scenario(s) APEX makes sense, in my opinion, is where you can separate your workflow in two clear stages: "compile" and "exectue", and you can trade the performance of compile stage for a real time execute stage, similar to why people still use C++ no matter how clumsy it is and how slow it compiles. "Rigging" and "animating" is kinda like a two-stage workflow, perhaps it's way SideFX marketed it as a rigging framework.

kodra
I've migrated an rig from Blender, which is similarly to Lucha in terms of complexity. Just as I said, it's slow: animating is fast, but the "compilation" is quite slow.

have you considered that there might a problem or a bug ? I can easily make apex generate 10000+ node in an apex graph in realtime, at the end of the day it only generate geometry data, vex is know to be able to update million of point per second, apex is no different. I'm pretty certain that something must be wrong there.
maybe the luka rig simply do something the wrong way itself.
please double check on that.
unless you're trying to run the 'compilation' while the animator is currently animating the character ? in this case that would indeed be a bad idea, you do need a 'compile' and 'runtime' step, but they could happen right one after another, right on the 'shot' scene

kodra
I do think if the whole autorig component system were implemented with Python instead of graph:: nodes, I wouldn't be so negative about APEX. But yeah, realizing it's still an option makes me a bit more positive.

I spend a few day trying to consider "Should I go python" or "Should I go apex" to generate my rig, and there a few point that made me go with apex : by using python, you loose the flexibility of storing apex graph as geometry, the rigscript system of sidefx is actually kind of genius, maybe because it perfectly fit the way I tried to build my character pipeline for the last 7 year (that maya could never follow), or because it actually make lot of sense : it just visual programing bundled with all the power of houdini, you can use sop, vex and python in an apex graph.

kodra
This is... a really, really common pitfall when designing tools. I suppose you mostly work in VFX, and if you have programmers friends who work in other fields (like web/cloud) you can ask them for opinions on the "code as data" pattern. Github Actions is one of the most hated tools for a reason: it tries to treat arbitrarily complicated code as yaml data.

I'm actually a senior developer with about 15 year of software development experience and used over 15+ programming language, including front end web, back end web, and low level language like assembly, c, c++, golang, and now focusing manly of python because of it implementation with dcc. I specialized in software architecture, and used many framework going from web framework (symfont, laravel, zend) to game engine like unity and ue4/5, passing through maya,houdini sdk.

I've been a 3D hobbyist since 2015 and basically LOVE programming pipeline tool, so did over 3-5 year of maya before switching to Houdini.

then I got hired in a vfx industry roles as a lead of pipeline.

I do think I have a strong grasp of programming in general and that I'm qualified enough to know apex is a magnificent (and one I predicted sidefx will HAVE TO DO a few year ago, if they wanted to break in the animation industry)

apex purpose is not to replace code, apex is here to offer a new framework for realtime processing and interaction with the viewport, something you cannot do with regular sop because of the overhead of inter-node communication.
to think apex is designed for coding purpose is missing the point, it a graph system with the capability to manipulate graph, seeing it as 'visual coding' is a mistake, you should see it as a new generation of sop cooking engine for procedural modeling, rigging, and animation.

Jacquesf
have you considered that there might a problem or a bug ? I can easily make apex generate 10000+ node in an apex graph in realtime, at the end of the day it only generate geometry data, vex is know to be able to update million of point per second, apex is no different. I'm pretty certain that something must be wrong there.

Perhaps? From what I saw it's more like "generally slow", but I'll bisect/profile it later and see if there is a particular bottle neck.

Jacquesf
I'm actually a senior developer with about 15 year of software development experience and used over 15+ programming language, including front end web, back end web, and low level language like assembly, c, c++, java, golang. and I specialized in software architecture. and used many framework going from web framework (symfont, laravel, zend) to game engine like unity and ue4/5, passing through maya,houdini sdk.

I apology for assuming your background.

But again, as you have professional C++ experience, you understand what I meant by powerful and flexible isn't always == good.

Even if you're one of those truly great C++ programmers (a rare species. Myself definitely isn't one), you must have encountered all the people less knowledgeable than you abusing macros and template programming, right? Or people who misuse Java's reflection?

You remember when TypeScript came out, even it's an objectively better language, it was quite harder to debug than plain JavaScript due to the extra layer of indirectness, until Microsoft + browser vendors + the community poured countless hours to build tool chains around it?

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...

And this seems to be at the core of APEX's design (even one use Python to editing graphs the issues are still the same, just that one can utilize their existing Python tools and debugging techniques). No amount of tutorial would save this. Higher-level tools, maybe... but not stuff like "5 more autorig components" or "slightly better SOP import". It needs a better "compiler pass" to show better error messages when the user makes a typo or misconnect the nodes (procedurally!). A relevant meme:



It's proven to be an extremely hard problem tho (as Lisp-like languages have been solving this for several decades, but the error messages are still demon-summoning rituals once you start working with macros), so I keep my hope low.