But as an example it’s easier to read without namespacing. Yeah, that’s my real excuse. ðŸ˜‰

]]>I understand a little bit about matrix math, but after carefully following your instructions to create the 4×4 matrix, I don’t understand how to use that matrix to get the Euler rotations that the constrained object needs to assume in order to aim at the target.

Could you help me understand?

Thanks so much,

Kirk

Launchy isn’t bad. I tried it on my machine at work when I first had to make the move to Vista. Thing is, it’s not Quicksilver, either, and IIRC there was some odd feature it had that got in the way of something else I needed more.

I’m typing this on my third new MBP (the second one that I got this morning I brought home only to find out that it had dead pixels!), and things are looking up, finally, so I don’t have to give up on Quicksilver just yet. ðŸ™‚

]]>Ahh sorry– for some odd reason it converted my quotes?

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.

]]>