I find that the number of points *does* in fact affect the result. When you have non-1V degree surfaces, you end up with less intuitive motion on the locator. It’s not about evaluation time, but rather about keeping the tangent vectors crossing each other in predictable ways.

By clustering a line of V cv’s and then rotating that line around the cluster, the path the U surface isoparms take through the surface becomes a bit skewed.

In the end as long as the rig doesn’t flip out and makes pictures, that’s all that matters; if you’ve had success with the normal constraint then I can’t say anything about that. I don’t use it because I haven’t had any problems with my method and since I know the surface normal is created from the cross product tangent U and V vectors, I like using the source vectors. The point of the post was that the rivet script which everyone uses can be improved upon, and that by using a script only as a black box of functionality you miss out on learning more about your software under the hood, as well as on potential fixes for poor behavior.

There’s something happening with the ” symbol here which prevents code from running when copied from this thread and pasted into a script editor on OSX. I had to run it through a plaintext converter to get it to work.

Anyway, your example works, but I was posting the above as an indicator of a situation of where it might not work, and a normal constraint would work a bit better.

Having a non-1 V degree won’t affect the result of either example. It’s true that using a smaller number of points is more efficient, but maya eats NURBS for breakfast…you’d need an incredibly huge ribbon before doubling the V CVs would make any difference in evaluation time.

Just because someone wrote it in a book, doesn’t mean it’s right!

I tried your code and tried plugging the .tv into the normalConstraint’s worldUpVector. I think I’m fuzzy on what you’re trying to accomplish.

From what I can see with your code, the reader object is behaving exactly as expected. Now, in your example I do get some perceived shearing when I set reader.posU to 0.84. Maybe that’s what you’re talking about?

The first problem I see here is that your V degree should be 1. It was either in the original Art of Rigging or the Farenheit DVDs, but for a ribbon to work well you need to keep the number of points down to a minimum. Here’s an example modified from your code. Scrub through the animation; you’ll see that the Z axis always aims out properly. Again there’s a bit of perceived shearing in extreme circumstances, but in my experience that shearing never adversely effects a rig using ribbons.

If that’s not what you mean, then I’m a little lost here. :)

file -new -force;

currentTime 24;
setAttr reader.posU 1;
setKeyframe "reader.posU";

//begin mel

{
//new file
file -f -new;

//make a simple d3 nurbs surface
string $plane[] = `nurbsPlane -ch on -o on -po 0 -ax 0 1 0 -w 5 -lr .1` ;

//deform the surface at each CV along V
select -r nurbsPlane1.cv[0][0:3] ;
CreateCluster;

select -r nurbsPlane1.cv[1][0:3] ;
CreateCluster;

select -r nurbsPlane1.cv[2][0:3] ;
CreateCluster;

select -r nurbsPlane1.cv[3][0:3] ;
CreateCluster;

//make a hierarchy of the clusters
parent cluster2Handle cluster1Handle;

parent cluster3Handle cluster4Handle;

//make and connect a pointOnSurtfaceInfo node
string $posi = `createNode pointOnSurfaceInfo`;
connectAttr ($plane[0] + “.worldSpace[0]“) ($posi + “.inputSurface”);

//add a reader group and give it attr for controlling the read point of the posi node,
//make the local axis visible and make it grabbable
string $readr = `group -em -n “reader”`;

addAttr -ln “posU” -dv .5 -at double $readr;
setAttr -e-keyable true ($readr + “.posU”);

addAttr -ln “posV” -dv .5 -at double $readr;
setAttr -e-keyable true ($readr + “.posV”);

setAttr ($readr + “.displayHandle”) 1;
setAttr ($readr +”.displayLocalAxis”) 1;

//make the aim constraint for conversion of the output vectors of the posi node to euler rotations
string $aim = `createNode aimConstraint`;

//drive the reader’s translation
connectAttr ($posi + “.position”) ($readr + “.t”) ;

//hook up the UV driver attrs to the posi node
connectAttr ($readr + “.posU” ) ($posi + “.parameterU” );
connectAttr ($readr + “.posV” ) ($posi + “.parameterV” );

//connect aim constrain as specified
connectAttr ($posi + “.tangentU”) ($aim + “.target[0].targetTranslate”) ;
connectAttr ($posi + “.tangentV”) ($aim + “.worldUpVector”) ;
connectAttr ($aim + “.constraintRotate” ) ($readr + “.r” );

//set some keys

setKeyframe -breakdown 0 |cluster4Handle.rotate;
currentTime 24 ;

setAttr cluster4Handle.ry 70;
setKeyframe -breakdown 0 |cluster4Handle.rotate;

//playback the scene. the z rotation does not work in a useful way, although the
//x axis is pinned to the U isoparm. The rotation does not “follow” the V isoparm of the surface

//one way this can be remedied by using a normal constraint (from the surface to the reader)
//instead of an aim constraint, and feeding the .tangentV of the posi node into the
//.worldUpVector of the normal constraint

//This could have been setup so that we “follow” the U parameter instead of the V,
//by altering the clusters and the length/ratio of the surface, however, what we are seeing
//is a shearing of the U and V parameter vectors in relation to each other. There will never
//be shearing between U (or V) and the surface normal: that will always be 90 degrees, so
//it’s probably a superior method of reading the vectors produced by the surface and posi node.

}

p.s. YAY! :)

The steps are:
1) Create a locator, the nurbs surface you want to use, and an aimConstraint (createNode “aimConstraint”)
2) On the nurbs surface, create a pointOnSurfaceInfo node (pointOnSurface -ch on)
3) Connect the pointOnSurfaceInfo node’s .position plug into the locator’s .translate.
4) Connect the pointOnSurfaceInfo node’s .tangentU plug into the aimConstraint’s .target[0].targetTranslate.
5) Connect the pointOnSurfaceInfo node’s .tangentV plug into the aimConstraint’s .worldUpVector.
6) Connect the aimConstraint’s .constraintRotate plug into the locator’s .rotate.

That’s it. I think. I’m doing this off the top of my head at the moment after a long day. ;)