{"id":1168,"date":"2026-04-16T19:57:08","date_gmt":"2026-04-17T02:57:08","guid":{"rendered":"https:\/\/www.toadstorm.com\/blog\/?p=1168"},"modified":"2026-04-16T19:57:10","modified_gmt":"2026-04-17T02:57:10","slug":"revisiting-parallel-transport","status":"publish","type":"post","link":"https:\/\/www.toadstorm.com\/blog\/?p=1168","title":{"rendered":"Revisiting Parallel Transport"},"content":{"rendered":"\n

I was asked the other day about fixing a little issue with MOPs Orient Curve<\/a>, a node that really hasn’t changed much in MOPs since it was first launched way back in 2018. Most of the reason it hasn’t been revisited is because a few versions ago SideFX created their own curve orientation tool, the aptly-named Orientation Along Curve SOP, which more or less does what MOPs Orient Curve did but with more technical options. <\/p>\n\n\n\n

However, the user was having trouble getting Orientation Along Curve to do exactly what he wanted and I figured I’d take a second look at the MOPs tool as it was one that was originally written by Manu from Entagma, using the Parallel Transport method outlined in his handy VEX tutorial<\/a>. I never had to get too involved in this part of the toolkit because Manu already handled all the math for me, so this was a perfectly good excuse for me to learn the algorithm and see if I could improve the functionality a bit. Hopefully this is also a good look at how this algorithm works for the reader who doesn’t want to watch an eight-year-old Vimeo tutorial.<\/p>\n\n\n\n

First, the source issue: on a closed circle, why do the end points at the 3 o’clock position here have slightly skewed<\/strong> orientations?<\/p>\n\n\n\n

\"\"
The instances at the 3 o’clock position have slightly skewed orientations. This position is where the first and last points on the circle primitive meet.<\/figcaption><\/figure>\n\n\n\n

The problem is grounded in the fact that the 3 o’clock position on this particular circle are where the first and last points on the circle primitive meet. Manu’s original implementation of the parallel transport algorithm, based on this paper here<\/a>, starts on the first point of the curve and computes orientations from first point to last point. Each point is figuring out what its tangent vector is (what direction points to the next location on the curve) based on the position of the next point in line. If there’s no more points in line, though, the algorithm just extrapolates the next tangent based on what the previous one looked like. It wasn’t really meant for this edge case where the start and end points are linked!<\/p>\n\n\n\n

What’s parallel transport?<\/h2>\n\n\n\n

Let’s take a step back and talk about what this algorithm even does. If you read the linked white paper it looks like a bunch of insane wizardry because, like all good white papers, the math has to be done with proofs, and if you’re not used to reading those it looks like absolute hell. However the idea behind it and the implementation of it, when done on discrete sets of points like what you deal with in 3D graphics, is really not terribly complicated.<\/p>\n\n\n\n

The goal of parallel transport is to create a smoothly-transitioning orientation along a set of edges so that you don’t end up with sudden flips or discontinuities along the line. If you’ve ever tried to animate something along a path or copy objects to the points of paths with lots of twists and turns, you’ve likely seen this problem before. Here’s a loopy curve with an orientation created by the very naive Polyframe SOP that just guesses at orientations based on computed tangent and normal vectors:<\/p>\n\n\n\n

\"\"
A curve with orientations created by the Polyframe SOP (visualized by MOPs Visualize Frame). Note the discontinuities in the circled areas.<\/figcaption><\/figure>\n\n\n\n

You can see in those circled areas that there are sudden flips in the green and red vectors. This happens in part because each point on the curve is more or less computing its local tangent (blue) and normal (green) vectors independently of any other location on the curve; they just look at their immediate neighbors and figure that’s good enough.<\/p>\n\n\n\n

Now the same curve orientations computed via parallel transport:<\/p>\n\n\n\n

\"\"
The same curve, with orientations computed by parallel transport.<\/figcaption><\/figure>\n\n\n\n

The core idea here is simple: starting at the beginning of the curve, get the tangent to the curve and a normal vector. Then for each successive point along the curve, figure out the angle that would rotate the previous tangent vector to match the next tangent. Then rotate the normal vector by that same angle, around the binormal<\/strong> (the red vector in the above images). The binormal is a fancy way of saying a vector that’s orthogonal to the tangent and normal vectors, meaning it’s an axis perpendicular to both those other vectors.<\/p>\n\n\n\n

If you’ve ever read my Even Longer-Winded Guide to Houdini Instancing<\/a> you might remember that in order to compute an orientation you need to have three vectors: a “forward” direction, an “up” direction, and a “side” direction. The “side” direction, however, can be automatically computed by determining the cross product<\/strong> of the other two vectors. Crossing two vectors gets you a third vector orthogonal to the other two. In parallel transport we’re doing the same thing to get the binormal vector that we use as the axis of rotation for our normal vectors.<\/p>\n\n\n\n

By incrementally applying these small rotations to the normal vectors along the length of the curve, the algorithm ensures that there’s no sudden flips or discontinuities in orientations while passing along the curve, regardless of how many twists and turns are present. Conceptually it’s not too bad! The implementation is, as always, the annoying part.<\/p>\n\n\n\n

Computing Tangents<\/h2>\n\n\n\n

The first thing to do to make this algorithm work is to compute the tangents along the curve. In Manu’s original implementation for MOPs, the tangents were always computed by starting at point i<\/code>, looking ahead to point i+1<\/code>, subtracting their point positions from each other, and normalizing the result. This gets you a vector pointing to the next point along the curve. This was the original VEX code:<\/p>\n\n\n\n

\n
for (int i = 0; i<pntcnt-1; i++)\n{\npush(tangents, normalize(point(geoself(), \"P\", pnts[i+1]) - point(geoself(), \"P\", pnts[i])));\n}<\/code><\/pre>\n<\/blockquote>\n\n\n\n
However, as we saw in the first illustration, this fails when you have curves that join at the ends. It also tends to run into trouble when you have curves with sharp corners; those abrupt changes in direction can mean anything you copy to those points or slide along them will have similarly sudden changes in orientation you don’t want. So what to do?<\/p>\n\n\n\n
\"\"
A curve with sharp angles. Note how the blue forward vectors always point to the next point along the curve; on sharp turns this can be very sudden! The circled red gnomon shows the joined start and end points, again computing the wrong angle because the last point doesn’t have anywhere to look forward to!<\/figcaption><\/figure>\n\n\n\n
Rather than using point numbers to determine the next point along the line, we can instead use vertex connectivity<\/strong>. We can see that the first and last points on the curve are joined together as part of a single polyline primitive, but points alone don’t have this connectivity information. Vertices do!<\/p>\n\n\n\n
One of the extremely cool things about Houdini is that so much of the various contexts use points and vertices to describe things beyond just geometry. Rigid body and Vellum constraints are two-vertex primitives connected together with a single polyline primitive. APEX graphs are just geometry, with points describing functions and parameters and vertex connectivity describing inputs and outputs to these functions, like a node graph. Most importantly for us, the KineFX rigging system also uses vertex connectivity<\/strong> to define parent\/child relationships between joints. This means we can lean on the KineFX helper functions in VEX to quickly and easily determine both the next and previous points of each point along the line, without getting in the weeds with pointvertex()<\/code> or pointhedge()<\/code> or anything else. It takes a certain kind of sick person to actively want to do anything with half-edges<\/a> and I figure most of my readers here would rather find an easier route.<\/p>\n\n\n\n
The library in question we want is the KineFX helper library for rig hierarchies, called kinefx_hierarchy.h<\/code>. It lives alongside a bunch of other KineFX-related libraries (totally worth checking out) in $HFS\/packages\/kinefx\/vex\/include\/<\/code>. If you open it up in a text editor, you’ll see a couple of important functions here, namely getparent()<\/code> and getchildren()<\/code>. These two functions crawl along half-edges, using the connectivity of polyline vertices to determine the previous (parent) and next (child) points on the curve. So anyways let’s steal them! All you have to do is start your Primitive Wrangle (because we’re iterating over points in a primitive, in order of points) with this line:<\/p>\n\n\n\n
#include <kinefx_hierarchy.h><\/code><\/pre>\n\n\n\n
You can do this with other built-in VEX libraries, too. It’s worth spending some time checking these out and studying them if you’re reasonably comfortable with VEX.<\/p>\n\n\n\n
Forward Tangents<\/h3>\n\n\n\n
Now we want to compute the tangents for each point along the curve, using the getchildren()<\/code> helper function. The first point in the array returned by getchildren()<\/code> is the nearest connected downstream point. We’ll set this up in a Primitive Wrangle so that it operates in the order of points on the curve:<\/p>\n\n\n\n
#include <kinefx_hierarchy.h>\nint pts[] = primpoints(0, @primnum); \nvector tangents[];\nvector normals[];\nvector first_normal = point(0, \"N\", pts[0]);\n\nfor(int i=0; i<len(pts); i++) {\n    \/\/ FORWARD TANGENTS\n    int desc[] = getchildren(0, pts[i]);\n    int child = desc[0];\n    if(len(desc) > 0) {\n        \/\/ tangent is child's position minus mine\n        vector P1 = point(0, \"P\", pts[i]);\n        vector P2 = point(0, \"P\", child);\n        vector tangent = normalize(P2 - P1);\n        push(tangents, tangent);\n    } else {\n        \/\/ no children found, duplicate previous tangent\n        push(tangents, tangents[-1]);\n    }\n    \/\/ add default normal to populate normals array\n    push(normals, first_normal);\n}<\/code><\/pre>\n\n\n\n
What we’re doing here is creating two empty arrays, one for tangents and one for normals (since we need both to compute the final orientations), and then populating those arrays one at a time with the tangents of the curve and with the first<\/em> normal found on the curve. The first normal is our starting point for all other rotations; we’ll be overwriting all of the other normals later on. To get the tangents, we get the first point number returned by getchildren()<\/code>, get the position P<\/code> of that point, and subtract the position of the current<\/em> point from that point. Normalizing the result gets us a vector that points straight down the curve to the next point in line. If the length of the array returned by getchildren()<\/code> is zero, then the point has no children and we just use the last index of the tangents array and copy it (index -1<\/code> is Python-like array syntax for “get the last index”).<\/p>\n\n\n\n
Backward Tangents<\/h3>\n\n\n\n
We could also go in the other direction… compute the tangents by looking backwards<\/em> to the parent point. On some curves this might be preferable to looking forwards! The code is very similar, we’re just relying on getparent()<\/code> rather than getchildren()<\/code>:<\/p>\n\n\n\n
for(int i=0; i<len(pts); i++) {\n    \/\/ BACKWARD TANGENTS\n    int parent = getparent(0, pts[i]);\n    \/\/ tangent is parent's position minus mine\n    if(parent > -1) {\n        vector P1 = point(0, \"P\", pts[i]);\n        vector P2 = point(0, \"P\", parent);\n        vector tangent = normalize(P2 - P1);\n        push(tangents, tangent);\n        push(normals, first_normal);\n    } else {\n        \/\/ there's no parent, so we must be the first.\n        \/\/ look ahead to the next point, but reverse the result\n        \/\/ so we're still pointing in the same direction we expect.\n        vector P1 = point(0, \"P\", pts[i]);\n        vector P2 = point(0, \"P\", pts[i+1]);\n        vector tangent = normalize(P1 - P2);\n        push(tangents, tangent);\n        push(normals, first_normal);\n    }\n}<\/code><\/pre>\n\n\n\n
If you look at the definition of getparent()<\/code>, it returns -1 if there’s no parent found. If a point has no parent, we can safely assume it’s the start of the curve, so we just look to the next point in line to get the tangent vector and then reverse it so it’s pointing in the same overall direction as the other tangents will be.<\/p>\n\n\n\n
Averaging Tangents<\/h3>\n\n\n\n
A third option would be to get the average of both neighboring tangents. We can look ahead for the forward tangent, look backwards for the backward tangent, flip one of them, then average them both together to get a blended result. For curves with sharp corners like the above example, this can sometimes get us smoother results. Check it out:<\/p>\n\n\n\n
 for(int i=0; i<len(pts); i++) {\n        \/\/ AVERAGE OF BOTH TANGENTS\n        int desc[] = getchildren(0, pts[i]);\n        int child = desc[0];\n        int parent = getparent(0, pts[i]);\n        \n        vector P1 = point(0, \"P\", pts[i]);\n        vector P2 = point(0, \"P\", child);\n        vector P3 = point(0, \"P\", parent);\n        \n        \/\/ average between forward and (flipped) backward tangents\n        vector tangent1 = normalize(P2 - P1);\n        vector tangent2 = normalize(P3 - P1) * -1;\n        \n        \/\/ exceptions for start and end points\n        if(len(desc) == 0) {\n            tangent1 = tangents[-1];\n        }\n        if(parent == -1) {\n            tangent2 = tangent1;\n        }\n\n        \/\/ blend forward and backward tangents\n        vector tangent = normalize(lerp(tangent1, tangent2, 0.5));\n        \n        push(tangents, tangent);\n        push(normals, first_normal);\n    }<\/code><\/pre>\n\n\n\n
Tangents Comparison<\/h3>\n\n\n\n
We’re getting ahead of ourselves a bit here but it’s helpful to see a visual comparison of these different approaches to computing tangents:<\/p>\n\n\n\n
\"\"
The tangent vectors are blue. Normals are green, binormals are red. Note the subtle difference between the “forward” method and the “average” method around sharp corners.<\/figcaption><\/figure>\n\n\n\n
As an aside, notice how the tangent of the point all the way on the far left (the one that was circled before) isn’t pointing out into space anymore? This is because of our new approach to getting tangents based on connectivity instead of point number! We still have to actually implement the algorithm, though…<\/p>\n\n\n\n
Computing Normals<\/h2>\n\n\n\n
Now that we have the tangents figured out and added to an array, it’s time to actually calculate the normals. If you look at page 9 of the white paper, you’ll see this extremely helpful (but somewhat confusing) pseudo-code for the algorithm:<\/p>\n\n\n\n
\"\"
Pseudo-code for the parallel transport algorithm.<\/figcaption><\/figure>\n\n\n\n
Translating this into something a little more human-readable:<\/p>\n\n\n\n