Custom maya matrix node constraint *UPDATED* rig tip

[@maccollo]

Watching these videos in persuit of the ultra clean hypergraph/outliner setup

[@iceescape]

This is some really useful stuff and it’s presented in such a clear and interesting way. Am a fan!

[@JarredLove]

I'm so glad to hear that! Thank you so much for taking the time to watch and comment! I'm glad you found it useful.

[@craigdpenn]

Thanks, Jarred. I've been doing a lot of work with vectors and Matrices in Maya recently. Getting away from my old style of using locators and constraints in the outliner and now just calculating stuff under the hood. The offsetParentMatrix is amazing and thanks for enlightening me about the pickMatrix. Your explanation on how to think about multiplying matrices with the multMatrix is really helpful. Almost possible to not decompose anything anymore!

[@JarredLove]

Awesome! Glad I was able to help! Working on vectors and matrices opens up a whole new world when it comes to rigging. Good luck and thanks for taking the time to watch and comment!

[@Nowayasaway29]

Good to see you again!! the geek in me would like to use matrix constraints instead of the classic ones, but i can't wrap my head around them, they always give me unpredictible results... plus they are a nightmare to script(or maybe i'm not good enough at scripting :-D), so i stick with the original constraints node ...

[@JarredLove]

Thanks! What seems to be happening as far as the unpredictability aspect you mentioned? Connection order is important in the mult matrix node, so that might be part of it... There could also be what appears to be some funky stuff going on if you're doing some non-uniform scaling, that might just require a little more tweaking... As for scripting it, maybe you could provide some sample code you're using, and I can help you out.

[@Nowayasaway29]

@@JarredLove thank you that's very kind of you, yes maybe i was not really carefull with the connection order, i need to redo some tests .As for the scripting side, i watched this video some time ago kzbin.info/www/bejne/q6OWeZmglrNreKM, the goal was to have controls without offset groups above them , at "5:21" he copies the values from the transforms attributes to the offset parent matrix transforms to have clean values on the control, when i tried to automate that step, i was not able to set the offset parent matrix transforms values via the setAttr command, i'm not sure if it's a bug , or if i did something wrong...

[@Nowayasaway29]

never mind, just rewatched that video now, i don't think it's a good idea , he' s zeroing out the joint orient in the process... better keep the offset group in that case..

[@JarredLove]

@Amine Kefi My guess on setting that offsetParentMatrix attr is that the attr is actually a 'matrix' type attr which won't allow you to set translate/rotate/scale values. When they added the display option for seeing matrix attrs as the actual matrix values or as the composition (translate/rotate/scale/shear) values and edit either to manipulate the matrix, I don't know if they added some sort of command to set the composition one via mel/python commands. To get around that, you could create a temporary 'composeMatrix' node where you plug in those translate/rotate/scale values, and then you can connect the output from the compose matrix into the offsetParentMatrix of the node you're trying to move. You can sever the connection once it's made, and the data will be retained, so it doesn't need to keep a live connection. If you're looping through nodes, you can create the composeMatrix once, then connect to each set of items in the loop, and then disconnect/delete after the loop - it will be a little faster since you're not creating and deleting the node on each loop iteration (alternatively, you could also just use the gettAttr and setAttr commands instead of connecting/disconnecting). You could still use this for the controls hierarchy, and then do constraints for the joints, or use an altered matrix constraint node network that takes the jointOrient into account.

[@Nowayasaway29]

@@JarredLove thank you for composeMatrix tip !! i'll try to mess around with all that in the coming days, i still think it's better to keep the offset grp though, it's too much of a headache to make the altered matrix constraint for the joint orient (your video on that subject was great though) great content as usual !

[@JBG-dj5iz]

Yep, blendMatrix reproduces the constraints blending. If you want to have 0.5, 0.5, you can use a wtAddMatrix and set the corresponding weight. The interesting thing et the check box to enable or disable the matrix channel.

[@JarredLove]

yes, the wtAddMatrix node is also pretty awesome - I used that for blending a lot before the new nodes came out (still do sometimes)... There's always something I forget to mention in a video! Thanks for watching and commenting!

[@eliranmagen7008]

another amazing tutorial :) thank you, extremely helpful!

[@JarredLove]

Thanks for watching and commenting! I'm glad you found it helpful

[@BorisKlimov]

Very, very useful! Thanks a lot!

[@JarredLove]

Thanks for taking the time to watch and comment! Glad you found the video useful!

[@BorisKlimov]

@@JarredLove Ive already implemented some your tricks. This is wonderful. Now its time to write script for automate the process of constraining using matrices. Especially blending between couples of objects.

[@JarredLove]

@@BorisKlimov that sounds great!

[@justarandomguy5731]

thanks a lot you seems an expert rigger , i just wondering did learn all this stuff alone beccause i m having hard time finding tutorials or infos about using matrices for rigging i mean most of tutorials and courses about rigging are only begginer or intermediate level

[@JarredLove]

Thanks for taking the time to watch and comment! Most of what I understand about using these matrix nodes, I learned through experimentation - at least after the initial hurdle of learning and understanding what the heck they even are. Some of it came from watching/reading various other tutorials that maybe used them a little and then figuring out how to extract and use/combine those concepts for whatever purpose I'm working on a solution for. You're right, the majority of rigging tutorials and courses out there are for beginner/intermediate level... so that's partly why I made these videos.

[@justarandomguy5731]

@@JarredLove yep rigging is tough .Thanks again and keep up the good content i learned a lot from your tutorials

[@shasheekaushalya4253]

Miss you man, Where are you!!

[@joachimhenrard5027]

Hello, thanks for those awesome explanations. In the case you want your child to be affected by the translation AND rotation of the parent while keeping its initial orientation, how would you do that? Thanks in advance.

[@JarredLove]

I'm not sure I quite follow what you are asking... Are you asking how to put an offset in? If so, that's covered in the last part of the video. If that's not what you are asking, please provide a few more details and I'll see if I can help

[@Yotunhe1m]

Hi Jarred. Thanks a lot for all these useful vids! I have a question about the "old" matrix constraint setup. If the driven node has a non-default rotate order (non-"xyz") then there is a mismatch between the driver and the driven result rotations. The problem persists regardless of the driver rotation order, even if the rotation order of all nodes in the setup is the same (non-"xyz"). Can't figure out why this problem might be occurring. I would be grateful for any hints that might help.

[@JarredLove]

Thanks for taking the time to watch and comment - I'm glad you are finding them useful. The matrix math will be correct regardless of the rotate order on the driver/driven items, so at least you don't have to worry about that. I'm not in front of my computer, so I can't check to verify, but I think the decomposeMatrix node has a rotate order attribute on it that you can use to spit the rotates out to suit your needs. Hopefully it's working, I remember a time when the attribute was there but didn't actually change the output rotate values at all... But that was almost 20 years ago, and I don't specifically remember testing it since then... Usually, I would leave whatever is being driven with the default xyz rotate order, and just change it on my driver node/control - but that may just be a holdover workaround I started doing because of that issue. Hope that helps!

[@Yotunhe1m]

@@JarredLove Oh, I didn't check if the decompose matrix has that attribute. Everything seems to be working properly now. Thanks for your help!

[@vladafanasjev9808]

Thank you for the tutorial. I have a question regarding if you want a point constraint behavior with a matrix. If you have two objects with an offset from each other, using the method demonstrated in the video still results in rotation. Essentially, the method provided functions similarly to a parent constraint in Maya. Even when the rotation is broken, it still follows the rotation of the parent object. How can I implement a point constraint behavior with a matrix in this scenario?

[@JarredLove]

Hello - could you please clarify your setup a little bit? Are you plugging into the offsetParentMatrix attribute on the dirven node, or using a decomposeMatrix node? If you're connecing into the offsetParentMatrix, are you utilizing a node like the pickMatrix to extract only the translate data? If you plug it all in fully without a pickMatrix excluding parts of the matrix, it will behave like a combination of a parent and a scale constraint combined - or I guess more accurately, as if it is actually parented under the driver node - so maybe that's what your seeing/describing? Hopefully that will help you get to your solution, but if not, a little more info could help determine some suggestions for your issue.

[@vladafanasjev9808]

​@@JarredLove Hey, thanks for the reply. Basically, I'm attempting to achieve the functionality of Maya's "Point Constraint" using matrices. Let me break it down: I have two locators with entirely different values and hierarchies. If I follow the method shown in the video - locator > multMatrix > decomposeMatrix > locator - the child locator still rotates with the parent locator, even if I only connect the translation. It's similar to using Maya's "Parent Constraint" without using rotation. However, what I want is the "Point Constraint" behavior, where the child only changes position if the parent's position changes, without any calculation of rotation of parnet. I've tried using - locator > pickMatrix > multMatrix > decomposeMatrix > locator - but then I struggle to calculate the offset properly.

[@JarredLove]

Hello - sorry it took so long to reply again (holiday time and such)... Ok I think I know what you're talking about, the driven node doesn't actually rotate but follows along in its offset position within the rotated space of the driver node, correct? If so, that does make sense since the full world space matrix from the driver node is being used to drive the other node and that would include that matrix's rotational data - and since the translation technically happens after the rotation in maya's calculation order, it's applying the offset within that rotated space and not world space the way a point constraint would. So, to 'fix' it you could very easily insert a 'pickMatrix' node between the driver's 'woldMatrix' attr and where it connects to the 'multMatrix' node - then disable everything on the pickMatrix except for the translates. This way, the driver matrix information feeding in is only the translation data and it will ignore any rotations to make it behave more like the point constraint. If you don't have access to that node (pre-Maya 2020) or you don't want to add that extra node into the math, you could also adjust it a little differently by constraining a node without an offset to the driver, and then put the offset into the actual driven node you care about its position for. To clarify a little differently... set up a matrix constraint system without any offset built into the multMatrix calculations, that node should be a parent/buffer node of the driven locator, and the locator can handle the appropriate offset by moving it into its previous world space position (or you could use another buffer node between the locator and its matrix constrained parent if you need clean values). A node connected only through translates without any offset will still technically be taking the orientation data into the multMatrix calculation; however, that node will stay right on top of the driver node without any rotations since there is no offset to 'throw it off' and make it 'orbit' around the driver node. Hope that helps!

[@notusingmyname4791]

this still has that maya flip at 180 and -180, is there a way to get around that? orientConstraining one object to another kinda doesn't do that too often, however if objA is constraint to objB which is a child of objC, rotating objC past the 180 point will cause the flip on objA at 180 and -180 still. I thought one benefit to doing this would be that we don't get that 180 flip but .. I was wrong, got anything for that?

[@JarredLove]

Thanks for watching and commenting! yeah.... that 'maya flip' is not easily handled even with maya's constraints and the main culprit is just due to how the math works out. Essentially maya deals with everything by using matrices under the hood and converts it into and out of euler angles for the xyz rotation values. For example, if you rotate a node 360 degrees in one axis and look at the matrix values for 0 degrees and 360 degrees, they're exactly the same. So, what actually causes the 180 flip is that maya looking strictly at a matrix doesn't know which direction the resulting euler rotation value is rotated and therefore uses the 180 delineation line to determine positive or negative rotation... So, for example a positive rotation value of 90 could also describe a negative rotation value of 270. As you continue rotating, and pass 180 degrees, Maya doesn't know if that's 181 degrees, or -179 degrees... so it chooses the value based on which one is closer to zero (essentially causing the flip). This is technically the 'safest' choice even though it is extremely annoying that it doesn't just inherently know based on the rotation values of the driver node. I have not seen a way to TRULY get rid of this issue with native maya nodes - there will still be a flip some way, somehow, somewhere... unless you're talking about an fk rotation value - you can rotate that node into infinity and it will never flip (something constrained to it will though). I have seen some people write their own custom nodes that keep track of previous rotation values as it goes to know what 'direction' around the rotation axis you're going, but they will usually have it 'flip' at 360 rather than 180 (I think it's more like re-setting to zero, though). Sometimes an orient constraint will seem to flip less depending on which evaluation method you choose (shortest, longest, average, etc), but even that isn't always guaranteed. Another thing I've seen involved some orient constraints and multiplying an output value by 2 to get a 360 flip instead of a 180 flip... but it's basically just tricking maya out in a way (I'm sorry, I don't quite remember all the details of it). You could probably use matrix nodes instead of the orient constraint in a setup like that as well... I suppose you could also look into quaternion math as well... There are some quaternion math nodes in maya, but I wish that they would actually open up the quaternions on transform nodes to be able to plug into them or use that data some way rather than only the euler angles... For practical application to your animators though, usually the 180 flip isn't much of a problem for the majority of 'normal' animations like walk cycles and such... it's only the more extreme posing that it tends to rear it's ugly head... most animators are aware of the 180 flip and know how to work within those limitations such as choosing a good starting position/orientation of the character master control that won't flip the character back and forth nearly as much; however, I also like to put things into a rig that allow the animator to switch/blend to a manual twist control, or just rotate a control on top of the automated twist system to help 'fix' the flipping if/when it happens.

[@ristcheng5585]

That's awesome, thanks a lot, But I have another question "what is different between xform matrix and matrix" ?

[@JarredLove]

That is an excellent question! To be honest though, I'm not entirely sure - I've not done enough extensive testing to determine if they ever have different values than each other, and then what those values actually boil down to... But, it's possible that matrix is just the local matrix under the current parent space, while xform matrix is the actual matrix created specifically from the transform values in the channel box (translate, rotate, scale). It is possible to have the same resulting matrix from multiple different transform values - rotate something 360 degrees and it's essentially back where it started - so that may have something to do with the differences... but I'm really not sure... Sorry that wasn't more helpful

[@12345678980115]

thanks for your tip , if possible make a tutorial on a rolling dice cube rig

[@JarredLove]

I'm glad you liked the video - thanks for watching and commenting. A rolling dice/cube rig? It sounds simple, but would actually end up being pretty complicated if you want it to be fully 'automated' rolling due to the nature of how a cube would roll and bounce random directions. You might want to start with something to measure the distance from the center of the cube to the point on the cube that's closest to the ground (or your main mover control that would be placed on the 'ground') and then adjust the vertical position of the cube based on that. You could then rotate the cube, and it would move it up/down to keep that lowest point in contact with the ground.

[@jianqiaowu8737]

Thank you so much for the video! I just try it on my computer and it works! As a beginner of maya I wander if we don't put the child in the group and want to switch the parent, then how can we do?

[@JarredLove]

Thanks for watching and commenting! I'm glad you liked the video and found it useful. To switch the parent of the constrained node, all you need to do is parent it to your new node, and then plug the inverseWorldMatrix of that new parent node into the appropriate attribute on the multMatrix node. good luck!

[@jianqiaowu8737]

@@JarredLove Thank you so much for answering! I did this but when I change de parent, the child can't stay at the same place. I thought it's related to child's world matrix, since the child local matrix and the child parent matrix change , the child world matrix change. If you have any idea of it, I'll be so glad to hear it!! Thanks a lot:)

[@JarredLove]

hmm... The driven node should stay where the driver node is when you switch a parent and hook that new parent up into the multMatrix node... Remember that the order of connection into the multMatrix is extremely important - if you do it in an incorrect order, then the driven node won't stay with the driver node. Now, if you're doing a constraint with offset setup, you need to calculate the new resulting offset in relation to the new parent node and factor that into the multMatrix. Try creating another setup entirely - duplicate the driven node and parent node, parent appropriately, and then try and make a new multMatrix node and connect that up to drive the duplicates and see if it works as you expect on that. If it does, compare it to your original and see if they're connected in the same order. hope that helps!

[@israel_ns]

Why we need to connect "group1" to multMatrix in [1]? Without it looks like the same behaviour.

[@JarredLove]

Thanks for watching and commenting! That's a great question, and I probably should have explained it better in the video - sorry about that! The video has an extremely paired down and simplified example to more easily explain the concept without additional distractions. So, in this case, the driven node will move with the driver and appear to be working the same with or without that connection. If you were to move the group node, the driven node would not stay synced with the driver without that connection, but would move with the group node instead. The constraint system needs to be aware of the driven node's parent matrix data so it can effectively remove it and ensure the driven node will stay in sync with the driver regardless of where the driven node's parent is in world space. Hope that helps!

[@MartenZander]

that's awesome! However, when you say "the order is important' at 19:12 ... I can't confirm that. I tried several orders and they all result in the correct offsetparentMatrix.

[@JarredLove]

Hey Marten - thanks for taking the time to watch, test, and comment! I'm glad you liked the video. It's interesting to me that you tried setting it up in multiple different orders with the same results, as I've never had that happen in practical application... It's possible all of the nodes you tested with were at the origin providing the same resulting matrix values...typically the nodes will be moved/rotated into 'random' spots, and will likely be parented into a hierarchy where each parent node was also moved/rotated in some way. With everything at the origin certain matrix attributes will even have the same values within the node such as the 'worldMatrix' and the 'matrix' attrs and connecting with them will produce the exact same results in a test, that will not work the same when parented into a hierarchy due to the differences in what matrix values each actually represent (in this example the worldMatrix is the matrix data in world space, while the matrix attr is the matrix data of the node in the local space of it's parent). I probably didn't mention that in the video - so sorry about that! Hope that helps!

[@MartenZander]

hey @@JarredLove, thanks for pointing that out. I assume that might be the reason for it. At least it is the only logical explanation I can think of right now. I will do further testing and see if I ever encounter issues when simply ignoring the order. Right now I am basically using this method to drive simple FK Control nodes, as well as their related system joints. I do not parent FK Controls to each other the traditional so they make up a hierarchy. This is super beneficial if you want to be able to hide FK Controls individually and not hide their children at the same time. Also much less visual overhead in the outliner, which is great! Thanks for taking your time and showing this method. Brings my rigging skills in Maya to a whole new level

[@JarredLove]

no problem! That sounds like an awesome use for this technique! Keep up the good work!

[@mishominas]

How make bipolar pivot it will be animatable

[@gherat]

This is not easy to set up, I got stuff rotating and flying around all over the place, its been really frustrating sp far :( This example is all done at the root but as soon as its in a hierarchy things start moving really unpredictable.

[@JarredLove]

Sorry to get back to you so long after you posted - I've been extremely busy... I'm sorry to hear you're having difficulty, so hopefully I can help. One thing to double check and be sure of is that you're making connections into the multMatrix node in the correct order ortherwise things will start moving around unpredictably. So, be sure that the worldMatrix of the driver node goes into the first index of the matrixIn attribute on the multMatrix node, then use the inverseWorldMatrix of the driven node's parent as the next matrixIn item. Also, if you're making it at the origin and then moving/parenting it into a hierarchy, some connections may need to be changed/updated to account for the change in parent nodes (but that will depend on how you set it up and what you parent where...) I hope that helps!

[@gherat]

@@JarredLove Thanks for your tips! I’ll give it another try! 🙌

[@shinobirigger6487]

1:30 🤣🤣 why MAYA!

[@JarredLove]

hahaha, yeah... it's funny - that particular connection back into itself is so you can have those nice little blend weight attributes in the channel box that are easier for animators to locate and adjust... they plug into the actual weight plug of the indexed constraint driver info.... but yeah.......