Hi
Is there any way to write a node that travels on surface(as if its live ) independent of the uvs …Some ideas or references would be great help
Something like this ?It is using Soup ray cast node i think : https://vimeo.com/70268137
HI
Thanks for the reply AbsurdityDW . Not exactly like this …i wanna use that node for facial rigging …basically wanna make a curve travel on a surface …But i want it not to be based on the uv imformaion… as if we made the object live …this is the kind of output that im looking for
Facial rigging: a parametric experiment | circe-characterWorks …
geometry constraint would allow you to let something travel over a surface without uvs, but is very unstable
follicle with closest point on surface/ mesh node would need uvs but is a bit more stable
Anything that is not UV dependent will be history dependent instead: the same settings applied in a different starting position will produce different results. Of course you can always create a dedicated UV channel that is customized for stability in the use you intend…
Not entirely sure what you’re trying to build, but using nurbsSurfaces as a guide geometry works really nicely here.
I’ve done a somewhat drag/drop face setup recently where all I would do is align one or more nurbsSurfaces roughly along the facial geometry.
The animator could just drag over the surface and it would reposition (and feel smooth/fluent).
In the background it moves by changes in pointAtUV on a surface node, but the animator doesn’t notice that.
It even has an attribute to change the sensitivity! That is NOT a multiplier of the UV value, but the sensitivity of the user interaction.
So the sensitivity could be changed at any time, but 0.5 on the control is still at the same position.
Nice thing is also that you don’t get the issues with geometryConstraints like inaccuracies. (For example if you would type an exact coordinate (XYZ) in the channel box that would match an point on th surface it still wouldn’t snap to it directly. Setting the same value again in the channelBox would again give a new value, until the inaccuracy becomes to small too notice.)