Recently, I’ve been trying to find a solution to make the good old “Sticky Controls” method work with GPU Override, since it’s pretty slow. Whether I use a uvPin node, Rivet, or vertexConstraint node, the setup pulls the entire deformation chain off the GPU. When I check the Evaluation Toolkit to diagnose the issue, I get a “Mesh In Cycle” error on my character’s body mesh (where all the deformations happen).
But as soon as I remove any sticky-control behavior, everything goes back onto the GPU again: GPU Override: Enabled (78k) {70/70}.
This lines up with a post I found on Google Groups. At the end of the discussion, Angelo Sta. Catalina said:
“You can’t attach anything to a vertex without losing GPU parallel functionality. Maya sends calculation data to display the geometry to the GPU. The GPU then sends it to your monitor. When you attach anything to a piece of geo, it has to be calculated on the CPU. When this happens, Maya automatically disables GPU functionality.”
So now I’m wondering: What do you all do?
Do you still use sticky controls, or have you dropped the method entirely?
instead of using a uvpin for attaching controls i query the skin information of the vertex;
position and driving joints and their normalized weight values.
with this information in default pose i create a transform that uses either a parentconstraint or a weightAddMatrix with the same joint information and skinclusterweight to drive the transform
then add a control and joint and make it manipulate the skin on that position or add extra elements such as buttons, bags, etc.
this will prevent a cycle and generate a setup similar to a uvpin.
I wonder if that’s worth a plugin?
It would take the same-ish inputs as a skincluster, plus an array of arrays of joint/weight pairs, and outputs an array of matrices.
Once that’s written, a script that takes a bunch of uv pins and outputs that setup would be really straightforward. Oooh. You could even write a second node that takes uv inputs and outputs data usable by the first node. Then it’d be easy to setup a “pinhead”, and get the closest UV on a non-deforming head to the positions of a bunch of inputs and drive the connections of the pins interactively. Then you’d just delete the pinhead and translation node at export time, and everything would continue to work exactly as before. No fragile post-processing needed.
I feel like that would be better than making a bunch of matrix/constraint nodes. It would be fewer nodes with more re-use of data under the hood. And you wouldn’t have as much node IO overhead. Plus you could probably parallelize it nicely.
But, of course, that’s a big project and the time tradeoffs will be specific to your situation.
I may have to add this one to my to-do list. I kinda like the idea. Now, will I ever get to it?
