Control Rig quick start guide! Basics, IK/FK spine, IK/FK arm & in-game leg IK!

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
hey what's up YouTube I hope you are doing well in today's video something a bit different I've not been super productive lately in terms of YouTube videos and patreon projects because I'm taking some time off to get myself up to speed on the latest ue5 features there are tons of new features I haven't had the chance to experiment with yet things like PCG geometry scripting scriptable tools and so on features that I'm most interested in and features that I will definitely want to showcase in upcoming projects and videos one feature I also wanted to try was control rig and so I finally gave it a fair shot and spends the last three days or so touring with it another though most of it is relatively straightforward some of it is also not now I want to point out that epic has done an awesome job documenting control video and has provided a great educational resource in the form of extra content available for free on the marketplace so I obviously took a deep look into it and had some difficulties making sense of the most advanced examples hence why I decided to make a video on the subway you see I was interested in building a decent trick for a personal project of mine and was Keen to replicate this neat ikfk spine setup now my philosophies to never copy anything unless I understand it and so with great struggle I reconstructed that spine setup from scratch a simpler one with a few adjustments and thought a quick breakdown would interest you guys and then it kinda spiraled into hey while I'm at it why not make a quick start guide and show some other things as well so in this video I'm first going to go over the basics of control rig then I'll make a breakdown of this ikfk spine then I break down of a switchable ik FK arm and finally I'll explain how this in-game ikelex setup Works alright let's dive right into it first of all I used blender to create a basic Armature the one important thing when working with blender and control wig is to make sure the bones forward axis is x-axis the secondary axis is likely to be y or negative y That's the setup that worked best for me I case in control rig worked out of the box with the Armature exported that way now it's likely you can get it to work with bones oriented differently but I personally had a lot of issues until I use those export settings so you do your I guess next in UE first things first make sure control wig is enabled having imported my skeletal mesh I can then create a blown Ctrl V and import a hierarchy or right click and create one from that Skillet animesh same but different in case I update the skeleton maybe tweak the Arcane blender and re-import it at a later date or something I can refresh the controls radio key like so now there's a way to do that automatically using the construct event but mounts that played on having done that you can now do many things like create duplicate and remove bones create nurse and nerds are quite important the way I see it they are like dummies or empties in your typical 3D software I think it used to be called something different in earlier versions of control rig I'm not sure but it seems like everyone has a different name Founders for instance that content example has a bunch of rigs with nulls named buffers and that kinda stuck with me so if you hear me mention a buffer I mean null anyway nerds don't do anything besides having a transform and potentially being pounded to something and being the parent of other things most often you'll use nerds to organize your hierarchy apply transforms to a group of controls and so on next obviously you can also create controls and move them around but be aware that this is the current temporary position to have this position be the controls quote-unquote zero position you can right click on it and call set offset transform from current you can also do that based on the closest bone or by creating a control directly on a bone like so I'm not going to go in too deep here because again it's all pretty straightforward and the documentation does a great job at explaining its basics okay so you can do plenty manually but you can also do plenty using nodes this construct event is like a blueprints construction script it's fired Once Upon that controlling being constructed so you can choose to do expensive computation and not worry too much about performance here so you can create nerves and controls update initial transforms set of parents and so on through procedurally build their wig that way you don't have to do anything manually besides building the construction logic obviously it's all automated and the controller can be ported to any skeleton which is neat so let's do a quick example first you can force an update on the skeleton so you don't have to refresh it manually in case the hierarchy changed so I'm going to delete all bones and courses import skeleton node to import Bones from the currently assigned skeleton cool next I'm going to create a function named create spine and add an input pin now it says one variable you are going to work with the most in control rig is the regular Mount key here I'm going to make an array called Bones then for each I'm going to create a control it's going to be pounded to that bone and its name is going to be that Bone's name press underscore control now a control can be many things it can be made to iron things so likely to have no effect during translation or the other way around or it can support all transforms location rotation scale right it really depends on what this control is meant to do here I want to have full control over it so I'm going to set this initial value to a transform and that's what's going to drive this controls value type here okay if you set that initial value to a vector this control is going to be a position control you get the ID now I find it easier to create all controls first and then worry about their transforms later on and as you kinda have to deal with relative transforms during the creation and it's a bit annoying so in order to do that I'm going to create a local variable by the way this controlling editor shares much resemblance to blueprints right you have access to global and local variables you can collapse graphs and so on to avoid creating a spaghetti mess just like in blueprints you can also get an input pin via its own node super useful anyway this local variable is going to be an array of rig elements and I'm going to set its length to whatever length that bones array is then updated to keep track of controls I created like so once controls are created I can set their transforms all in one go using the bones transform array and voila note that it's also important to return that execute context okay let's add that function to the construction event and forward the list of bones here there are many solutions you could use a remote and construct the list manually like so or select all the desired bones click and drag and create an item array cool however it's apparently not working well not quite right I do have controls in the ER Key so it works I just don't see them so let's tweak those controls shape maybe use a circle and scale it up a bit better although depending on your bone orientation and all you may need to tweak the shapes rotation like so now I want to point out that there are many ways to do things in control rig for instance instead of using an array of rig elements you could use an array of names and find each bone same but different you may use those tumble on that kind of setup when dealing with the left and right side a first for loop with two names L for left side and R for right side and for each side Loops through an array of bone names concatenated to find the left and right bones to create controls for and whatnot personally I find it easier to deal with arrays of rig elements rather than names but you do edges anyway controls are still not working that's because here a controls the child of a bone so moving it does not result in the bone moving right so I need to tell a control rig to take each controls transform and apply it to the bone that control is bar into two and that happens during the forward solve here I created a construct spine function so to be consistent I might as well create a forward spine function same thing use an array of weak elements this time called FK controls and here it's as simple as it gets just forward those controls transform to the bones transform in global space and that's it the transform of the first control in that array is applied to the first bone in that other array and so on and so on cool I still need to send that function the list of controls though I could do that manually right but here I'm going to do things differently so that setup doesn't break in case the controls names are later changed I'm going to make this function output its local array foreign [Music] I could also set a global variable directly within that function but that'd be a bad design choice that would constrain that function to create a spine and only that right whereas by choosing two output that array I can actually use this function to create any kind of FK controls not just the spine arms legs whatever sweet so I'm then going to pass that FK controls Global array to that function and actually I'm going to rename it to forward FK controls because there's no reason for it to be specific to a spine and Tada it's working except that not really controls do have an effect but behave on their own like the hierarchy has no effect right and you'd expect controls to inherit movement from the controls below but that's not what's happening that's because the hierarchy is wrongfully built and I kinda added that on purpose first because I wanted to demonstrate that the hierarchy is of great importance and second because I also wanted to show you you can re-parent things using nodes you can for instance use the switch parent node to save hey that element is now the child of that other element do that a bunch of times and you can reconstruct hierarchy and now it behaves properly well almost but let's put on everything all right for just one more minute last important step control rig has the concept of a backward solver meaning the forward solver is used to forward transforms from controls to Bones right backward you guessed it is the other way around from Bones to controls that's useful in case you want to edit an existing animation because that animation would only contain a bunch of Bones transform right so Ctrl read needs a method to First recreate the way controls are moving along with the bones during the animation so you can then edit that animation if that makes sense and here once again it's as simple as it gets just forward transforms from the bones to the controls in global space still and that's it [Music] you can then double check that controls are all moving properly by using a specific animation and turning on the backwards over here cool that's one way of doing a super duper simple FK setup however notice this I rotate this widget 45 degrees and it rotates 90 degrees now again I want to remind you that I just recently been playing with control rig so I might be missing a few things here and there but as far as I know that's not the right way to create a controller yet it's what most YouTube tutorials demonstrate for some reason even the documentation shows this approach despite this note telling you its best practice not to do this now I know control ranges is a quite uncommon stack approach to compute transforms it's as far as I know designed to avoid cyclic dependencies amongst other things but it still doesn't entirely prevent this kind of behavior and it just makes sense see this control is parented to this bone so this control inherits from these bones transform so I'm rotating this control 45 degrees which makes the bone rotate 45 degrees because of the applied transfer right thus that control further inherits of 45 degree rotation from the bone it's parented to and ends up being rotated 90 degrees now typically in rigging you have a hierarchy for deforming bones and one for control and your job as a rigor amongst other things is precisely to avoid that kind of issue I Promise You anime haters don't like that sort of weird Behavior so here's a better way of creating this simple FK setup I first created a control for the root bone it's the parent of the first control I created here right then that control becomes the next controls parent and so on and so on this recreates controls with the same exact bonyarky but quote unquote separated right thus serving the cyclic dependency issue the final step would be to drag the control rig into the scene and that automatically puts you in animation mode you may then keyframe these controls however you like to create an animation animation that you can then export to an animation asset you can also edit an existing animation by using the sequencer on a skeletal mesh right click on it select back to Ctrl rig and select your Ctrl rig anvara that animation has been backed into a bunch of keyframes for your controls keyframes you can then tweak to edit your animation and re-export it again the basics are all very well explained in the documentation so feel free to take a look at it if you want a more detailed step-by-step tutorial now that's the most basic FK setup and if you're serious about creating good looking animations you know that you ain't going to go far with just such a basic FK setup for the entire rig inverse kinematic or ik is most often necessary and for the spine especially you really do need extra controls to under hip swing and that kind of thing not to mention squash and stretch limb twist and so on rigging is definitely its own craft not that easy to learn but having a decent rig makes a huge difference when it comes to animation untrue a more advanced exam version this FK ik spine we great for hunting hip swing and just a nice setup to have overall especially for cartoon characters and back it up because we're going from simple as can be to quite complex once again this particular setup is entirely copied from this content example so shout out to the engineer or engineers at Epic who made this I merely made it in my opinion a bit more easier to digest and got rid of minor Parts but that's pretty much it I take no credit for it alright let's dive right into it the one important thing to graspier is that the ik and fkrk have to be separated the ik is parented to the root control so it moves around with it and is used to generate a spline the fkrk is isolated and isn't parented to anything if can nerves are then placed on that spline and FK controls which are pounded to nurse further allows the user to tweak the spine in a forward kinematic fashion let's start with the construct event first I simply create a null and a control for the root bone then have the construct spine function which takes a list of bones on a parent in that function here I first prepare local arrays and make sure they are correctly sized for each spine bone I create a null and a control attached to it this control is going to be the next nurse parent to create that kind of descending hierarchy null control null control and so on I then simply snap those nerves and controls onto the bones that creates those zero stickers right the FK controls now this spine setup is meant to work with a bone chain of at least four bones but you can have more in fact in the original example it goes from the pelvis all the way up to the Torso so it has a total of five bones but you see the ik controls the oppositioned on the first two and last two bones these two are to control the spine's end pawns and these two the spines converter and that's what these few nodes do get the first two and last two bone transforms using those four points I create a spline and get its rest length next I create a null to be the parent of all ik controls why not here I choose to parent it to the root controls so the ik spine moves with it then I prepare the ik controls array and create them those two at each end of the provided bone chain to control the spline starting end points and two more in between two controls the spline excavator controls be positioned on the four respective bones and that's the construction event onto the forward solve then well first forward the root controls transform to the root bone next the spine is the headache inducing part buckle up I first send the list of controls nerves and Bones then I can choose to remit stretch and if so how much it can stretch based on its initial length the rest I'm going to explain in a second so first step is to create a spline from those ik controls it's pretty straightforward I just get their transforms and build an array of positions and then create a spline from that array then for each bone I need to decide where they should end up on that spline using a 0 to 1 value meaningful four bones that be 0 1 3 2 3 and 1 and in order to do that I just leverage for each ratio pin to build an array of four values one for each bone then I remap that zero to one range to another zero to one range meaning assuming this is my spline going from zero to one I can say hey actually that bone chain isn't going to be from top to bottom but say from here to there that sells the way I decide if stretch could be limited knowing those spline's default length and its current stretch length I can say hey that current zero to one range should actually end up here its stretch is to be prevented so that's what this function does it takes the current spline length and a maximum allowed length assuming this is true A Min and max range a slide value to make the whole chain slide on the spline and have further control over it on a reverse value that tells if the stretch limit should happen at the top and the bottom are a bit of both and then obviously I send the list of 0 to 1 value used to remap then here I first compute the spline's length ratio can be below 1 then for each value I'll compute a new remapped value so prepare a local array next Loop through all values to update and store the result in that local array which is then returned this may look scary but it's actually quite basic math similar in principle to the remap value range material function just with a bit more controls thus with a bit more adds and multiplies but nothing to be scared of as though again do yourself a favor on avoid making a spaghetti Mess by getting those inputs via their own nodes rather than dragging a dozen of wires from two screens away anyway know that those values are remapped if limiting stretch those remap values need to be quote unquote reproducted on the spline because planes are weird if I don't do this this happens meet we're getting close next for each remapped value I get the splines transformed at that 0 to 1 position and for each I also interpolate the top and bottom ik controls rotation and scale the interpolated rotation is used to drive the splines a vector this is with and this is without notice how the roll is quote unquote distributed along the spline [Music] same with scale I don't actually care about the spline scale here finally I replace the first and last rotations with the ik control's original rotation this is only relevant in case stretch is limited as this happens I lose control over the Bone's rotation and the start and end of the bone chain because due to the stretch mutation they can end up somewhere on the spline if that makes sense last bit and that's probably the most confusing part convert that array of spline transforms to a local space to set those nerves transforms in local space then that's confusing as well combine JFK controls transforms with the transforms of the nerves they are founded to to create the final list of transforms in local space and convert each to Global space to finally apply transforms on the bone chain and voila now I apologize that bit here would be hard to explain in Greater details without doing a complete course on coordinate system and space switching so I remain somewhat vague here but yeah it's at the end of it well not quite there's one last step remember the backwards solve so first the root control is simply snapped onto the root bone then comes more trouble given a chain of Bones we need to derive where those four ik controls lie in space to create a spline that result in the same bones transforms once the forward solver is applied does that make sense it's some kind of reversing right I haven't looked into it that much to be honest but again it's just more math to create an array of four transforms transforms used to set those ik controls transforms in global space and here we have it a quite usable ikfk spine setup again I can stress this enough this is not my own work I merely recreated this existing setup from scratch and made it easier to digest so this is not mine to sell thus in case you're interested files are available for free on my patreon also shout out to the technical writers and engineers at Epic for producing these great great documentation and this cool content example foreign [Music] control for the route next I construct FK controllers for the arm nothing fancy [Music] there's a clavicle control which is parented to that root control I just created zero brown blue arm and hand I keep track of controls created in an array send their transforms here and returns that array to the original Global variable next has the ik controls for the arm first I create another pounded to the FK clavicle then I create a control for the ik pole on hand both bounded to the panel [Music] the pole controls translation is set using this compute pole Vector which is a function that comes from the standard function Library that's by the way an awesome control rig feature you can link functions in between control reads so this file is just a control rig like any user right it has a forward server on all and contains functions you can use in any other control rig that's neat so this compute pole Vector function does a bit of math to figure out where that pole Vector should be located based on the triangle formed by the three bone chain you give it there's no one right answer to this problem by the way the pool just has to lie somewhere on this plane pretty much foreign offset value you can play with to set how distant that pole is from the elbow which I personally come to prevent it from being too distant on occasions cool that's the FK and ik controls finally I create a float control to switch between FK and ik I would use a Boolean control but for some reason it's not exposed here yet so as far as I know there's no way yet to create a Boolean control using nodes so float it is no big deal then repeat that whole setup for the right arm next the forward solver to forward the root control transform nothing fancy next if in ik mode apply the FK clavicle transforms too because the clavicle isn't part of the IKR then make sure ik controls are visible apply the turbone ik on the upper and lower arm apply the ik hand control transform draw a line from elbow to pole with the same color why not and the important bit here when in ik mode FK controls follow along now it's worth noting that this ikfk switch isn't perfect there's a tiny jump see and I don't know why to be honest I looked and looked but couldn't find the reason if you know why please tell me in the comments below it could be due to some rounding errors or floating Point Precision issue I'm not sure anyway due to this issue I can't just snap FK controls to where bones are well I could but due to that imprecision this ik pole would drift on and on upon switching back and forth between ik and FK so instead I recompute the same two bone ik using the bones transforms it's pretty much the same but that one updates bones you give it and that one just speeds out transforms bones would have if the attack was light if that makes sense thus FK controls follow that LK chain along in a way that doesn't make this tiny and precision Cascade when switching between ik and FK on and on it's a bit of a hack and again I'm still learning I'm not sure that the best way to do things but it's for now the only solution I found anyway if in FK mode we'll apply FK control transforms and figure out where the ik controls should be to create the same bone transforms if the ik was on right meaning compute where the pole Vector should be and play the hand ik control and that's pretty much it if I keep all controls visible at all times you can see this Behavior ik mode the FK controls follow along FK mode the ik controls follow along and I think currently is that the best way to go for a switchable ikfk setup but again I could be wrong let me know in the comments below if you have a better solution now keep in mind control ring is quite a beast of a system already and I'm only scratching the surface really and it's also a two-part system meaning control V can be used to create and edit animations offline right that's what I showcased so far but it can also be used in game to create procedure animations to activate case and all kind of cool things so let's take a brief look into this other side of control ring and see how to create an in-game leg ik system [Music] one thing to keep in mind is that you are likely going to create one control rate to author and edit animations offline a complex one right with lots of logic and you're going to create a separate one much simpler one that likely doesn't need to use backwards solver at all and say just under the Lego case that's exactly what this control rig does again I did not make this it's part of the starter content so feel free to take a look at it yourself and again Shadow to whoever made this I just merely tweaked a few things here and there and added debug lines so it turns out this is that simple but I feel like there are a few things that need explaining let's have a quick look then first for each foot trace for the ground and get how much that food has to be shifted in Z based on that trace for both feet interpolate that the offset of your time to smooth out the ik behavior a bit next use the minimum of those two offsets for the pelvis offset to prevent over extension apply offsets to the feet and pelvis in an additive fashion and apply the full body ik with a is locked in place so the full body ik is only a partial body solver and that's pretty much it now I admit that setup kind of fried my brain for a while because if you think about it here we trace for the ground so assuming our character is running and its feet are placed like so if we were to trace from that foot to the ground and shift that foot by however distance it is to it that foot would be snapped onto the ground at all times right and I remember I used to build ik Solutions with such a naive way of thinking back in the days and I had to do all kind of tricks to avoid this so how does this setup work because clearly it doesn't do anything special to prevent this well it doesn't Trace from the foot to ground that's the key thing it only cares about the foot's X and Y position and uses the root bone Z position slightly offset upward and downward to create a line Trace at the ground level this it doesn't care about where the foot is in the it only outputs how much is actual ground is above or below the base of our character its root bone so even if that foot is Airborne it's offset in Z by the distance and same for that other fruit and then the pelvis is shifted by the smallest of the two offsets to allow that leg to reach its Target foreign [Music] detail to keep in mind is that the sphere Trace is in global space or weak space this heat location is not a world position so if I move around and watch as you've said this sphere Trace outputs if the ground is flat it's always around negative 2 centimeters despite the ground altitude okay why negative 2 centimeters well the character movement component has some kind of safety margin built in that usually result in a two centimeter offset from the actual ground so the capsule is vertically offset by that amount hence why the feet are moved downward by the same amount to make contact with the ground one of the important thing to note is that the full body ik needs effectors to work with it needs targets to reach for the fit right and it obviously can be the full bones so Unreal Engine skeleton has ik bones that move around with the foot bones in most animations those are the ones that are moved around in control rig and used as a Victor if you have a rig that doesn't have such ik bones or they are not moving along with the foot bones for some reason there are workarounds you can create a control for each foot apply the foot bone motion to each control then move those controls around and use them as the factors and that pretty much does the same thing finally having set up this control ring all you have to do is go to your animation blueprint drop a control wig node where you want to apply this logic select the Ctrl wig and maybe expose the uik Boolean Cindy which should be forced if in air and ta-da that's it I hope this video helped you in some way in your control week Journey if you like the video consider leaving a like and subscribing to the channel also consider joining my patreon to get access to all kind of cool UE projects and support me as well I thank you for watching I thank you for your support I'll see you in the next video take care of yourself bye foreign [Music]
Info
Channel: Ghislain Girardot
Views: 5,681
Rating: undefined out of 5
Keywords:
Id: 8CZKXACS0J0
Channel Id: undefined
Length: 31min 31sec (1891 seconds)
Published: Fri Sep 15 2023
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.