I recently had a problem with this, and found this thread:
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=15315 [sidefx.com]
Where someone else had similar problems, but I don't think many people have seen it, so I'm posting the problem here.

I found some free mocap files at the CMU site, and converted one into the biovision format. I used Houdini's mcbiovision (with no options) to generate .cmd and .bclip files. I sourced this (the .cmd file) into Houdini, collapsed the various nodes into a subnet, set the CHOPs data source correctly, and the resulting skeleton animated fine.

I then used the biped auto rig. I get everything set up, and then I generate the animation/deform rigs. I used the “Generate Mocap Rig”, and (I think) associated the skeleton bones with the various rig parts in the dialog asset.
However when I click “Accept” I get a python error in:
houdini/scripts/python\autorig\mocaprigutils.py, line 180

which, on my installation is:
avglength = distance / len(chain)

It would appear that the “chain” array is empty, so we're getting a divide by zero error. Any ideas on how to deal with this? I've tried this same mocap data with the Toon character and get the same error.

Running 64 bit Houdini on Windows Vista 64, Houdini version 10.0.554.

After fiddling some more, I did get this to work with the Toon character, although it does cause some problems. I still can't get it to work right with the Biped character. I *think* it has something to do with what bones I'm picking on the skeleton, but I can't figure out which ones to pick.

I'm trying to get this to work in order to animate something for a competition, so I'd really appreciate the help. I've included the hip file, the original bvh file, the .cmd file and the bclip file.

I meant to reply sooner. Sorry about that.

Looking at it, the problem is caused when the script tries to deal with certain features of the arm where it might need to backtrack up the hierarchy to find some bones/lengths for when you have bones mapped that might not be connected.

Basically it is failing because the input bone is the one we want but I suppose that when I wrote this way back when there might have been some differences in bone hierarchies between between the biovision and acclaim types. In the acclaim ones it looks like we would always find at least one inbetween bones and hence the list would always have >0 elements. At least I think anyway. It's been a while and it always was confusing.

To fix it you'll just need to wrap the line in a couple things. It should read like this:
if len(chain) is not 0:
avglength = distance / len(chain)
else:
avglength = distance

This fix allowed the rig to be generated for me.

OK, thanks. I'm in windows, do I just edit the file ine notepad, save it and restart Houdini? I notice that when I open it with Scintilla it doesn't seem to have tabs, and since Python is tab sensitive…

Sigh, it's more complicated, it would appear that all these files in houdini/scripts/python/autorig/ are all python compiled? Or at least there's .pyc file for each .py file. What the correct procedure for handling this?

You just need to modify the .py file. The pyc file will be recompiled when either restarting Houdini or reloading the module. Notepad should be fine to do this. After you have modified the file you can either restart Houdini, or in Houdini's Python Shell enter the following. After that it should be fine.
import autorig.mocaprigutils
reload(autorig.mocaprigutils)

Thanks Graham. I did try notepad, but because of the way the new lines are done, it's uneditable in Notepad. Write was OK. My only concern then was the tabs issue, but everything seems to use 4 spaces (instead of Tab characters), so presumably that will work OK?

Graham,
No luck. Using the file I've posted here, now I just

2440: Fatal error: Segmentation Fault

I made the python changes you suggested. Any ideas what I need to do next?

Is it always this difficult to bring in mocap data? Or is this a problem with the file?

I upgraded to the latest production build, 10.0.595, adjusted the python script and I still get the same error/crash. I'm adding my settings that I'm using for the various skeleton bones, maybe they are bogus.

{'right_leg': , ‘right_arm’: , ‘spine’: , ‘left_leg’: , ‘head_and_neck’: , ‘left_arm’: }

I really can't suggest why it is causing Houdini to crash. I've tested it with the same mappings and always get the rig generated. Same goes with other motion files as well across multiple builds all the way back to Houdini 9.1.

As to how difficult it is to bring in data, that will always be dependent on what you are trying to do with it. This system is just one way you could do it and is specific for dealing with how the Autorig is designed. We came up with a system that met the goal of being able to fairly easily apply animation from a motion skeleton to an Autorig.

However, the success of this, or any system really, is of course dependent on both the design of your rig, as well as how well the motion matches the skeleton. Unless your model is created and rigged with the same proportions as the actor providing the source for your mocap, you will run into issues.

An example is trying to apply motion to the Toon Character. I've applied motion where in the source the hands start out together. Applying that to the toon character results in the hands intersecting at the start. This is caused because while the arms may be of similar proportions, the clavicle bones of the Toon rig are much shorter. So while the motion is technically correct, the visual result is wrong.

If I just had a rig that was made up of bones and controls, not the Autorig, then my method of using that animation would be quite different.

OK, thanks for the info. Well I'm stumped as to what to do next.

I guess I can try this on OSX, and see if it works any better or worse.

If that fails, then can I manually associate the channel data with a particular part of the animation rig? If so, any guidance on what goes where?

If I don't do that, I could just try and use mocap skeleton as a reference, and then key frame the animation rig to match as closely as possible.

Well I just tried with the 32bit version of Houdini and that worked OK. Of course the results are horrible looking, but maybe this is a starting point.