Maya Aim Matrix vs Aim constraint..what's missing?

Hey there, i wanted to re-create this super simple rig which i had made using a regular AIM constraint, but using the new AIM matrix node in maya.
I am having some weird issues , when the matrix rig, top group gets rotated at an angle, the Aiming object starts to go balistic and rotates in all sorts of wrong ways.
I provide a simple scene with the two rigs (there is animation onto it, so you can see what im talking about).
I am fairly sure i am messing up something…but i can’t quite figure out what it is.

How can i achieve the exact same behaviour of the Aim constraint, onto the Aim Node rig ? (i would like to keep the exact same hierarchies, unless is impossible and needs to be adjusted a different way)

Also, what do you guys think of this new node? I am not sure is any faster then the old constraint (nor any less nodes tbh…)

Maya scene :
https://file.io/oEb3FKG7j0ap

1 Like

You’re doing some things that would be smart for a more complicated setup, but you should try to just get it working first with simpler connections.
So first, don’t worry about doing this in local space. Just plug the world matrices of your nodes into the aimMatrix.
Second, you’re missing a connection. You have to have a matrix that tells the aimMatrix node where you’re aiming from, and that’s the .inputMatrix plug. Basically, with this setup you’ve gotta have an extra transform above the node that you want aimed.

A good simple setup would be:

from maya import cmds
aimTar = cmds.spaceLocator(name='AimTarget')[0]
upTar = cmds.spaceLocator(name='UpTarget')[0]
pos = cmds.spaceLocator(name='Position')[0]
output = cmds.spaceLocator(name='AimedNode')[0]
aimMat = cmds.createNode('aimMatrix')

cmds.setAttr(aimMat + '.secondaryMode', 1)
cmds.connectAttr(pos+ '.worldMatrix[0]', aimMat + '.inputMatrix')
cmds.connectAttr(aimTar + '.worldMatrix[0]', aimMat + '.primaryTargetMatrix')
cmds.connectAttr(upTar + '.worldMatrix[0]', aimMat + '.secondaryTargetMatrix')
cmds.connectAttr(aimMat + '.outputMatrix', output + '.offsetParentMatrix')

Try starting from that and making it more complicated from there.


And since you asked, I absolutely LOVE all these new low-level toys that maya has been getting recently. Maya has needed this low level stuff forever. IMO In the past, so many of maya’s yearly improvements are either trying to lower startup friction or impress investors. But they’ve done precious little to make things easier for more knowledgeable technical users until recently.

With these matrix nodes I don’t have to continually compose/decompose matrices all over the place to do the cool stuff. And, especially for more complicated setups, I don’t have to have extra nodes/constraints all over the place. I can usually get away with a multiply or three, and a connection to the .opm.

6 Likes

Yay!
@tfox_TD , thanks for the quick response!
I was definitely missing something here, the Position locator did the trick!:slight_smile:
I had to also re-organize my hierarchy given the double transform on the joints, but not a big deal.

My question was more in specific about this AIM matrix constraint (i couldn’t find much info on how to make it work properly ), i definitely am VERY appreciative of the new matrix nodes and offset parent matrix connection being available! :slight_smile:
I wonder, have you tried comparing a rig using constraints, and the same rig using matrices?
wonder if there is a speed improvement , for sure the connections needed are going to be less.

I ended up with this solution, and does behaves as i would expect, with just 1 node(and fewer connections).

I honestly haven’t done a direct comparison of nodes vs. constraints. I haven’t noticed any day-to-day difference, but I just kind of assumed matrix nodes were faster because there’s less going on in them, and I don’t have to decompose the matrices (decomposing rotation has to use trig functions, which are slow compared to mults or adds). It’s certainly worth testing though.

That said, the fact that I can build whatever behavior I want without having to repurpose nodes to do things they weren’t meant for (looking at you, follicle) is such a big deal to me, that I honestly don’t care so much about the speed of the matrix nodes, so long as it’s at least comparable to constraints.

2 Likes

Can I just say, mostly being a lurker here, your posts are always so incredibly informative. Thank you @tfox_TD

4 Likes

I agree, cutting down the building complexity is definitely worth it!
and i am with you @WeatherMan , this forum in general is full of little gems, is the first place that comes to mind when i need help and industry advice, hoping for an answers by some very smart individuals like @tfox_TD .

3 Likes