Hello all,

Introduction
It's my first time posting on the forum, so I will briefly introduce myself. I am a game dev student at Breda University (formerly known as NHTV Breda in the Netherlands). I primarily specialise in motion-capture animation, and for a while now, I have been looking into rigging. Since we got taught Maya in our first year, that is where I started. However, after spending some time in Houdini to create a procedural environment for a school project, I liked Houdini so much that I decided to look much deeper into it. By now I have learned enough that I am rigging all characters for my current project in Houdini.

To learn how to do rigging in Houdini, I followed several tutorials, including 3D Buzz's Technical Rigging and Advanced Character Rigging volumes, as well as Michael Goldfarb's rigging series (at least, the videos that have been released so far). I have made this post to give all my feedback on Goldfarb's series because I think it will be much easier/clearer to understand in one post rather than posting one comment under each individual video. Some of my points are about more intermediate rigging topics so they can be taken with a grain of salt if you think it is too advanced for a beginner tutorial series.

TL;DR
Here is a TL;DR version of my major points of feedback:
- Parent space blending with the if(ch("../"), 1, 1, 0) condition is a broken/not fully polished feature, which makes it a nightmare to animate with. Sadly, Goldfarb skips the steps to make it work properly (smoothly).
- Scripting is an essential part of rigging. This series only briefly explains what the scripts do, and therefore does not teach the student a strong foundation in scripting, because the student can just download the scripts and not learn anything about writing it.
- Some of the scripts can be improved. For example, the SplitBone tool doesn't actually use the given input name for the split bones. Strangely enough, the script works correctly in the video.
Another example is the TwistExpression tool. This tool is hardcoded, meaning that it expects a certain amount of bones. Perhaps the script is intended for situations with four bones, but it would probably much more useful if it could work with any number of bones.
- Optimisation: there is hardly any talk about optimising a rig (this may come in later parts, but I want to mention it anyway).

Alright, let's get deeper into this.

Stepping through parent spaces
At some point in the series, Goldfarb implements a parent blend constraint for the IK goal controller. Setting up the constraint is fairly simple until we get to the point where the blends in the constraint need to have the right values. Michael uses an if condition: if (ch(“../") == 1, 1, 0). The problem with this condition is that it makes the blend values either 0 or 1, with no floats in between. This may seem correct for the blends because we don’t want incomplete blends (50% space A and 50% space B), but over time it doesn’t work. Here is what happens:

Let’s say we keyframe the space on frame 1 on “World”. Michael uses 4 possible blend spaces, of which “World” has index 0. This means that on frame 1 only blend1 is 1 and the rest is 0. If we now go to frame 10 and key on “Chest”, which has index 2, blend3 will turn to 1, and the rest, including blend1 for “World”, will go to 0. If we now play this animation, we’ll see that the blends only change on 2 frames in between frame 1 and 10. Around frame 3, the parameter will change from “World” to “COG” (index 0 to index 1 in the menu) and around frame 7 from “COG” to “Chest” (index 2 to index 3). And if we pay careful attention, we’ll see that the blends don’t blend smoothly from 0 to 1 or 1 to 0; instead, they act as if they were animated in stepped mode, which causes them to jump from 0 to 1 or 1 to 0 suddenly. If you were to keyframe the IK goal in different positions on both keyframes, you would notice a shocking move that is the effect of the blends being animated like that.
That is where the big problem is; the if-condition will never allow the blends in the constraint to blend smoothly from 0 to 1 or vice versa over multiple frames because it always snaps to either 0 or 1.

So, what could be a solution to this issue? One could be that SESI implements a built-in fix. For example, they could implement a feature that allows the user to keyframe multiple parameters in the HDA by keyframing only a single parameter in the UI. This would enable us to keyframe the blends in the constraint when we keyframe the IK space parameter. And then we can make those keyframes interpolate smoothly. With the if-statement from the series, this is impossible to do.

Conclusion
My point of feedback is that Michael didn’t go in-depth enough for this system to work well for an animator. If you follow(ed) the series, implemented it this way and then gave the rig to an animator, he will come back to you within a few minutes to tell you that the feature is broken and it would be easier to animate without it than animating with the function implemented like this. I suggest for a next series to prove that a feature works after implementing it, by testing it over a few frames.

Improving scripts
It is pretty sweet that Michael provides everybody with scripts that are free to download. However, I think some of the scripts could use improvement.
For example, the SplitBone tool, which is used in the arms and fingers to split the bones into a custom number of bones, has an issue with the naming. When pressing this shelf tool, it shows a pop-up window asking for a name for these new bones. Upon pressing <OK>, it is supposed to name the new bones with whatever the user wrote down. This is bugged, though, because the tool never uses the new name. In the script, one can see that the name of the new bone will always be named "_split", regardless of user input. This is, of course, a simple bug that can easily be fixed so my point of feedback would be to solve that issue.
Another example is the TwistExpression tool. This tool is hardcoded, meaning that it expects a certain amount of bones. If you give it a different number of bones, it will show an error. I think this could be improved because it looks like this tool should be usable on any number of bones. Unfortunately, since the script is pretty much entirely hardcoded, it will require an overhaul if it were to work for any amount of bones.

Learning to write code
As many riggers will probably agree, writing scripts is an essential part of the rigging process. But how does one learn to do this? As Dr Strange said: “Study and practice.” And that is what I think should happen in a beginner's tutorial. Simple tools that are used countless times, like the FKControl tool, could be used as an excellent example of a script that can be used to learn the foundations. Michael goes over the script briefly, so we have a rough idea of what the code is doing, but I think that it is not enough to learn how to do it yourself. There are tutorials and a library of documentation on basic commands, but I still think it should be included in this series, because it is so focused on introducing new people to rigging in Houdini, and thus it should introduce them to scripting (most likely in Python) as well.

Rig optimisation
As mentioned earlier, the FKControl tool is useful to create a controller quickly and is used frequently in the series. The tool creates 3 new nulls and using it over and over again generates a sea of nulls that one could easily get lost in, despite everything being named correctly. Plenty of these nulls exist only because they were created by the FKControl tool, but are never used. It would be nice if there could be some information on how this impacts the performance of the rig.
Besides, there is also a lack of in-depth discussion on when it is better to use constraints over relative references or vice versa. Setting up relative references is much quicker than making constraints for every bone in a rig, so there should probably be a discussion about which is better.

To rig for games or not to rig for games
There are many posts online in which people wonder how they can accurately export their animation to a game engine. This starts with building a compatible rig. I think that the series does not make clear that this rig is not designed for game animation, so I suggest the description of the series should mention this. It also leads me to a new tutorial request: it would be great if there could be a series that goes deep into how to build rigs for games and export them correctly.

Miscellaneous questions
Some general questions that I would like to have an answer to:
- Why are the body parts not stored in the HDA right away?
- Why does every limb have its own Geo Display option? Once the final character is skinned to the bones, is it possible to hide specific primitives or do you hide the entire skinned geometry?
- What could the Python SOP be used for? Since this is cooked on every frame, I suppose it has its uses.

thanks for the feedback.
Since rigging is a huge topic and everyone wants something different from a tutorial this series was intended to be a basic introduction to rigging a biped in Houdini - and is very much based on a series done in Maya that a number of people mentioned as one that they felt provided a good start for those just beginning to rig (https://3dtotal.com/tutorials/box-sets/maya-animation-rigging-with-jahirul-amin).
The series was not intended to cover all aspects in great detail - many, many people wanted something simple.
And the series was not intended to produce a production ready asset - so many things are introduced but not taken ‘all the way’, since many users would want various things to operate differently etc.
I hope that the series serves as a good foundation and reference moving forward - and I hope to add updates as time goes on and as needed - there are already some new things in Houdini 17
Regarding the scripting - again this series wasn't intended to to teach scripting, but rather to introduce some concepts and to see some examples of how scripting can be used in Houdini for rigging - not to provide battle tested tools for production.

Rigging for games wasn't within the scope of the series for the above reasons and because my background is Film/TV and I didn't want to make any assumptions about rigging for games until I had learned a bit more about the specific needs in game dev - this is a topic that we intend to cover in the future.

Ids
Some general questions that I would like to have an answer to:
- Why are the body parts not stored in the HDA right away?

mostly because I usually make some kind of mistake here - and it's a paint to remove the geo and re-embed

Ids
- Why does every limb have its own Geo Display option? Once the final character is skinned to the bones, is it possible to hide specific primitives or do you hide the entire skinned geometry?

some animators like to work with the proxy geo for blocking etc - some being able to turn off parts of the body can be useful, and yes it is possible to hide primitives of the skinned mash.

Ids
- What could the Python SOP be used for? Since this is cooked on every frame, I suppose it has its uses.

you could use the python SOP for rigging/setup type things - but I'd avoid it in an asset used for animation, as you say it'll cook every frame.


thanks again for the feedback.

Few words from a person who is learning rigging - I found this tutorial very good. SideFX tutorials are always very good, but even in this noble company this one shining. Pacing, balance, and amount of information is spot on. I'll look for continuation. Thanks a lot!

After few more hours:

It is amazing, that I can not only follow this tutorial, but, in case of mistake my new knowledge allow me to find and correct it later.
It is partly due to very good tutorial but node representation of rig really shines in situations like this. I found this proces quite clear, much simpler than I thought.

what I don't like in a process:

- I know rigging it's a knowledge, discipline and patience, but proxy objects with nulls inside that's need to be reenabled after every change it is a low ball. This should be fixed by another script, because it's really badly streamlined.

- Scripts attached on sidefx site are old and not working properly. Some nice fellow (edschiffer - props!) posted newest working version in comments, and that saved my ass when I started to make controls for fingers.



Anyway, still following this (and making my own rig) and love every minute. I learn few new things about UI and HDA, so that's a bonus.