esttri
Ah yes, we are currently missing one additional input parm that needs to be exposed on the curve callbacks that will help with the fixed length!
Vex would be the less favorable solution because it creates quite the performance overhead and it can slow your rig down!

Any news on that?

Not yet, but it's right up next on the TODO list to look at the *Spline* callbacks. If there's no bug/RFE logged, please make sure you put them in.

Hi everyone. I'm just catching up on this thread. Thank you all for the various bug reports and RFEs. I can provide a quick update on a couple of the topics of discussion here.

The next major release of Houdini will provide the following updated nodes:

• rig::SampleSplineTransforms::2.0
  
• rig::SampleSplineTransformsToArray::2.0
  
• rig::SplineInterpolateTransforms::2.0
  
• rig::SplineInterpolateTransforms::2.0
  

These nodes have fixes for the uneven twisting behavior, as well as various other interpolation instabilities.

Support for arbitrary joint orientations
The original nodes were expecting transforms to follow a historical houdini convention that the -Z axis represents the tangent axis of the transform. With this update, a new "tangent" parameter is added such that users can inform the nodes which vector is their desired tangent vector. For example, if "tangent" is set to (1, 0, 0), then the +X axis of the output transforms will be aligned to the next transform in the output hierarchy. This also means that the control matrices must follow the same convention (in this example, using +X as their tangent direction).

Other Considerations
Internally, rig::SplineInterpolateTransforms builds a bezier curve from the input control matrices. The order of the internal curve can be adjusted by the "order" parameter. This has the direct consequence that the number of cvs needs to satisfy the requirements of a bezier curve. Specifically, the constraint number of cvs % (order-1)must be satisfied.

We may attempt to make this more flexible in the future by adding a parameter which switches the internal curve to a nurbs curve. However, if you need that flexibility today, you may consider using "rig::SampleSplineTransforms::2.0" or "rig::SampleSplineTransformsToArray::2.0" instead. These callbacks can accept a bezier curve, nurbs curve, or poly line with a "transform" point attribute representing the control matrices. So you should have maximum flexibility over the number of cvs if you feed it a nurbs curve, since a nurbs curve doesn't have the same constraint. The points of the curve (along with the transform attribute) represent the same control matrices that are passed to rig::SplineInterpolateTransforms; however, instead of building the curve internally, it is provided to the node.

There are many spline RFEs on the books, so we look forward to continuing the improvement of these nodes' capabilities. Hopefully, you'll find these updates to be positive improvements that you can work with today!