Spine setup problems with locators on nurbs surface

Hi. I’m working on a pretty basic spine setup, fk with a nurbs surface that should have a bunch of locators.

I really want to move away from follicles and go with Maya’s new matrix UV Pin. So far so good. However, when stretching the nurbs surface, my locators are not at the intended position along the 0 to 1 range which makes setting up a stretch slider attribute unreliable. I figure this is due to the nurbs surface being skinned and deformed that makes the locators not positioned evenly because they are controlled by the UV coordinates and not a specific 0 to 1 range. It should be the same for follicles though? And I’m not quite sure how to solve that.

I created a curve from an isoparm on the surface and connected the locators to the curve using a motion path instead, broke the U value connection and distributed them evenly. Now the locators are staying on the spot when the surface is being deformed. However, the locators are obviously not oriented correctly. I thought I might create another locator for each of the original locators, just a tiny amount from the original and aim constraint it at that. this should solve the orientation, but a setup like that sounds quite ugly and seems prone to flipping. What are your thoughts?

If I’m understanding correctly, you’re getting UV parameterization, but you want normalized length parameterization. I think that means you need to reparametrize before you pin.

I think you can do that with a rebuild surface node, but I haven’t messed with it in a long time so you may have to do it in a different way (like maybe skin some curves, rebuild the curves, and then loft the rebuild), or there may be better/faster ways in base maya.

1 Like

Hey and thank you for such a swift reply.
Rebuilding the surface didn’t help, or I’m missing something. I think that’s the nature of NURBS surfaces. And I really need control over the distances. Maybe I should look into spline IK again, but that caused another irritating issue with a “jumping” end joint which I someway alleviated, by a multiple of distance nodes…
But first I’m going to try doing it with two curves instead and set up the aim constraints to point at a twin locator on the twin curve. It could actually be the best approach.

Thanks again.

I kind of found a solution. I’m UV pinning the locators to follow the surface. That way I don’t have to think about the normals, then I’m also creating locators attached to a motion path on the curve on the surface. With a closest point on surface node, I feed the curve locator’s position in to get the correspofing U,V values on the surface. It works. seem stable. Just one issue is that the UV pinned locator isn’t folowing the surface down the middle so I might have to fix that by an aim constraint to the curve locator and offset the U value of the UV pin locator slightly.
the polygon arrow is just for a set driven key of the motion path U value. The red thing is the resulting locator for the joint.
Hope it makes sense.

Fair enough. I could have sworn that rebuilding would allow you to do that.
Apparently not. :confused: Oh well

At work we use plugins that are specifically built to parameterize on length. Or we use a custom spline plugin. But it sounds like you want to do this in base maya.

edit: If you decide to use plugins, looks like mGear has the percentageToU and uToPercentage nodes in the mgear_solvers.mll. Those may do what you’re looking for.

1 Like

Maybe I’m confused. It’s been a long day.
But I think I’m on the right path for my needs.
It’s not that I want to do it this way, I just can’t seem to do it another way =)
I wish I had the knowledge to write a plugin to do this and I haven’t dug deep into mrig yet, but that sounds great! I will be sure to look into that.

So with the motionpath is the only way I’ve found that gives me the control I need to make sure 0.2 is at 0.2 of the full length. Then I can lock that length so in the end I will have an attribute to blend on and off the stretch.

I mean rebuilding would work if it was a static mesh. The problem occurs when the NURBS surface is deformed. SInce all CV:s are not moved the same amount all the time, this will change the parametrization. Maybe that’s the wrong word, but the 0-1 range is closely connected to where the points are on the surface. This is not the case for a curve however. No matter how I move the curve CV:s, bundling them up on one end and stretching the last one, 0.5 will always be in the middle.
The percentageToU sounds like it does exactly that. If I put in 50% it should give me a U value that would be at the middle of the surface at all times.

Right. What I failed to mention (sorry) was that the rebuild node would remain in the file, connected after any deformations, but before the pins. My thought was that the rebuild had an option would update the parameterization. And since the node came after the deformation, it would take that into account.

I was incorrect. It does not do that. I could’ve sworn it did. I was wrong.

1 Like

Aha, I see. But so it would have to rebuild constantly?
Thank you.

I mean … yeah. But that’s the point. :slight_smile: (I mean … that WOULD be the point if it worked)

THEORETICALLY: Rebuilding on chord length would have to solve the exact same math as percentageToU. It would then just go through the extra step of storing that data in a nurbs knot vector and forwarding that data out to a new node for you to extract via the uvPin. (At least, that’s how I’d want to write it)

The only real variable is how Maya deals with tessellating and drawing nurbs surfaces. If it always re-tessellates on deformation whether the surface is hidden or not, that’s a performance hit. If it re-tessellates only on the draw call of a dirty surface, then it would be on-par with (but almost certainly a bit slower than) percentageToU so long as you hid the surface.

I see. Thank you.
Yeah for this I’m actually going the long route, not using mgear, but I will definitely try that afterwards.

And I’m being really silly here. A far easier solution which I mentioned in my second reply is to actually have two curves riding on a NURBS surface, one with joints, the other with locators sharing the same U value feed and use the joint’s motionpath ObjectUp attribute to the corresponding locator, to be oriented correctly.

1 Like