I've been building this character rig in APEX - it's a simple character but with some custom requirements, like cartoony bendy arms and deformations.

It's a bit of a headspace shift compared to rigging with SOPs and KineFX - previously I would add bits of rig in chunks that could be fairly independent, in APEX everything goes in one network. And there are no assumptions, you even have to rig FK (there are helper nodes to add those simple bits). The end result is a bit like a massive all in one Rig Attribute VOP, with lots of interconnections, it's going to be tough to deconstruct rigs from their APEX graphs. But with all the new features in the Scene Animate node I think it'll be worth the effort moving rigs over, I'm looking forward to trying that out next.






Here's the APEX graph, over 5000 nodes, luckily mostly added automatically!

Insane!! How did you figure this out? So far I haven't been able to do anything in an APEX graph

benttoenail
Insane!! How did you figure this out? So far I haven't been able to do anything in an APEX graph

I've used Python to help turn a graph into a more usable template (generating a new APEX graph from my original) - so I don't have to repeat nodes hundreds of times to rig each point. This is sort of what the prebuilt APEX components do I think, except I haven't managed to figure these out, I think each component needs to know how to edit the graph so customising them seems tricky, hopefully there'll be some upcoming tutorials to help with that.

Plus I finally figured out how to use compiled blocks, because you can refer to wrangles in APEX, but only via sop::invoke - a lot of stuff I already had vex code for, and you can still use all of that in APEX! It's not my favourite workflow, the rig isn't shareable by itself anymore - you need to also share the compiled blocks which are separate from the graph, and have them in the same place in any hip that uses the rig. But it's a good shortcut for now until I learn how to do those things in APEX, or APEX gets more functionality built in.

danfitz82
because you can refer to wrangles in APEX, but only via sop::invoke - a lot of stuff I already had vex code for, and you can still use all of that in APEX! It's not my favourite workflow, the rig isn't shareable by itself anymore - you need to also share the compiled blocks which are separate from the graph...

if you want to clear your rig from such external dependencies on compiled blocks you can try creating equivalent nodes to your wrangles using
sop::attribvop APEX node
it has vexsnippet parm for your wrangle code as well as other parms to define custom bindings etc similarly to wrangle in SOPs

tamte
if you want to clear your rig from such external dependencies on compiled blocks you can try creating equivalent nodes to your wrangles using
sop::attribvop APEX node
it has vexsnippet parm for your wrangle code as well as other parms to define custom bindings etc similarly to wrangle in SOPs

Ooooh thanks I hadn't spotted that one! That'll be a real win if I can bring the vex code into the rig.

I was excited about the new tools H20 provides. But I think we have to ask: is this really the future of rigging? I thought the premise of KineFX was some kind of modular rigging. Now we go back to a monstrous network with 5000 nodes...?

kodra
I was excited about the new tools H20 provides. But I think we have to ask: is this really the future of rigging? I thought the premise of KineFX was some kind of modular rigging. Now we go back to a monstrous network with 5000 nodes...?

The final APEX graphs of a rig are pretty intimidating, but I think the future will bring more ways to author those networks - part of the power of them being geometry is that there's lots of potential for editing them in SOPs. The autorig components are a start but tough to tweak to create custom rigs. It's early days and we just don't have all that potential yet. That's my hope!

danfitz82

kodra
I was excited about the new tools H20 provides. But I think we have to ask: is this really the future of rigging? I thought the premise of KineFX was some kind of modular rigging. Now we go back to a monstrous network with 5000 nodes...?

The final APEX graphs of a rig are pretty intimidating, but I think the future will bring more ways to author those networks - part of the power of them being geometry is that there's lots of potential for editing them in SOPs. The autorig components are a start but tough to tweak to create custom rigs. It's early days and we just don't have all that potential yet. That's my hope!

I hope so.

My experience with APEX so far is that it's nearly impossible to author APEX rig by hand. And it's very hard to read one, too.

Here is a criticism to Maya, from cgwiki:



Ironically, this is exactly how I feel about APEX. Perhaps at the end of the day, Maya be like that for a reason...

From my view as a programmer, while APEX is technically between SOP and VEX (according to SideFX at least), APEX is actually assembly of Houdini. It's conceptually extremely low level. So low level that instead of a loop that iterates 10 times, you use 10 nodes.

---

Sorry for the rant below:

I hope I'm wrong, but it feels like SideFX is occupied by Architecture Astronauts [www.joelonsoftware.com]. There is just no obvious reason why APEX is designed as it is. Why is the APEX graph "geometry" at all? Yes, you can technically encode a graph as a geometry. You could have probably found a way to encode tasks, USDs, textures and any other data into geometry. Whether you should do it is another different story.

It's typical way how mathematicians think: we invent the concept of "Group" and now we can fit a lot of completely different math operations into this category. It was a huge mathematic milestone, but it's almost unexplainable to someone who doesn't work in relative fields why we grouped seemingly unrelated things into a group called group.

Evidently, SideFX already calls heightmap "2D volume". Heightmap isn't volume for 99.99% of people, just like an executable graph isn't a geometry.

I really hope SideFX can take a step back and rethink how they design the software. APEX doesn't feel like it's designed for some customers' needs. It feels like someone who is extremely smart and good at thinking on high abstraction level came up with an idea: "Well I just realized graphs can be represented as geometries, interesting isn't it?" And they spend 50 man-years to implement UIs and tools around this single idea.

It's amazing that they made it work to some extent. An engineering miracle. But it won't make Houdini the industrial standard for character animation. Actually I believe the two videos on the official youtube channel drove more animators/riggers away than they attracted.

Obviously, it's already way too late to redesign APEX again, but it's more like a general concern.

kodra
Whether you should do it is another different story.

As far as I know, you can store an entire graph as a logical geometry unit and utilize it anywhere. I find this aspect of the approach quite fascinating. For instance, Electra's character can read a prepared rig from a file. Regarding Houdini, it has consistently fluctuated between being user-friendly and challenging. This is not surprising, considering the numerous memes about its steep learning curve. However, this is perfectly acceptable and contributes to its unique nature.

kodra
APEX is actually assembly of Houdini.

I think that's spot on, and that's why I'm hopeful there'll be more authoring options coming, ways to compile into APEX graphs from easier to use tools. Just like we would compile down to assembly from higher languages and never really worry about the assembly code itself. It'll take time to fill out those tools though.

kodra
I hope I'm wrong, but it feels like SideFX is occupied by Architecture Astronauts . There is just no obvious reason why APEX is designed as it is...

I agree. The seemingly 'architecture astronaut' driven agenda causes me some anxiety as a Houdini user. I have practical, everyday tasks to complete. I haven't yet had a client who said: "Wow! it's brilliant that you used [insert your architecture here]". It's more often: "Is the animation done yet?".

danfitz82
I've used Python to help turn a graph into a more usable template (generating a new APEX graph from my original) - so I don't have to repeat nodes hundreds of times to rig each point.

I've tidied this code and wrapped it into a more usable HDA, HDA and an example for using it on github here: https://github.com/noadanimation/houdini_apex_graph_from_templates [github.com] (very beta! alpha? alphabeta. But might be a useful option for anyone else who, like me, has a bit of trouble with the abstraction of creating an APEX graph to edit & create other APEX graphs, but still wants to create custom rigs).

It is good to see some people even trying to get this to work. As animator I took an look into APEX and run away screaming.
We need simple tools that will enable us to get to 90% of task done, fast. Think mgear for maya or similar riggers in blender. We need tools like that that will get us to rigged usable characters fast. Until that point is reached I don't think you will see too many animators switching to Houdini.
I would be first in line to ditch maya in an instance! But beside not being able to get understandable tools for myself.. it is mission impossible to find even Houdini riggers too.
So until this is reached and polished... I would love to see Houdini taking over character animation as well but I'm afraid it will take too long. And taking things too long was part of what ended up killing Softimage as well....I mean not that not being character animation software will kill Houdini, but character animation part of it will never become standard.