That's a tough question to answer because of all the factors involved - the evaluation mode you're using (DG, serial, parallel), scene size/setup, and even the hardware of the computer you're using. Also, if you're just comparing one parent constraint to one matrix node network, the difference will not really be noticeable, it's only after you get several in the scene... which is really not hard to do if you replace all/most in a rig and have multiple rigs in a scene. To give some numbers and a bit of an idea, I created a file of one parent constraint setup and another one with a corresponding matrix 'constraint' setup, then gave them identical animation over about 30 frames (4 keys). I imported each 200 times into their own file so I could compare a large number of each together (identical in every way except the constraint). Then I used the evaluation toolkit to test the fps playback speed. So, I ran each 3 times and took the averages, but listed all the values so you could take the highs and lows to determine a range yourself if you would like. parent constraint: Playback Speeds =============== DG = 220.1047 fps (204.545 | 230.769 | 225) EMS = 50.1096 fps (48.913 | 50.2793 | 51.1364) EMP = 183.7243 fps (187.5 | 180 | 183.673) matrix nodes: Playback Speeds =============== DG = 232.766 fps (214.286 | 243.243 | 240.769) EMS = 68.892 fps (68.1818 | 68.1818 | 70.3125) EMP = 200.202 fps (195.652 | 209.302 | 195.652) With those averages, the DG mode is about 5.75% faster, the EMS (serial) is about 27.26% faster, and the EMP (parallel) is about 8.23% faster. So, the more constraints you convert to matrix nodes, the more improvement in fps you'll see. Granted, this is only testing the difference between the constraint speed and not the space switch speed, but it should give a pretty good idea even then. One thing to note is that it seems the first test for DG mode might have cached the parent constraint or something because it had a really low fps (around 109 I think - reopening the file and testing a few times continued this trend), so I ran it 4 times and took the last 3.
Hey Jared, is this setup essentially deprecated now with the new Offset Parent Matrix node in 2020? I wonder the same as another user who asked the same question, would you do a good to the users who use maya that you update a version using new versions of maya maybe 2020 or newer.
Hello - thanks for taking the time to watch and comment! Is it deprecated? Well... yes and no... I have an updated video on the 'matrix constraint' itself here: ruclips.net/video/7A98wukXsJQ/видео.html That will give you some info on the new stuff to experiment with and hopefully a few ideas of where you might want to use them (I even briefly touched on using multiple drivers). But, there's still a lot of good info in this video about building the matrix needed to drive the driven object that can still come in handy. For instance, you could use the new blendMatrix node and a system to drive the weights of each target matrix to handle the switching, or you could still use the choice node method in this video to feed into a multMatrix. It really may just come down to how you're using it in any given situation and what would make the most sense in that particular situation (but either way, you'll probably want to skip the decomposeMatrix node). In any approach, managing the offsets is one of the major parts to consider as the old and new matrix options can handle them very differently I hope that helps!
@@JarredLove It is a very interesting topic, once again thank you very much for sharing all this material, there is a lot to study in all this from me.
There's a bit of dishonesty about needing the locators for the parentConstraint method on the IK hands... I've added several "spaces" even at different times in my animation with a parentConstraint maintaining offsets, and when you add that new target, nothing jumps or messes up... no locators needed (even for objects not aligned with the object you're constraining). All you need is a script to run when you switch your space, and that's typically done through some sort of extra UI, and that script usually creates a transform at the position your control is at, then switches your control to the desired space, then matches transforms to the created transform object.. and then deletes said transform object... nothing extra is needed to be floating around in your scene all the time. (and to do that with animation, just have the script, set a keyframe at the current time, go back one frame, set a keyframe there, go to the current time, do all that spacing, and set a keyframe, overwriting the first keyframe)
Thanks for taking the time to watch and comment on another video! Well, it wasn't intentionally dishonesty... you can look at the conversation thread in these comments with brod515 (provided the user name doesn't change). They mentioned some confusion and not having that issue with parent constraints, and it's something I was actually not aware of... I then go on to explain that years ago when I first learned methods for creating space switches, that it was what I had to do because there was no such thing as a parent constraint at that time. Once parent constraints were added, I kind of just kept doing it the way I had done it using point and orient constraints. But there are a few other minor benefits of having a node to perform that switch on (I prefer a transform, and only used a locator in the video to help visually show where that node was). Here's an excerpt from that conversation: "So, in using a parent constraint, you actually wouldn't need those locators/transforms and it should still work fine; however, since the stored offsets are somewhat hidden away within the constraint node, it could be a little bit more difficult to diagnose if there's something wonky going on with your switch. Having the transforms there does make it a little easier to select the node for a given 'driver' and see where that pivot is and how it's oriented in space... But, there's really no reason you couldn't create a tool to make temporary locators and use the values in the constraint to give yourself a visual cue when trying to solve that potential issue." Also, this video is just for setting up the mechanism for a space switch within the rig - you would likely still need a tool like you mention to re-position the hand control (or whatever it is) to the same position and orientation in world space because it is definitely going to 'jump' to a different spot when you change spaces - in fact, I even mention that in the video.
@@JarredLoveI didn't intend the "dishonesty" bit as a dig, mind you... and I'm sorry that's how it sounds, it looked like a knowledgible person was skipping something of parentConstraints and comparing that to all of the strengths of this matrix connections. I'm re-reviewing now and see how I could've come across poorly. My apologies. I still run into the same issue when trying to use this method over the parentConstraint method from my other thread though, but I have seen it work ferpectly so I'm doing something wrong. I will add that there is a bonus to the matrix not discussed here, but you can make a cyclical connection without the cycle spam so long as the objects are never set to cycle. ie: objA can have objB as a space, and objB can have objA as a space (so long as they each have a second space to go to), and there's no constant spam about a cycle unless you set them both to be driven by the other at the same time. I think that's awesome as I have props that need to do that (like nunchaku, or a broom in one hand or governing both hands), and you can't have that with constraints without the warning spam.
my one remaining question... if the nodes for "multiplying matrices" are called multMatrix, and you are multiplying matrixes.. why is the output called matrixSum? aren't sum's the result of addition, and products the result of multiplication?
that's a good question, and I honestly don't really know... I thought it was odd myself and kind of just assumed that either the person who wrote the node just had a brain fart when naming the node/attrs, or that's what the actual mathematical terms are for multiplying matrices... but I never really took the time to investigate. I think I remember watching someone's math videos that talked about multiplying matrices one time because I was a little curious how the math is actually done, but that was several years ago and I don't really remember the details at this point... Sorry I couldn't be more helpful on that one...
Hey Nico Corrao - great question! I would say yes... and no.... Yes, in the sense that you do not need the 'decomposeMatrix' nodes anymore since you can just plug into the 'offsetParentMatrix' attribute. Just be aware that there will be a little bit of additional things to consider and implement... if you only want rotations or translations instead of the whole resulting matrix, for example... No, in the sense that the nodes required for creating the appropriate matrix to feed into your driven nodes are largely the same, so the concept itself still stands even if a few of the specific connection details are different. There may also be situations where you do need to decompose a matrix to extract out some of the information if you aren't plugging directly into a transform node's offsetParentMatrix attribute, so being familiar with the decomposeMatrix node could be helpful.... I do plan to do some updated videos using the matrix node additions from maya 2020. I tried them out briefly when they were released and really like the additions a lot; however, there are a few things I need to experiment with to verify how I personally would like to implement them in my own work before making those videos/suggestions. Thanks for taking the time to watch and comment!
I really like this approach as it makes for a clean graph and the parent space transforms are all in one place. I wonder how one might achieve blending between spaces this, though?
Thanks! I'm glad you like it. If I understand your question correctly, you want to know how to blend between them instead of an abrupt switch? If that is correct, start watching this video from around 16.55 where I describe a way you could create a blending setup utilizing a 'wtAddMatrix' node. I hope that helps!
hello jarred thanks for these amazing tutorials, im a begninner in character rigging and eagerly wants to learn about matrix connections instead of direct maya constrains (im slow learner btw which takes time to undertstand ) so please if you have beginner tutorials or anything like simpler terms to understand that would be really helpful ps i love your all videos of matrix constraints im getting alot of information
Thanks for taking the time to watch and comment! I'm glad you're finding my videos useful. Be sure to check out the most recent matrix video where I go over the exciting new matrix stuff added in maya 2020 (well... exciting for rigging nerds like me...) ruclips.net/video/7A98wukXsJQ/видео.html - it should give you an idea of the minor tweaks you'll need to consider in order to utilize them for potentially cleaner setups! As for some more beginner friendly tutorials, I don't have many at the moment but could potentially add some in the future. In general I originally set out to make my videos at a bit more of an intermediate level of rigging since there are a lot of other creators who have covered a lot of the basic stuff pretty well. Still, definitely something I could do in the future!
Hello, I replied to this, but it seems to have disappeared between when I finished typing it and hit reply... so sorry if there's a duplicate that pops up somehow... Yes, the snapping is going to happen - that's unavoidable unless you write some sort of plugin to automatically deal with the popping switches will create... So basically, you'll need to write a helper script to move the control back to where it was before the space was changed. It would go something along these lines: 1) collect world space translation/rotation from the control 2) switch the space 3) apply the world space translation/rotation that you collected before the switch NOTE: your switch should always used stepped keyframes, and your control's keyframes will either need stepped keys for the switch, or 2 keyframes (one on the frame right before the switch, and one on the same frame as the switch). You can collect and set the translate/rotate values with the 'xform' command utilizing the 'worldSpace' flag/kwarg Hope that helps!
Hello, I have a question about a problem I encounter trying to build this on my rig. I have a prop that I'm space switching between the left and right hand and the world. I can get the prop control to follow translation of the desired space, but when I rotate the drivers the driven control has bizarre rotations happening. Do the drivers have to have frozen transforms?
Hey Sean, thanks for taking the time to watch the video and give it a try! I'm sorry you're having difficulties, and it's a little difficult to know what's wrong without being able to see the file... Is it flipping when you switch between spaces? Or do you mean that you rotate your hand control and the prop is rotating a completely different way? In general, I would avoid freezing transformations like the plague. It almost always causes problems when you're trying to debug stuff since the freezing process still stores a bunch of offset information onto the transform making the resulting matrix actually different than what you think it is... It's just an extra headache. Instead, I just use another transform as a buffer node which will be used to 'store' all of the non-zero transform values so that the node I'm interested in will have a clean zero state. I don't know if that is enough to help you fix your problem, but if it's not, a little more info could hopefully help point in the right direction!
@@JarredLove Hey thanks for the response, actually I found that I has used the incorrect parent world inverse matrix. Got it sorted out and wrote a nifty tool to switch. Thanks for sharing this tut!
Hello Jared. I'm trying to reproduce your maintaining offset setup here. There's some way to connect the "offset" multiMatrix´s (the temporary one, used just to get the offset calculation) matrixSum directly on the choice node Input using python instead of creating those matrix attributes just for store the data? I've tried: offset = cmds.getAttr("temp_multMatrix.matrixSum") cmds.setAttr("name_of_the_choiceNode.input[0]", offset) but I get an error: Error: RuntimeError: file line 5: setAttr: Error reading data element number 1: I believe the error is due to the type of both nodes aren't the same or compatible. If I add the flag type="matrix" in the setAttr command I get another error: RuntimeError: file line 5: setAttr: The attribute 'name_of_the_choiceNode.input[0]' does not accept data of type 'matrix'. How would you proceed? There's some problem in just connect these attributes on the node editor, and keep all the temporaries multMatrix or I'll get a cycle?
Hey Bruno - so sorry you've run into this problem. I'm currently on a vacation for 2 weeks, so I'm away from my computer and can't do any explicit testing to make sure I provide a correct answer. Once I get back home, I will look more into it and we can figure something out. In the meantime, could you please give me any other details of what you're trying to do that you think might be helpful (if there is anything else)?
I'm really sorry for bothering you on your vacation, man! Actually, I'm trying to connect the result (the "matrixSum" output) of the temporary multMatrix used to get the offset calculation between the target and the driver via python, instead of using those matrix attributes on some other node to receive this information, you see. But don't worry about this right now, enjoy your vacation and sorry again!
@ Bruno Silva - Ok, well... apparently, I lied about just setting the choice node's input atttrs with matrix data.... I'm terribly sorry to do that to you. I've set the choice node inputs with other data (probably just float values) in the past, and if you want to put matrix data on the matrix math node inputs (like a multMatrix) without keeping a connection, you have to set them manually since they lose their matrix data as soon as you disconnect them... Also, the choice node can accept and pass matrix data along when connected... So with all those conditions/quirks, I guess that I (foolishly) assumed you could set the data on a choice node and it would actually accept it and work just fine. I did several tests - one of which was to connect it to a worldMatrix of some node temporarily to try and 'set' the attr type of the choice node's input to be a matrix type, then disconnect it and set the matrix data... but nothing I tried would work. Sorry to send you down that annoying rabbit hole, but it looks like you will need to pick a node somewhere in your hierarchy and add those offset attributes. The good news is that you can actually set them when you create them to make it work... You will have to do this in order to get the proper offsets because if you keep any temp multMatrix nodes and connect their output to the choice node, you'll get cycle issues - the offset matrix values need to be static. I would suggest doing it on one of the top group nodes in the hierarchy for that body part, or if you have a single node in your hierarchy that you use for various configuration attributes... I tried to add a note to that part of the video, but the ability to do it has been removed by youTube, so I made a note in the video description...
I've really tried here as you did, but at the end of the day, I kept the attributes in the parent group of each limb setup, as you suggest in the video. Despite that, this setup works really well! I'll try to use it as much as I can in my future rigs. Thanks again, Jarred!
Hey MrBrN197, those nodes don't necessarily need to be locators - an empty transform node will do just fine. I just used locators to show you where those nodes existed in space. Their purpose is to give you several nodes to parent constrain your driven item to without having to deal with any kind of offset issues since the offset would be different for each driver (head, hips, master, etc). Maintain offset doesn't really work on constraints with multiple drivers that you are blending between because it can only store one offset (instead of one per driver). So the easiest way to ensure a 'clean' switch is to have transform nodes that match the position and orientation of your driven item, then parent those to each of your 'drivers' and use the nodes to do a constraint without any offsets. hope that helps!
@@JarredLove are you referring to an orient/point or parent constraint. I don't seem to get any issues using a parent constraint with multiple drivers on an object with maintain offset checked. the offset is maintain between both drivers.
Hey MrBrN197 - aha! You got me there - as it turns out, parent constraints do have per-target 'targetOffsetTranslate' and 'targetOffsetRotate' attributes to store those offsets. Back before the parent constraint was added to maya you would typically set up a space switch with a point and orient constraint which only store the single offset so you kinda had to make those extra empty nodes to line up the pivots... After I started using the parent constraint, I just kept doing it that same way! Man, you get used to doing something a certain way and don't always catch when you don't necessarily need to do it anymore! So, in using a parent constraint, you actually wouldn't need those locators/transforms and it should still work fine; however, since the stored offsets are somewhat hidden away within the constraint node, it could be a little bit more difficult to diagnose if there's something wonky going on with your switch. Having the transforms there does make it a little easier to select the node for a given 'driver' and see where that pivot is and how it's oriented in space... But, there's really no reason you couldn't create a tool to make temporary locators and use the values in the constraint to give yourself a visual cue when trying to solve that potential issue. good times!
Hello Oleg - so sorry to reply to you so long after you posted, but I've recently moved and it's been a lot of work trying to get everything done! I still don't have my desktop computer set back up so I can get back to CG work... I'm a little hesitant to put up a file since there may be a point in the future where I would need to take the file back down or it would lose it's hosting or something and someone who finds it after that point wouldn't be able to benefit from it... I've seen several tutorials online where the images or example files are just not there anymore and it pretty much makes that tutorial a dead end for trying to learn from it. But, I will consider it and may look into doing that at some point (maybe keeping files up online is not as big of an issue these days as it used to be...). Was there any particular part of the video that needed further explanation?
awesome info, i always try to use matrix constraints in my rigs, i absolutely love them, but never used them in a space switching setup, very clever method, thak you very much. Any idea on how to setup an aim constraint with matrix nodes? i saw something similar on the cult of rig channel, but it was to complicated for my little brain :-D
Thanks! I'm glad you enjoyed the video! It is possible to set up an aim network, but it requires a lot of extra nodes and is kind of a headache to get it to work correctly (not as clean/simple as the point, orient, parent, and scale networks - which are really all the exact same network but just driving different attrs on the constrained node)... And it may not even evaluate faster due to all the extra connections and un-optimized operations since some nodes can handle so many different types of operations... Here's a blog post talking a bit about the math behind the aim constraint that you might be able to use to build it: sugarandcyanide.com/blog/2009/05/22/vector-is-that-you-its-me-and-im-blank-on-a-witty-finish/ The blog post is geared a bit more toward how you would need to calculate the data in order to write a plugin for an aim constraint replacement node instead of how to create the node network to make the constraint, but it's helpful to extrapolate what types of operations you would need to hook up... If I remember correctly, you would end up with some vectorProduct nodes using the dot product operation to get your rotation axis vectors to be orthogonal and feed those into a fourByFourMatrix node to create the final matrix.... Now, probably the easier thing to do (and what I do) is to go ahead and use maya's aim constraint, but then de-cycle it as much as possible by snipping connections or driving them with something else where appropriate. Here's a video from cult of rig (love that stuff!) on how you can de-cycle constraints: ruclips.net/video/wT4D_I89aQ8/видео.html Fortunately, he's actually using an aim constraint to demonstrate it. You may have already seen this one since you mentioned watching some of his videos, and you don't necessarily have to watch all the explanation parts where he's describing the graph evaluation (although I think it's really helpful insight) - so if that makes your brain want to explode, you can focus more on the parts where he's adjusting the connections. If you want to retain the capability of the constrained node to be moved (whether an animator directly or indirectly causes the constrained node's translate values to change), you will still need to leave the translate connections cyclical; however, if the aim constrained object can be 'split up' with the parent and parentOfTheParent nodes the way he gets to in the latter half of the video, then the cycle can be completely removed. I hope that helps!
thanks a lot for your reply, yes i saw that part, actually i watched all the season 00 , and i was lost at the season 01 :-D i'm really not good at math ! so de-cycling it will be then :-D (though , i remember when i watched rafaelle's video, i tried to replicate what he did, but i was having less framerate than the cyclic one... maybe i did something wrong , or maybe maya was cashing the constraint, i don't know :-) ) , anyway, i absolutely love what you're doing, and i hope to see another video from you soon :-D cheers.
Hmmm, that sound a little odd - perhaps your computer was doing something else that demanded more computation as you were testing the pruned aim constraint...? Were you testing on a very simple scene of only a driver/driven node with the aim constraint between them? It may also be helpful to do a timing test with a few hundred duplicates of a default aim constraint with a little animation on them, then a duplicate file where the constraints are de-cycled and see if it was just a fluke... There's another comment for this video asking how much faster this is than a constraint. You can look at my reply for a little more detail of how to test it. To generate your file, you can create an aim constraint and animate it a little, then save it and do some imports (you can script the import, or just import in stages to a new file - import 5, save that separately, import the new file to have 10, save that separately, import that a few times to keep building the number of constraint setups you have in the scene) to get a file that has 200 or so of them in the scene - then de-cycle your original file, save it and do the same type of import method to get another file matching your first test file, then do the timing tests on each and see how it goes.
Yes, i tried on a very simple setup, i'll do the import method and keep you informed, i'd like to know the result since i use quite a lot of ribbons setup in my rig, they're not really heavy, but i'm trying to make them lighter , thanks for the testing method :-D oh and i also really liked your ik arm setup videos, thanks again.
Just tried on 200 aims, no difference at all, almost same fps, with the cyclic one being faster at times.. weird. (Just tested with parralel evaluation only.)
this isn't a good solution, if you rotate a driven object's parent, the driven object will still obey its parent as if there was no connection, then, with that parent's offsets affecting how the child behaves, if you move your driver object the driven object will be out of sync, so you're not really in the "space" of the driven object. and I dunno about y'all but my animators will even move the top most node to fit the starting point of their scenes so there's NO WAY to ensure these connections will ever work as intended.
Thank you for the comment. That's interesting - I don't seem to have the issue you brought up when I work with it. Whenever I set up a matrix constraint, the driven node no longer follows its actual parent node but instead follows along with the driver. My guess is that you may have made a mistake somewhere in your connections that prevents it from working as intended. Working with matrix nodes can be a little confusing and aggravating at times - especially where multMatrix nodes are concerned because the order of input is critical to get right (otherwise it will give you what appear to be strange results). Something to remember is that there are multiple ways to rig things. Not every method will be the best fit for every situation, so you need to use what's best for your particular needs and requirements. These matrix node constraint systems have the ability to really speed up the rig functionality by streamlining connections and making the data flow as efficiently as possible through the rig. But, something to be aware of is that it does become less and less noticeable as computer processing power increases (and things like parallel evaluation helps as well). Even then, if you need to have 100 or even 50 characters in a scene, the constraints may begin to bog the scene down and these are a tool to help lighten that burden on the system - scene splitting where you have smaller collections of characters and render in passes to composite together at the end is another option as well.
@@JarredLove thanks for the response even though the video was posted in 2019-ish... I'm coming back to this now and trying to find where I went wrong.
you are welcome! If you're still having issues with the matrix system 'flipping out' as you move the driver or the driven node's parent you could try simplifying your setup and just get a single matrix constraint working first before applying it in a 'space switch' situation. Pair it down to a node as a 'control' (like creating a nurbs circle or something), and a 'driven node' with a parent (like a cube with a group node) and get the constraint working with the matrix nodes to drive the cube with the circle. then move the group node around and/or parent it to some other nodes and move them around to see if the constraint is actually working. If it's not, there's probably an issue with your connection order into the multMatrix node. good luck, and I'll try to help out as best as possible
@@JarredLove question... what's the best practice for adding spaces to an object already set up with spaces? should I disconnect the decomposition from the target object, then capture the offset and hook that up to the choice nodes then re-hook up the decomposition to the target object? (I've had it break things for some reason)
How much faster is it compared to maya's constraints?
That's a tough question to answer because of all the factors involved - the evaluation mode you're using (DG, serial, parallel), scene size/setup, and even the hardware of the computer you're using. Also, if you're just comparing one parent constraint to one matrix node network, the difference will not really be noticeable, it's only after you get several in the scene... which is really not hard to do if you replace all/most in a rig and have multiple rigs in a scene.
To give some numbers and a bit of an idea, I created a file of one parent constraint setup and another one with a corresponding matrix 'constraint' setup, then gave them identical animation over about 30 frames (4 keys). I imported each 200 times into their own file so I could compare a large number of each together (identical in every way except the constraint). Then I used the evaluation toolkit to test the fps playback speed. So, I ran each 3 times and took the averages, but listed all the values so you could take the highs and lows to determine a range yourself if you would like.
parent constraint:
Playback Speeds
===============
DG = 220.1047 fps (204.545 | 230.769 | 225)
EMS = 50.1096 fps (48.913 | 50.2793 | 51.1364)
EMP = 183.7243 fps (187.5 | 180 | 183.673)
matrix nodes:
Playback Speeds
===============
DG = 232.766 fps (214.286 | 243.243 | 240.769)
EMS = 68.892 fps (68.1818 | 68.1818 | 70.3125)
EMP = 200.202 fps (195.652 | 209.302 | 195.652)
With those averages, the DG mode is about 5.75% faster, the EMS (serial) is about 27.26% faster, and the EMP (parallel) is about 8.23% faster. So, the more constraints you convert to matrix nodes, the more improvement in fps you'll see. Granted, this is only testing the difference between the constraint speed and not the space switch speed, but it should give a pretty good idea even then.
One thing to note is that it seems the first test for DG mode might have cached the parent constraint or something because it had a really low fps (around 109 I think - reopening the file and testing a few times continued this trend), so I ran it 4 times and took the last 3.
unless you're dealing with a huge scene with tons of objects with spaceswitching involved... not enough to make the transition immediately important.
Hey Jared, is this setup essentially deprecated now with the new Offset Parent Matrix node in 2020?
I wonder the same as another user who asked the same question, would you do a good to the users who use maya that you update a version using new versions of maya maybe 2020 or newer.
Hello - thanks for taking the time to watch and comment!
Is it deprecated? Well... yes and no... I have an updated video on the 'matrix constraint' itself here: ruclips.net/video/7A98wukXsJQ/видео.html
That will give you some info on the new stuff to experiment with and hopefully a few ideas of where you might want to use them (I even briefly touched on using multiple drivers). But, there's still a lot of good info in this video about building the matrix needed to drive the driven object that can still come in handy.
For instance, you could use the new blendMatrix node and a system to drive the weights of each target matrix to handle the switching, or you could still use the choice node method in this video to feed into a multMatrix. It really may just come down to how you're using it in any given situation and what would make the most sense in that particular situation (but either way, you'll probably want to skip the decomposeMatrix node).
In any approach, managing the offsets is one of the major parts to consider as the old and new matrix options can handle them very differently
I hope that helps!
@@JarredLove It is a very interesting topic, once again thank you very much for sharing all this material, there is a lot to study in all this from me.
There's a bit of dishonesty about needing the locators for the parentConstraint method on the IK hands... I've added several "spaces" even at different times in my animation with a parentConstraint maintaining offsets, and when you add that new target, nothing jumps or messes up... no locators needed (even for objects not aligned with the object you're constraining). All you need is a script to run when you switch your space, and that's typically done through some sort of extra UI, and that script usually creates a transform at the position your control is at, then switches your control to the desired space, then matches transforms to the created transform object.. and then deletes said transform object... nothing extra is needed to be floating around in your scene all the time.
(and to do that with animation, just have the script, set a keyframe at the current time, go back one frame, set a keyframe there, go to the current time, do all that spacing, and set a keyframe, overwriting the first keyframe)
Thanks for taking the time to watch and comment on another video!
Well, it wasn't intentionally dishonesty... you can look at the conversation thread in these comments with brod515 (provided the user name doesn't change). They mentioned some confusion and not having that issue with parent constraints, and it's something I was actually not aware of... I then go on to explain that years ago when I first learned methods for creating space switches, that it was what I had to do because there was no such thing as a parent constraint at that time. Once parent constraints were added, I kind of just kept doing it the way I had done it using point and orient constraints. But there are a few other minor benefits of having a node to perform that switch on (I prefer a transform, and only used a locator in the video to help visually show where that node was). Here's an excerpt from that conversation:
"So, in using a parent constraint, you actually wouldn't need those locators/transforms and it should still work fine; however, since the stored offsets are somewhat hidden away within the constraint node, it could be a little bit more difficult to diagnose if there's something wonky going on with your switch. Having the transforms there does make it a little easier to select the node for a given 'driver' and see where that pivot is and how it's oriented in space... But, there's really no reason you couldn't create a tool to make temporary locators and use the values in the constraint to give yourself a visual cue when trying to solve that potential issue."
Also, this video is just for setting up the mechanism for a space switch within the rig - you would likely still need a tool like you mention to re-position the hand control (or whatever it is) to the same position and orientation in world space because it is definitely going to 'jump' to a different spot when you change spaces - in fact, I even mention that in the video.
@@JarredLoveI didn't intend the "dishonesty" bit as a dig, mind you... and I'm sorry that's how it sounds, it looked like a knowledgible person was skipping something of parentConstraints and comparing that to all of the strengths of this matrix connections.
I'm re-reviewing now and see how I could've come across poorly. My apologies.
I still run into the same issue when trying to use this method over the parentConstraint method from my other thread though, but I have seen it work ferpectly so I'm doing something wrong.
I will add that there is a bonus to the matrix not discussed here, but you can make a cyclical connection without the cycle spam so long as the objects are never set to cycle.
ie: objA can have objB as a space, and objB can have objA as a space (so long as they each have a second space to go to), and there's no constant spam about a cycle unless you set them both to be driven by the other at the same time.
I think that's awesome as I have props that need to do that (like nunchaku, or a broom in one hand or governing both hands), and you can't have that with constraints without the warning spam.
my one remaining question... if the nodes for "multiplying matrices" are called multMatrix, and you are multiplying matrixes.. why is the output called matrixSum? aren't sum's the result of addition, and products the result of multiplication?
that's a good question, and I honestly don't really know... I thought it was odd myself and kind of just assumed that either the person who wrote the node just had a brain fart when naming the node/attrs, or that's what the actual mathematical terms are for multiplying matrices... but I never really took the time to investigate. I think I remember watching someone's math videos that talked about multiplying matrices one time because I was a little curious how the math is actually done, but that was several years ago and I don't really remember the details at this point... Sorry I couldn't be more helpful on that one...
Hey Jared, is this setup essentially deprecated now with the new Offset Parent Matrix node in 2020?
Hey Nico Corrao - great question! I would say yes... and no....
Yes, in the sense that you do not need the 'decomposeMatrix' nodes anymore since you can just plug into the 'offsetParentMatrix' attribute. Just be aware that there will be a little bit of additional things to consider and implement... if you only want rotations or translations instead of the whole resulting matrix, for example...
No, in the sense that the nodes required for creating the appropriate matrix to feed into your driven nodes are largely the same, so the concept itself still stands even if a few of the specific connection details are different. There may also be situations where you do need to decompose a matrix to extract out some of the information if you aren't plugging directly into a transform node's offsetParentMatrix attribute, so being familiar with the decomposeMatrix node could be helpful....
I do plan to do some updated videos using the matrix node additions from maya 2020. I tried them out briefly when they were released and really like the additions a lot; however, there are a few things I need to experiment with to verify how I personally would like to implement them in my own work before making those videos/suggestions.
Thanks for taking the time to watch and comment!
@@JarredLove Please have a updated vid usign the new Maya matix nodes.
I really like this approach as it makes for a clean graph and the parent space transforms are all in one place. I wonder how one might achieve blending between spaces this, though?
Thanks! I'm glad you like it. If I understand your question correctly, you want to know how to blend between them instead of an abrupt switch? If that is correct, start watching this video from around 16.55 where I describe a way you could create a blending setup utilizing a 'wtAddMatrix' node. I hope that helps!
Jarred Love Serves me right for not watching to the end. Thanks!!
No worries - it's always possible I don't explain something well enough and it doesn't make sense... so I just wanted to be sure!
hello jarred thanks for these amazing tutorials, im a begninner in character rigging and eagerly wants to learn about matrix connections instead of direct maya constrains (im slow learner btw which takes time to undertstand ) so please if you have beginner tutorials or anything like simpler terms to understand that would be really helpful ps i love your all videos of matrix constraints im getting alot of information
Thanks for taking the time to watch and comment! I'm glad you're finding my videos useful. Be sure to check out the most recent matrix video where I go over the exciting new matrix stuff added in maya 2020 (well... exciting for rigging nerds like me...) ruclips.net/video/7A98wukXsJQ/видео.html - it should give you an idea of the minor tweaks you'll need to consider in order to utilize them for potentially cleaner setups!
As for some more beginner friendly tutorials, I don't have many at the moment but could potentially add some in the future. In general I originally set out to make my videos at a bit more of an intermediate level of rigging since there are a lot of other creators who have covered a lot of the basic stuff pretty well. Still, definitely something I could do in the future!
@@JarredLove thank you 🙏🏽
hello
i same your rig character by matrix when switch Between enam attr jump to position and not snap .
can help me?
Hello, I replied to this, but it seems to have disappeared between when I finished typing it and hit reply... so sorry if there's a duplicate that pops up somehow...
Yes, the snapping is going to happen - that's unavoidable unless you write some sort of plugin to automatically deal with the popping switches will create...
So basically, you'll need to write a helper script to move the control back to where it was before the space was changed. It would go something along these lines:
1) collect world space translation/rotation from the control
2) switch the space
3) apply the world space translation/rotation that you collected before the switch
NOTE: your switch should always used stepped keyframes, and your control's keyframes will either need stepped keys for the switch, or 2 keyframes (one on the frame right before the switch, and one on the same frame as the switch).
You can collect and set the translate/rotate values with the 'xform' command utilizing the 'worldSpace' flag/kwarg
Hope that helps!
Hello, I have a question about a problem I encounter trying to build this on my rig. I have a prop that I'm space switching between the left and right hand and the world. I can get the prop control to follow translation of the desired space, but when I rotate the drivers the driven control has bizarre rotations happening. Do the drivers have to have frozen transforms?
Hey Sean, thanks for taking the time to watch the video and give it a try! I'm sorry you're having difficulties, and it's a little difficult to know what's wrong without being able to see the file... Is it flipping when you switch between spaces? Or do you mean that you rotate your hand control and the prop is rotating a completely different way?
In general, I would avoid freezing transformations like the plague. It almost always causes problems when you're trying to debug stuff since the freezing process still stores a bunch of offset information onto the transform making the resulting matrix actually different than what you think it is... It's just an extra headache. Instead, I just use another transform as a buffer node which will be used to 'store' all of the non-zero transform values so that the node I'm interested in will have a clean zero state.
I don't know if that is enough to help you fix your problem, but if it's not, a little more info could hopefully help point in the right direction!
@@JarredLove Hey thanks for the response, actually I found that I has used the incorrect parent world inverse matrix. Got it sorted out and wrote a nifty tool to switch. Thanks for sharing this tut!
Aha - yep, that'd do it! Glad you got it figured out!
Hello Jared. I'm trying to reproduce your maintaining offset setup here. There's some way to connect the "offset" multiMatrix´s (the temporary one, used just to get the offset calculation) matrixSum directly on the choice node Input using python instead of creating those matrix attributes just for store the data?
I've tried:
offset = cmds.getAttr("temp_multMatrix.matrixSum")
cmds.setAttr("name_of_the_choiceNode.input[0]", offset)
but I get an error:
Error: RuntimeError: file line 5: setAttr: Error reading data element number 1:
I believe the error is due to the type of both nodes aren't the same or compatible. If I add the flag type="matrix" in the setAttr command I get another error:
RuntimeError: file line 5: setAttr: The attribute 'name_of_the_choiceNode.input[0]' does not accept data of type 'matrix'.
How would you proceed? There's some problem in just connect these attributes on the node editor, and keep all the temporaries multMatrix or I'll get a cycle?
Hey Bruno - so sorry you've run into this problem. I'm currently on a vacation for 2 weeks, so I'm away from my computer and can't do any explicit testing to make sure I provide a correct answer. Once I get back home, I will look more into it and we can figure something out. In the meantime, could you please give me any other details of what you're trying to do that you think might be helpful (if there is anything else)?
I'm really sorry for bothering you on your vacation, man! Actually, I'm trying to connect the result (the "matrixSum" output) of the temporary multMatrix used to get the offset calculation between the target and the driver via python, instead of using those matrix attributes on some other node to receive this information, you see. But don't worry about this right now, enjoy your vacation and sorry again!
@@brunosilva3170 no worries! Thanks for your patience and understanding
@ Bruno Silva - Ok, well... apparently, I lied about just setting the choice node's input atttrs with matrix data.... I'm terribly sorry to do that to you.
I've set the choice node inputs with other data (probably just float values) in the past, and if you want to put matrix data on the matrix math node inputs (like a multMatrix) without keeping a connection, you have to set them manually since they lose their matrix data as soon as you disconnect them... Also, the choice node can accept and pass matrix data along when connected...
So with all those conditions/quirks, I guess that I (foolishly) assumed you could set the data on a choice node and it would actually accept it and work just fine. I did several tests - one of which was to connect it to a worldMatrix of some node temporarily to try and 'set' the attr type of the choice node's input to be a matrix type, then disconnect it and set the matrix data... but nothing I tried would work.
Sorry to send you down that annoying rabbit hole, but it looks like you will need to pick a node somewhere in your hierarchy and add those offset attributes. The good news is that you can actually set them when you create them to make it work... You will have to do this in order to get the proper offsets because if you keep any temp multMatrix nodes and connect their output to the choice node, you'll get cycle issues - the offset matrix values need to be static. I would suggest doing it on one of the top group nodes in the hierarchy for that body part, or if you have a single node in your hierarchy that you use for various configuration attributes...
I tried to add a note to that part of the video, but the ability to do it has been removed by youTube, so I made a note in the video description...
I've really tried here as you did, but at the end of the day, I kept the attributes in the parent group of each limb setup, as you suggest in the video. Despite that, this setup works really well! I'll try to use it as much as I can in my future rigs. Thanks again, Jarred!
@10:53 I don't understand why the locators are necessary in the constraint version?
Hey MrBrN197, those nodes don't necessarily need to be locators - an empty transform node will do just fine. I just used locators to show you where those nodes existed in space. Their purpose is to give you several nodes to parent constrain your driven item to without having to deal with any kind of offset issues since the offset would be different for each driver (head, hips, master, etc).
Maintain offset doesn't really work on constraints with multiple drivers that you are blending between because it can only store one offset (instead of one per driver). So the easiest way to ensure a 'clean' switch is to have transform nodes that match the position and orientation of your driven item, then parent those to each of your 'drivers' and use the nodes to do a constraint without any offsets.
hope that helps!
@@JarredLove are you referring to an orient/point or parent constraint. I don't seem to get any issues using a parent constraint with multiple drivers on an object with maintain offset checked. the offset is maintain between both drivers.
Hey MrBrN197 - aha! You got me there - as it turns out, parent constraints do have per-target 'targetOffsetTranslate' and 'targetOffsetRotate' attributes to store those offsets.
Back before the parent constraint was added to maya you would typically set up a space switch with a point and orient constraint which only store the single offset so you kinda had to make those extra empty nodes to line up the pivots... After I started using the parent constraint, I just kept doing it that same way! Man, you get used to doing something a certain way and don't always catch when you don't necessarily need to do it anymore!
So, in using a parent constraint, you actually wouldn't need those locators/transforms and it should still work fine; however, since the stored offsets are somewhat hidden away within the constraint node, it could be a little bit more difficult to diagnose if there's something wonky going on with your switch. Having the transforms there does make it a little easier to select the node for a given 'driver' and see where that pivot is and how it's oriented in space... But, there's really no reason you couldn't create a tool to make temporary locators and use the values in the constraint to give yourself a visual cue when trying to solve that potential issue.
good times!
@@JarredLove Ahh I see. Thanks
Hi Jared. Can you share your example file for deep learning? Thank you.
Hello Oleg - so sorry to reply to you so long after you posted, but I've recently moved and it's been a lot of work trying to get everything done! I still don't have my desktop computer set back up so I can get back to CG work...
I'm a little hesitant to put up a file since there may be a point in the future where I would need to take the file back down or it would lose it's hosting or something and someone who finds it after that point wouldn't be able to benefit from it... I've seen several tutorials online where the images or example files are just not there anymore and it pretty much makes that tutorial a dead end for trying to learn from it.
But, I will consider it and may look into doing that at some point (maybe keeping files up online is not as big of an issue these days as it used to be...). Was there any particular part of the video that needed further explanation?
awesome info, i always try to use matrix constraints in my rigs, i absolutely love them, but never used them in a space switching setup, very clever method, thak you very much. Any idea on how to setup an aim constraint with matrix nodes? i saw something similar on the cult of rig channel, but it was to complicated for my little brain :-D
Thanks! I'm glad you enjoyed the video!
It is possible to set up an aim network, but it requires a lot of extra nodes and is kind of a headache to get it to work correctly (not as clean/simple as the point, orient, parent, and scale networks - which are really all the exact same network but just driving different attrs on the constrained node)... And it may not even evaluate faster due to all the extra connections and un-optimized operations since some nodes can handle so many different types of operations... Here's a blog post talking a bit about the math behind the aim constraint that you might be able to use to build it:
sugarandcyanide.com/blog/2009/05/22/vector-is-that-you-its-me-and-im-blank-on-a-witty-finish/
The blog post is geared a bit more toward how you would need to calculate the data in order to write a plugin for an aim constraint replacement node instead of how to create the node network to make the constraint, but it's helpful to extrapolate what types of operations you would need to hook up... If I remember correctly, you would end up with some vectorProduct nodes using the dot product operation to get your rotation axis vectors to be orthogonal and feed those into a fourByFourMatrix node to create the final matrix....
Now, probably the easier thing to do (and what I do) is to go ahead and use maya's aim constraint, but then de-cycle it as much as possible by snipping connections or driving them with something else where appropriate. Here's a video from cult of rig (love that stuff!) on how you can de-cycle constraints:
ruclips.net/video/wT4D_I89aQ8/видео.html
Fortunately, he's actually using an aim constraint to demonstrate it. You may have already seen this one since you mentioned watching some of his videos, and you don't necessarily have to watch all the explanation parts where he's describing the graph evaluation (although I think it's really helpful insight) - so if that makes your brain want to explode, you can focus more on the parts where he's adjusting the connections. If you want to retain the capability of the constrained node to be moved (whether an animator directly or indirectly causes the constrained node's translate values to change), you will still need to leave the translate connections cyclical; however, if the aim constrained object can be 'split up' with the parent and parentOfTheParent nodes the way he gets to in the latter half of the video, then the cycle can be completely removed.
I hope that helps!
thanks a lot for your reply, yes i saw that part, actually i watched all the season 00 , and i was lost at the season 01 :-D i'm really not good at math ! so de-cycling it will be then :-D (though , i remember when i watched rafaelle's video, i tried to replicate what he did, but i was having less framerate than the cyclic one... maybe i did something wrong , or maybe maya was cashing the constraint, i don't know :-) ) , anyway, i absolutely love what you're doing, and i hope to see another video from you soon :-D cheers.
Hmmm, that sound a little odd - perhaps your computer was doing something else that demanded more computation as you were testing the pruned aim constraint...? Were you testing on a very simple scene of only a driver/driven node with the aim constraint between them? It may also be helpful to do a timing test with a few hundred duplicates of a default aim constraint with a little animation on them, then a duplicate file where the constraints are de-cycled and see if it was just a fluke...
There's another comment for this video asking how much faster this is than a constraint. You can look at my reply for a little more detail of how to test it. To generate your file, you can create an aim constraint and animate it a little, then save it and do some imports (you can script the import, or just import in stages to a new file - import 5, save that separately, import the new file to have 10, save that separately, import that a few times to keep building the number of constraint setups you have in the scene) to get a file that has 200 or so of them in the scene - then de-cycle your original file, save it and do the same type of import method to get another file matching your first test file, then do the timing tests on each and see how it goes.
Yes, i tried on a very simple setup, i'll do the import method and keep you informed, i'd like to know the result since i use quite a lot of ribbons setup in my rig, they're not really heavy, but i'm trying to make them lighter , thanks for the testing method :-D oh and i also really liked your ik arm setup videos, thanks again.
Just tried on 200 aims, no difference at all, almost same fps, with the cyclic one being faster at times.. weird. (Just tested with parralel evaluation only.)
this isn't a good solution, if you rotate a driven object's parent, the driven object will still obey its parent as if there was no connection, then, with that parent's offsets affecting how the child behaves, if you move your driver object the driven object will be out of sync, so you're not really in the "space" of the driven object.
and I dunno about y'all but my animators will even move the top most node to fit the starting point of their scenes so there's NO WAY to ensure these connections will ever work as intended.
Thank you for the comment. That's interesting - I don't seem to have the issue you brought up when I work with it. Whenever I set up a matrix constraint, the driven node no longer follows its actual parent node but instead follows along with the driver. My guess is that you may have made a mistake somewhere in your connections that prevents it from working as intended. Working with matrix nodes can be a little confusing and aggravating at times - especially where multMatrix nodes are concerned because the order of input is critical to get right (otherwise it will give you what appear to be strange results).
Something to remember is that there are multiple ways to rig things. Not every method will be the best fit for every situation, so you need to use what's best for your particular needs and requirements. These matrix node constraint systems have the ability to really speed up the rig functionality by streamlining connections and making the data flow as efficiently as possible through the rig. But, something to be aware of is that it does become less and less noticeable as computer processing power increases (and things like parallel evaluation helps as well). Even then, if you need to have 100 or even 50 characters in a scene, the constraints may begin to bog the scene down and these are a tool to help lighten that burden on the system - scene splitting where you have smaller collections of characters and render in passes to composite together at the end is another option as well.
@@JarredLove thanks for the response even though the video was posted in 2019-ish... I'm coming back to this now and trying to find where I went wrong.
you are welcome! If you're still having issues with the matrix system 'flipping out' as you move the driver or the driven node's parent you could try simplifying your setup and just get a single matrix constraint working first before applying it in a 'space switch' situation. Pair it down to a node as a 'control' (like creating a nurbs circle or something), and a 'driven node' with a parent (like a cube with a group node) and get the constraint working with the matrix nodes to drive the cube with the circle. then move the group node around and/or parent it to some other nodes and move them around to see if the constraint is actually working. If it's not, there's probably an issue with your connection order into the multMatrix node.
good luck, and I'll try to help out as best as possible
Hey I got it to work!! Thanks for you help and videos,
@@JarredLove question... what's the best practice for adding spaces to an object already set up with spaces? should I disconnect the decomposition from the target object, then capture the offset and hook that up to the choice nodes then re-hook up the decomposition to the target object? (I've had it break things for some reason)