Curve Rivet

Hello there! Last year I was battling with this issue, I have always used ribbons for all my setups that require bendy bones. Once an animator told me something related with them. In some axis, on an extreme position, the ribbon breaks and sometimes we don't need to control the twist. 

Rotation in the secondary axis, no issues

Rotation in the up axis, flipping

I've been looking for an answer, but I've been told to only use SplineIK or Motion Path or a custom node. Therefore, I wanted to do a simple setup to mimic the behaviour of the SplineIK without the issues that it has. Besides, I got interested in doing rigs setup with less DAG nodes. I came across with the way how Vasil Shotarov does the rivet on NURBS Surfaces without any DAG node.

I've been doing several tests related with this approach. I'm going to explain each method to use a curve to drive transforms, without using custom nodes, and explain its advantages and disadvantages.

SplineIK:

• Customizable a bit tricky ✔
• It has a built-in twist setup ✔
• It's required to know the primary and secondary axis ✖
• It's unstable when you stretch ✖
• Require lots of dag nodes and joints in order to work properly ✖
• Can keep the same distance between transforms ✔
• Very heavy for parallel evaluation ✖✖

MotionPath:

• Very simple and straightforward ✔
• It needs a separate twist setup ✖
• It's required to know the primary and secondary axis ✖
• It's stable when you stretch it ✔
• It has issues related with flipping in the up axis✖
• It doesn't require any dag nodes, except for the worldUpObject ✔
• Can keep the same distance between transforms ✔
• Light for parallel evaluation ✔

IkHandle + PointOnCurveInfo + Extend Curve:

• Very tricky setup ✖✖
• It needs a separate twist setup ✖
• Doesn't required to know any axis ✔✔
• It's stable when you stretch it  ✔
• Sometimes it will calculate the rotation incorrectly, I haven't tested it enough ✖
• Require lots of dag nodes and joints in order to work properly ✖
• Cannot keep the same distance between transforms  ✖
• Heavy for parallel evaluation ✖

As you can see here each method has its differences, you will need to outweigh each method and use one of them depending on your necessities. However, I recently discovered a way to solve the flipping, instability and it don't require a bunch of dag nodes. This method I'm going to call it Curve Rivet. I'm going to explain how to set it up.

Curve Rivet:

• Tricky setup ✖
• It needs a separate twist setup ✖
• It's stable when you stretch it ✔
• Doesn't have any issues related with flipping ✔✔
• It doesn't require any dag nodes, except for the worldUpObject ✔
• Can keep the same distance between transforms ✔
• Light for parallel evaluation ✔

I'm showing the graph of the setup, which is quite straightforward. There are a few things to take into account:

• The curve driver must be normalized.
• The orientation of the worldUpObj doesn't matter, because it's been compensated.
• The final composeMatrix should use quaternions not euler.

The whole graph

• As it's shown, we need to know the aimQuat and aimOffsetMatrix. There are several ways to obtain them. I'll show you the method that I use:

import math
import maya.api.OpenMaya as om2
import maya.cmds as mc

"""

tanVector is pointOnCurveInfo.tangent or pma.output3d

objUp is a transform to control the twist

"""

aimVector = [1,0,0]

#How to obtain aimQuat
eulerRot = mc.angleBetween(vector1=aimVector,

                           vector2=tanVector,

                           constructionHistory=False,euler=1)
radRot = map(math.radians,eulerRot)
mEuler = om2.MEulerRotation(radRot,order=0)

aimQuat = mEuler.asQuaternion()

#How to obtain aimOffsetMatrix
aimMMatrix = aimQuat.asMatrix()
objUpMMatrix = om2.MMatrix(mc.getAttr(objUp + '.worldMatrix[0]'))

aimOffsetMatrix = aimMatrix*objUpMMatrix.inverse()

As you can see is working fine, but you may know that the PoCI (pointOnCurveInfo) cannot keep the same distance between the transforms while we move the curve. We can use a motionPath instead of it. This node has a build-in attribute called "Parametric length", which will do what the PoCI can't. The only drawback of the motionPath is the tangent vector is not obtainable from it. For this reason, I will explain the following:

Fake Tangents:

As I mentioned before we can use a motionPath, but it's mandatory to have a tangent vector to create the rivet, so in this case I am going to use what I called "Fake Tangents" which is basically a point which is very close to the base point. We can make a small script to keep the U Value of the Fake Tangent between 0 to 1.

threshold = 0.05
uValueFakeTan = uValue + threshold

if uValueFakeTan > 1:

    uValueFakeTan = uValue - threshold

Let's create another motionPath using the uValueFakeTan on the "U value" attribute. Now we need to obtain the Fake Tangent Vector so to obtain it let's subtract the position of the fake tangent with the base point position using a plusMinusAverage.

After the node "angleBetween" the setup will remain the same as the curve rivet, this variant I call Curve Rivet with Fake Tangents.

Used curve rivet with fake tangents + parametric length

with dual joints (parent + point)

Why not obtain the "real" tangent using PoCI?

I've done many tests about it, but the only thing that we can do to keep using PoCI is using the NPOC (nearestPointOnCurve) to calculate the new position which is provided by the motionPath. That node is very heavy, so is not advisable to use it in large quantities.

Rivet on Beziers?

Sure thing, sometimes we need to do rivets using a Bezier curve, as it's known in Maya we can control the Handle and we can overlap it with the Anchor Point.

However, if we overlap both items, we cannot obtain the tangent using PoCI. For some reason Maya doesn't calculate the tangent of that point, as we see here. This only will happen if our parameter is 0 or 1.

If we want to pin a transform using a Bezier and we know that Handle and Anchor Point will overlap, we cannot use PoCI, the only thing that we can use is Fake Tangents + Parametric Length. 

I'm sharing the scenes if you want to take a look:

Curve Rivet

Curve Rivet + Fake Tangents

That is the complete setup. I'm showing you the results using the Evaluation Toolkit of Maya. I am using an average PC, not a fancy one. In the scene:

• 201 joints.
• 5 controls, randomly animated.
• A curve or surface depending on the case.
• A transform used as worldUpObj.
• Used the matrix constraint.
• The cycle clusters were removed.

Method	FPS
Bare Motion Path	100
Matrix Rivet	96
Curve Rivet	90
Curve Rivet + Fake Tangents	69
Spline IK	41

As you can see this method is quite functional, it can be used for many things, especially for things that need a lot of range of motion. Just it require a transform to calculate the twist correctly. That's all for now and happy rigging!

UPDATED 31/03/2024: Recently I have found a error to calculate aim vector, it's already solved

Geo Connector Rivet

Hello, I had written this post years ago. This a rewritten version. I have a friend who taught me how to pin a transform on a vertex using a particle emitter. I haven't heard about this method, it could be because it is quite old. However, I going to explain in simplified way using just the geoConnector. 

As you know there are several ways to make a rivet (4x4 matrix, uvPin, follice, etc.) This method works quite well for pinning a vertex. The only downside is the performance, that's something to bear in mind. These are the steps to follow:

• Create a set for a single or a group of vertices, if it's a group the rivet position will be averaged between them.

• We create a locator and a geoConnector node.

• Now, we need to create a vectorArray attribute to the geoConnector to hold a connection. We can called whatever we want.

mc.addAttr(geoCon,ln='ComponentPositionStatic',dt='vectorArray')

• We need to find out the groupID, which was created when we create the set. You can localized in the node editor. Remember to turn on the visualization of the auxiliary nodes.

• We need to make these connections.

• The rivet setup is complete.

• However, we have in the outliner a set without any function. Moreover, this depend on the number of rivets that we have in scene. Well, here is the solution for that. Just disconnect and delete in that order.

• If we made everything as it was explained, the rivet will keep working.

Things to take into account:

• We need to do this after applying all the deformation to our mesh. If we create a deformer after the rivet was created, it won't work when you reopen the scene.
• This method is not parallel friendly, because of the geoConnector. Use it wisely.

That's all for now. Thank you

Set Default Tool

Hey there! I am back. First of all. Happy New Year! I hope to keep posting things. 

This post will be brief. Some times we need to set a default values for float or integer attributes on the channel box. Maya doesn't have a tool to do that, you need to do it by cmds. This is particularly useful when the default value is not 0. We can use the next command to query the default value, to reset the attribute.

dValue = mc.addAttr(source + '.' + attr, q=1,dv=1)

mc.setAttr(source + '.' +attr, dValue)

So, I built a simple tool for that. You just need to select a custom attribute float or integer and press the button. The value won't change, but internally the default value will.

The code:

I hope you find this helpful. Thanks

Local Rigging vol. 2

This post is the continuation of the previous post, please check it before read this one.

Relative World:

The main idea of this setup is allow you to create groups above the controls and the joints will keep following the controls, but they are not going to follow the controls if they are moved from a certain group above them. I'm going to name each component: the control (source), joint (target), a group above the control (top parent). The top parent is not necessary to be an immediate parent of control. Some notes to take into account:

• The offset is the offset between the source and the top parent.
• In this case I'm not using the parentInvertMatrix of the target, because I don't want to create more cycles for parallel evaluation. Instead I'm turning off the inheritsTransform.

So if everything is done correctly, all the controls will work properly and the groups above them will also work correctly. However if you move the top parent, the joints won't move at all. 

This is an alternative method for local rigging. I hope you find it useful.

Local Rigging vol. 1

Recently, I took the course of Optimizing Rigs for Parallel Evaluation on Rigging Dojo by Charles Wardlaw, a very good course by the way. One of the topics that he explains is the local rig. When I started doing rigging years ago ( I feel old now D: ) I made local rigs for many parts of the face without any control, for the eyebrows, for eyelids, for lips, for mouth, for everything. The main problems that I faced was the normalization of the skinCluster and if you don't have a good control of that, it can be a nightmare to edit the rig. Moreover, when you want to move a control and at the same time the joint, you will need to duplicate the setup on the local rig. Since, I built my own autorig system I tried to avoid that, but the main problem of having the whole setup on a single chain is the performance. Obviously, if you want to export the skeleton to a game engine is mandatory to have the whole system on a single chain, but for films is not required.

The skeleton hierarchy of half-life 1 models

I bumped up with the idea of using locals rigs without using direct connections from controls to joints. I discovered two methods that you can use to approach this setup. I divided this into two posts

Reciprocal Driving:

This setup is a bit complex to make, but if you understand it, you will get good results. First of all, you need to make the setup (groups, parents, constrains, etc.) on the local rigging group not in the global rigging. In the global rigging, you will only put the controls and a couple of groups above them. First I will name the transforms that are involved:

• controls = animatable controls
• relative controls = controls on the local rigging
• buffers = group above the animatable controls

The connections will be like this:

1. Direct connection from the control to the relative controls (T,R,S)

2. We will use the parent matrix of the relative controls and we will multiply by itself but static and inverted. The result should be an identity matrix, then we will decompensate the matrix and connect to buffers or use the offsetParentMatrix.

I am using a compose and an inverse matrix, but you can use pymel or openMaya to make this operation

without this nodes

Voilà! You now have a local rigging setup if you want to create more groups above controls, maybe to control them, just create them above the relative controls. The only downside that I found is this only will work if the all the controls are not parented between them.

In the next post I will explain the second method, which is very different from this one. See you there and happy rigging!

Maya Wheel Rig with Constraints

Sometimes I need to rig vehicles, and one of the things that are done very straightforward is the wheels. For the most part I have used the classic algorithm.

Generally "d" is always or almost always used as a local translation axis, to avoid further complications. However, this does not work very well in all cases. I've seen a video where explain a different method using the same formula. The tutorial was made by Andrew Christophersen. It's quite old, but he uses some good technics like the dot product to obtain "d". Nevertheless this could be simplified using just a couple of constraints.

The general idea is to obtain a global z-translation. For this we create a locator outside the control that will move the tire and another one inside. Then we create a group above the outside locator. We make a pointConstraint from the inside locator to the outside locator. Then we make an orientConstraint from the control that will move the tire to the outside locator group. 

$autoRot = "global_ctrl.autoRotate";
$rad = 41.8101;

wheel_ctrl_expression.rotateX = 360*wheel_out_loc.translateZ/(2*3.1416*$rad);

The result basically will be the same as the video tutorial, but personally I find it easy to understand. A video demonstration.

I hope you find this useful. Thanks

IKFK switch using matrices

After all these years, more than 4 years. I've had rough time, but I'm back. Since I started using matrices for all my rigs, I came across the idea of using matrices for switching IK to FK. I've seen other methods to achieve this approach, but require new nodes like pickMatrix or blendMatrix which can be useful, but for this time I'm going to simplify the connections making it simpler.

To blend them I'll use blendColors and pairBlend nodes, to avoid the unitConversion from degrees. Here is the connections in the node editor.

From my point of view is a simple setup. Require 10 nodes to achieve it. It has some rules to follow but still very simple.

Rules:

• BK chain is the Blend Kinematics chain

• The dag node "L_Forearm_FK_CN" is child of  "L_Upperarm_FK_CN", same in the IK chain

• The dag node "L_Forearm_BK_NULL" is child of  "L_Upperarm_BK_NULL"

• The FK and IK chains don't need to have the same rotation order

• The BK chain needs to be in xyz

The connections of  the first node of the chain is slightly different, in the "localSpace_MultMatrix" it will go just the first chain and in the node "worldSpace_MultMatrix" in the index [1] it won't need any connection. Just as simple as that. I hope you find it useful.

IKFK switch using matrices from Steffano Richi on Vimeo.