I've been pondering whether I'm hitting the age where things get a bit too complicated, or if rigging in Houdini is genuinely more complex compared to other programs.
A bit of background: I've been in animation for over 25 years. I started rigging in XSI, then moved on to Maya. Nothing too fancy, but I could handle about 90% of my character rigging needs at a generalist level for freelance projects.
Recently, I've been casually exploring Houdini for both rigging and animation. My brain starts hurting with all the nodes and everything—it feels confusing. I'd love to hear from others who have switched from different programs to start rigging in Houdini.
Even the idea of hiring proper riggers for Houdini seems challenging especially for APEX being still fresh, and I thought it can't be that complex. I should be able to reach the level of rigging in Maya, for example, to create basic character rigs with legs, spine, arms, head, IK/FK, basic facial shapes, and controls. Am I approaching this from the wrong angle?
In short, I'm eager to hear about others' experiences diving into APEX and rigging, particularly from an artistic perspective rather than a purely technical one.
Blender on the other side seems with plenty of seemingly good addons for rigging according to friends who've switched. While I like Houdini and initially moved to shading, lighting, and rendering (I'm primarily a character animator), I now want to expand into rigging and animation. Sometimes, it feels overwhelming—age, lack of free time, and exhaustion. What are others' experiences?
Thanks for sharing your insights and venting! 😊
Full Version: APEX rigging insight
Ima throw my 2 cent here.
I've been rigging as a hobbyist in maya for a few year, I can tell this software kinda babysit you when it come to rigging, you put parent constraint, ik, just by selecting your bones and hitting the tools you need.
In my opinion, this don't really teach you rigging, it a high level of rigging, but you don't really know what really happen under the hood, what kind of math is happening ? trying to look at your rig in the node editor just pull a pile of spaghetti that impossible to untangle, and add to that that you have a 'hierarchy' of node in the outliner, thing are not clear, constraint override bone position, controller, bone and logic are split into chunk of mess sprinkled with ton of transform node in between.
sure you may end up sorta knowing what you do, create python script to automate you rigging, end up tools that have been developed for decade like advanced skeleton, with their own tangled messy code that near impossible to decipher.
here come kinefx and apex : bone are point with a name and a transform attribute, hierarchy is build using primitive, your skeleton is just a flat list of point that you can manage the way you wish. apex look like a purified node editor, with a clear view of every transformation that happen in your rig.
You as the rigger, manipulate the raw transformation matrix in a meaningfull way, you understand what you're doing, you know what your rig is doing, you connect your node because you want to achieve a specific behavior : your fk ctrl are just a chain of parent xform passed one after another, use these same xform to build yourself an interpolation curve, sample it as you see fit, and you got yourself a spine !
all the graph of a rig can be read from left to right : no bullshit cyclic connection, once layouted automatically each column become a 'step' : you clearly see what node depend of what step, first the root, then the pelvis, then the leg and the spine, until you reach the tip of the finger.
I've learned more about rigging in these last few month than I ever did in the last 7 year in maya. matrix transformation are less and less of a secret to me !
put that in addition to the fact you don't need to put a single line of python code to build a rig, and that apex is naturally designed to build 'rig builder', you end up spending your time thinking 'how will that rig be built' rather than 'how to build that rig'.
The Autorig component system is amazing, every little bit of your rig now become a little module that you can then reuse into bigger one, the potential for sharing, updating, improving without coding is a new shift in how you build your rigging tool.
there so much more I love about kinefx and apex, it a powerfull framework and there so much to discover that even the dev at sidefx probably didn't think of !
I have so much more fun rigging from absolute scratch in houdini than using those blackboxed tool from maya.
the simple fact you have access to the entire library of sop node also allow for absolutely new way of rigging that could never be dreamed of in any other dcc ever !
it true that using apex today can be very frustrating tho, it in it early phase, and little tool to help the user exist, but if you go beyong what currently availlable and think of all the potential, this is a little price to pay for a futur that look promising.
hope that wasn't too much of a nightmare to read
I've been rigging as a hobbyist in maya for a few year, I can tell this software kinda babysit you when it come to rigging, you put parent constraint, ik, just by selecting your bones and hitting the tools you need.
In my opinion, this don't really teach you rigging, it a high level of rigging, but you don't really know what really happen under the hood, what kind of math is happening ? trying to look at your rig in the node editor just pull a pile of spaghetti that impossible to untangle, and add to that that you have a 'hierarchy' of node in the outliner, thing are not clear, constraint override bone position, controller, bone and logic are split into chunk of mess sprinkled with ton of transform node in between.
sure you may end up sorta knowing what you do, create python script to automate you rigging, end up tools that have been developed for decade like advanced skeleton, with their own tangled messy code that near impossible to decipher.
here come kinefx and apex : bone are point with a name and a transform attribute, hierarchy is build using primitive, your skeleton is just a flat list of point that you can manage the way you wish. apex look like a purified node editor, with a clear view of every transformation that happen in your rig.
You as the rigger, manipulate the raw transformation matrix in a meaningfull way, you understand what you're doing, you know what your rig is doing, you connect your node because you want to achieve a specific behavior : your fk ctrl are just a chain of parent xform passed one after another, use these same xform to build yourself an interpolation curve, sample it as you see fit, and you got yourself a spine !
all the graph of a rig can be read from left to right : no bullshit cyclic connection, once layouted automatically each column become a 'step' : you clearly see what node depend of what step, first the root, then the pelvis, then the leg and the spine, until you reach the tip of the finger.
I've learned more about rigging in these last few month than I ever did in the last 7 year in maya. matrix transformation are less and less of a secret to me !
put that in addition to the fact you don't need to put a single line of python code to build a rig, and that apex is naturally designed to build 'rig builder', you end up spending your time thinking 'how will that rig be built' rather than 'how to build that rig'.
The Autorig component system is amazing, every little bit of your rig now become a little module that you can then reuse into bigger one, the potential for sharing, updating, improving without coding is a new shift in how you build your rigging tool.
there so much more I love about kinefx and apex, it a powerfull framework and there so much to discover that even the dev at sidefx probably didn't think of !
I have so much more fun rigging from absolute scratch in houdini than using those blackboxed tool from maya.
the simple fact you have access to the entire library of sop node also allow for absolutely new way of rigging that could never be dreamed of in any other dcc ever !
it true that using apex today can be very frustrating tho, it in it early phase, and little tool to help the user exist, but if you go beyong what currently availlable and think of all the potential, this is a little price to pay for a futur that look promising.
hope that wasn't too much of a nightmare to read
I've posted a lot of criticism about APEX and I definitely won't recommend using it on production.
But to your specific question:
Chicken/Lucha examples have IK/FK switch, 4-point spline spine and some facial controls (with bones, not blendshapes). At APEX's current state, I don't think there are much simpler ways to do this than how they did them in the example files. If you feel the example files are too complicated then yes APEX is too complicated.
I built my own autorig components for Ik/FK switch, forearm twist, reverse foot and blendshape driver and spine control in Python. It's about 1500 lines of code so far. I'm not saying my code can't be simplified further, but that's about what you need to build "basic" rig in APEX now.
The silver lining is that you can actually copy/paste rig components from Chicken/Lucha examples, but you still need to take time to read them carefully to know what kind of input they expect.
The first thing you should decide is how important "proceduralism" is to your workflow. APEX is very clearly built with proceduralism in mind: you'll be modifying the graphs with other graphs or code most of the time, and only manually edit graphs for prototyping/debugging purpose.
You can do this in Blender, too, but it won't be much easier than doing it in APEX. Blender has more high level constraints than APEX, sure. But first of all it's all manipulated with Python so if you prefer nodes than code Blender can't help you. If you only need basic stuff, yes you can use addons like Rigify or Autorig. However any custom logic still need to be done in Python if you want to do them procedurally.
Secondly, even if you prefer code like I do, Blender doesn't have something like APEX network editor where you can view the dependencies between nodes, which makes debugging rig much more difficult. I've been using Blender for years, but can I tell which constrain is evaluated first with 100% certainty? No. With APEX you have 100% certainty. You don't just kinda get it, you know it.
And last, Blender has its high-level constraints, and they're generally quite fast. However if you need a very unusual rig that can't be expressed with these constraints, you're out of luck. Sometimes you can do something with these constraints, but it requires a lot of intermediate bones. In APEX you might need a lot of nodes to do something specific, but at least you can organize them into a subgraph and call it a day.
However, if you just want to rig manually, Blender will be much faster than APEX. Anything will be much faster than manually editing your final rig graph in APEX.
There is not artistic perspective to be discussed in the current APEX. It's a very technical, low level stuff. The artistic part is the same as Maya or Blender.
My only suggestion is to wait for H20.5, unless your goal is to learn the logic behind rigging. By "logic" I'm not talking about "knowing when to use IK", more like "implement a swing/twist decomposition with quaternions". If that's not the stuff you're willing to deal with than APEX is no good for you at this point.
But to your specific question:
Mirko Jankovic
I should be able to reach the level of rigging in Maya, for example, to create basic character rigs with legs, spine, arms, head, IK/FK, basic facial shapes, and controls. Am I approaching this from the wrong angle?
Chicken/Lucha examples have IK/FK switch, 4-point spline spine and some facial controls (with bones, not blendshapes). At APEX's current state, I don't think there are much simpler ways to do this than how they did them in the example files. If you feel the example files are too complicated then yes APEX is too complicated.
I built my own autorig components for Ik/FK switch, forearm twist, reverse foot and blendshape driver and spine control in Python. It's about 1500 lines of code so far. I'm not saying my code can't be simplified further, but that's about what you need to build "basic" rig in APEX now.
The silver lining is that you can actually copy/paste rig components from Chicken/Lucha examples, but you still need to take time to read them carefully to know what kind of input they expect.
Blender on the other side seems with plenty of seemingly good addons for rigging according to friends who've switched. While I like Houdini and initially moved to shading, lighting, and rendering (I'm primarily a character animator), I now want to expand into rigging and animation. Sometimes, it feels overwhelming—age, lack of free time, and exhaustion.
The first thing you should decide is how important "proceduralism" is to your workflow. APEX is very clearly built with proceduralism in mind: you'll be modifying the graphs with other graphs or code most of the time, and only manually edit graphs for prototyping/debugging purpose.
You can do this in Blender, too, but it won't be much easier than doing it in APEX. Blender has more high level constraints than APEX, sure. But first of all it's all manipulated with Python so if you prefer nodes than code Blender can't help you. If you only need basic stuff, yes you can use addons like Rigify or Autorig. However any custom logic still need to be done in Python if you want to do them procedurally.
Secondly, even if you prefer code like I do, Blender doesn't have something like APEX network editor where you can view the dependencies between nodes, which makes debugging rig much more difficult. I've been using Blender for years, but can I tell which constrain is evaluated first with 100% certainty? No. With APEX you have 100% certainty. You don't just kinda get it, you know it.
And last, Blender has its high-level constraints, and they're generally quite fast. However if you need a very unusual rig that can't be expressed with these constraints, you're out of luck. Sometimes you can do something with these constraints, but it requires a lot of intermediate bones. In APEX you might need a lot of nodes to do something specific, but at least you can organize them into a subgraph and call it a day.
However, if you just want to rig manually, Blender will be much faster than APEX. Anything will be much faster than manually editing your final rig graph in APEX.
particularly from an artistic perspective rather than a purely technical one.
There is not artistic perspective to be discussed in the current APEX. It's a very technical, low level stuff. The artistic part is the same as Maya or Blender.
My only suggestion is to wait for H20.5, unless your goal is to learn the logic behind rigging. By "logic" I'm not talking about "knowing when to use IK", more like "implement a swing/twist decomposition with quaternions". If that's not the stuff you're willing to deal with than APEX is no good for you at this point.
I understand completely. It seems to me that the current APEX is at such a low level that it provides all the necessary controls, which is great for riggers
A couple of years ago, I would have definitely jumped into those tools again, for sure. However, now that I'm more focused on other aspects, I only need a bit of rigging for support. What I, and I'm sure many others actually need, are tools created by these low-level APEX nodes.
Essentially, something like mgear for Houdini, as an example. Let me set up guides for legs, fingers, and other elements, and build everything in the background. I don't want to manually create each bone, each FK/IK switch, and so on
Given that APEX is still relatively new, it's natural that it needs to first cater to the needs of riggers. Then, hopefully, riggers will develop tools for the rest of us. I'm confident that there are others who would be willing to pay for such tools, similar to how I'm paying for animbot for Maya, for example.
While most of these tools can be created by users themselves, it would take days, even months... Instead, I'd prefer to pay for a yearly subscription, use the tool, and focus on my primary work.
Does that make sense? It seems to me that the current APEX is precisely what riggers require, and with time, the rest of us may have access to tools created by riggers for animators.
Looking at it from a similar perspective, why do we need to create a box in the Houdini shelf when you can go into nodes and meticulously model your own box, constructing the entire network from scratch, vertex by vertex?
Thank you for your insights! It's still valuable to delve into these low-level aspects, of course, but not to the extent that I would want to build everything entirely from vertices
This master lass shows exactly what I mean.
Go for it riggers, but anyone else that just wanna simple rig tool should stay away from it
https://www.youtube.com/watch?v=-0KbPtoP5MU&ab_channel=Houdini [www.youtube.com]
A couple of years ago, I would have definitely jumped into those tools again, for sure. However, now that I'm more focused on other aspects, I only need a bit of rigging for support. What I, and I'm sure many others actually need, are tools created by these low-level APEX nodes.
Essentially, something like mgear for Houdini, as an example. Let me set up guides for legs, fingers, and other elements, and build everything in the background. I don't want to manually create each bone, each FK/IK switch, and so on
Given that APEX is still relatively new, it's natural that it needs to first cater to the needs of riggers. Then, hopefully, riggers will develop tools for the rest of us. I'm confident that there are others who would be willing to pay for such tools, similar to how I'm paying for animbot for Maya, for example.
While most of these tools can be created by users themselves, it would take days, even months... Instead, I'd prefer to pay for a yearly subscription, use the tool, and focus on my primary work.
Does that make sense? It seems to me that the current APEX is precisely what riggers require, and with time, the rest of us may have access to tools created by riggers for animators.
Looking at it from a similar perspective, why do we need to create a box in the Houdini shelf when you can go into nodes and meticulously model your own box, constructing the entire network from scratch, vertex by vertex?
Thank you for your insights! It's still valuable to delve into these low-level aspects, of course, but not to the extent that I would want to build everything entirely from vertices
This master lass shows exactly what I mean.
Go for it riggers, but anyone else that just wanna simple rig tool should stay away from it
https://www.youtube.com/watch?v=-0KbPtoP5MU&ab_channel=Houdini [www.youtube.com]
Mirko JankovicNo, it doesn't
. It seems to me that the current APEX is at such a low level that it provides all the necessary controls, which is great for riggers
Current APEX is beta, it's a proof of concept
It provides some control, some nodes, some workflows
But it's missing a lot of nodes, even low level ones, lots of UX to be productive and a lots of workflows
It needs to mature, whether for riggers or anyone, but it's definitely a great showcase of possible potential
even tho some node are missing (I needed a euler to quaternion and other similar function) the RunVex allow to pretty much do anything, so the limit is one's own skill I guess ?
I do know there is a performance overhead to using it, but until apex mature, it allow to virtually do any rig ever.
I do know there is a performance overhead to using it, but until apex mature, it allow to virtually do any rig ever.
JacquesfI'd consider it a workaround that should not be necessary in a robust environment
RunVex allow to pretty much do anything, so the limit is one's own skill I guess ?
On top of that yes, it's been said invoking vex in apex has a performance hit
But most importantly vex doesn't support all the apex types so its really only a workaround for math needs or processing geo, which can of course help a lot
But also at the risk of repeating myself, there is a lot of needs in rigging that the current apex architecture doesn't seem to easily allow for yet or workflows that are not yet in place, like lightweight history dependent constraints or interaction only constraints, etc...
So even vex wouldn't help to solve that as it's more about being able to selectively access runtime evaluated time sampled values, having smart internal caching system, or apex graphs invoked just to process interaction input but not be part of the runtime rig logic
Anyway, from my point of view there is a lot of room for it to mature even for rigging as there's a difference between just being able to do something and actually having a robust toolset that doesn't make it feel like you are doing a lot of workarounds or compromises
Just my two cents: I’ve seen many people in production solve problems using only VEX or Python nodes. While this approach is great and flexible, debugging—especially for others—becomes much easier when generic nodes are used. Everyone knows how they work.
Maya its pretty safe in rigging,if sidefx its going this way.
Learn Bones in sops,no wait learn kinefx/rigvop
Ups sorry learn Apex
Learn Bones in sops,no wait learn kinefx/rigvop
Ups sorry learn Apex