That's so smart to snap them like that. I was super tired, but I decided to play another video in this playlist and force myself to watch it anyway. Wow am I glad I did, this content is gold. You not only explain how to do it, but why.
I htought we had made these vids unlisted. I m currently chasing down a strange behavior where everything works in Control RIg but it breaks in sequencer. So take it with some salt til we sort this out
Absolutely love this. As a (now) long, long time Maya animator coming from 3DS Max in the late 90's early 2000's, I have always appreciated just how advanced Biped was for it's time as it's STILL an unsolved capability today! The only thing missing here is full time FK/IK, choosing whichever transform method you'd like to use without the need to switch. Grab the foot and move it, grab the thigh and rotate, no need to checkbox. Granted Biped had explicit keys for Free, Plant and Slide, but I can't see how that couldn't be possible with Control Rig. Bravo my man!!
For anyone who doesnt understand 'why' we project L_Foot to the 'ball bone': First of all go watch a video on how project to parent works, it'll only take like 2 minutes. As for the 'why' of it, let's just say that it's because of the fact that changing the rotation of the ball bone through IK controls always requires you to do so by moving the L_Foot ctrl in IK, and thus, wherever the ball bone goes, it must be the result of L_Foot going in the same direction. The RV_ball_ctrl in IK can't move the 'ball bone', so we know for a fact that if the 'ball bone' got globally rotated in some direction during IK, it must be because L_Foot was rotated in that direction. The two are always coupled. And for those who dont understand the part after the 'project to new parent' part: Kevin is technically trying to rectify a problem that is a side-product of the 'project to parent' node. Because of that node, whenever the FWD_BALL_CTRL gets rotated in FK, that rotates the L_Foot, and RV_ball is rotated along with the L_Foot due to the parent child relationship, which means that although the RV_ball wont get any 'local' rotations from this action, it WILL get rotated globally. But the thing is, we do NOT want any action on the 'FWD_BALL_CTRL' to influence the global rotation of the RV_ball in any way (kind of a long story this one... feel free to ask). So we need to UNDO the global rotation that is being done to the RV_ball as a result of the FWD_BALL_CTRL being rotated. To undo this, i.e. to maintain the global rotation of the RV_ball as we rotate the FWD_BALL_CTRL, why not just take the local FWD_BALL_CTRL rotation that caused the RV_ball to rotate in the first place, and pass the negative of that into the local RV_ball rotation, right? That is a perfectly valid idea, and it SHOULD work! But... depending on how you do this 'passing the negative of fwd into RV', it will either work or wont. There are probably at least 2 reasons why it doesnt just simply work, so more than 1 really. But let's just focus on what I think Kevin is targeting. The local rotations of the 2 controls are NOT necessarily globally equal. For your local rotations to correspond to the same kind of global movement, you gotta have equivalent parents or something. FWD_BALL_CTRL is parented to FWD_FOOT_CTRL. RV_ball is parented to... guess who? RV_TOES! 2 completely different parents in completely different places, and we dont even know if their axes align perfectly. This basically means that you need some other way to figure out what a local rotation of X degrees in FWD_BALL_CTRL corresponds to in terms of local rotation of RV_ball... Or to put it even better (remember what we want is for the RV_Ball to sit perfectly still during FWD_BALL_CTRL rotations: You need to figure out the local rotations for RV_ball that are equivalent to IT GLOBALLY SITTING STILL :) If only we had some child of RV_Ball and made him sit globally perfectly still during FK, cuz the locality of that child relative to its parent would tell us what local rotations we'd need to do on RV_ball in order to get it back to where it was. Well, having such a child on RV_ball itself may be problematic, and besides, dont forget that we need an opposite rotation relative to the FWD_BALL_CTRL. So to do this properly, you need to create a sibling for RV_Ball, a sibling who will act the same way as the RV_Ball. Then you also create a child for this sibling. Remember, the sibling is an exact doppelganger of the RV_ball, always equivalent to it, globally. You need to make the child of this sibling not move at all during the FWD_BALL_CTRL rotations. If you can somehow do this, the local rotation between that child and its parent will be equal to what 'globally sitting still' corresponds to in terms of local rotations in the world of the RV_ball. If you 'rotationally constrain' the child to the foot bone, who remember, won't get rotated during FWD_BALL_CTRL rotations, you'll have your child sit perfectly still during FWD_BALL_CTRL rotations. The local rotations on this child, are exactly the local rotations that'll make the RV_ball go back to its rotation before the 'project to new parent' rotated it. These local rotations are also already opposite sign, because during the FWD_BALL_CTRL rotation, it's not the child that rotates, but rather it's parent rotating and the child sitting still. This kinda thing almost always if not always gives the child local rotations of the opposite sign as the rotation. Kevin keeps hitting multiple birds with one stone :D It's not as simple as it looks... Oh , I found that you can also do 'Take local rotation of FWD_BALL_CTRL as a quaternion, take its inverse, and pass that into the local transform of RV_ball_ctrl'. This does the job fine, no need to create extra nulls. When this DOESNT work, is if you use 'get control rotation' and 'set control rotation'... It all has to do with one doing sequential rotations and the other just 'setting' rotations.
What an amazing write Andy. Thank you for taking time to share all this. I think I have also learned a lot more since making this video about the use of World vs global (rig) space and am actually actively working on this entire setup to solve a lingering issue with sequencer. Its possible we may re-work this. Either way, what an awesome explanation and it sounds like you have this all dialed in. Thanks for watching and commenting.
You guys are just fantastic, I'm so happy I stumbled onto this channel and this series in particular. Thank you so so much and keep doing what you're doing!
You did such a wonderful thing. In blender rigify there are "IK to FK" or "FK to IK" button and you have to press if you want to align IK or FK, but it can't follow continuously like in this video. In Unreal Engine 5.4, I had to not convert Local Space to Global Space at 37.50 and I had to add Rotation Constraint to the end of both FK and IK sequence. After success, I achieved the same effect in TOE REVERSE CONTROL by continuing with a very similar logic. Before editing the graph editor for TOE REVERSE CONTROL, it started to rotate like CR_Mannequin_Body. Thank you.
Would you happen to have an idea why this seems to work in the control rig editor but not inside of a level sequencer? That's what I'm seeing on my end :o Either way really really cool stuff!
I have noticed a similar issue. I'm still working out what might be going on and for the immediate term have disabled switching and just work FK or IK straight ahead. As we increase our CR learnings I'm thinking we will either get some help from Epic with a bug or perhaps figure out where the flaw is in our setup.
@@livinfreestyle6727 Found how to go about this I think. So on my end what I need to do is. Lets say I switch from FK to IK. I need to key the IK controls on the last frame I am in FK mode. And then key it on the frame of the switch to IK. Sounds like something that can be fixed in the CR with an extra function. But wanted to share. Cheers!
thank you so much, this is soooo useful to me. the IK FK switch is amazingggggg!!!! 🤟🤟🤩🤩Do you have a tutorial is taking about the rig character with lattice? like we did in maya. a cartoon eyes which is use lattice from a perfect circle and wrap it to oval shape or artistic shape and the eyelid, eyeball just need to rotate it. the lattice will do the deformation after the rig rotate the eye.
Found the one is called graph deformer and in ue5.4 it have lattice deformer is added. and also Unreal Offical sample > content Sample> animaiton deform is have the lattice sample to show how to do lattice in Unreal. they make a custom lattice rig, and rebuild the deformer logic in graph deformer(the sample is 5.3 which is not yet have lattice deformer can use at that moment)..
Thanks for the great detals to share and I wonder there has been already pole vector placement function? if not, can we simply handle the correct ideal location based on positions of three current bone transforms ( thigh, knee, foot ) using vector projection between vec(knee, tight) and vec(thigh,foot) tp support the FK2Ik match. If there are any updates, it would be awesome! Once again, thanks for great tutorials!
I believe there is a pole vector placement function you can take from the Control Rig that comes with the third person project for example, BUT then you wouldn't have learned why it works 🤣
@@livinfreestyle6727 For sure, yap it is great way to see how it works as good example and utilizing the vector math on bone transforms seems to be pretty stable result I can see in addition! Keep up with the great tutorials!!
Thank you for the tutorial. Do you know about the snapper tool which can "pin parts of your control rig to objects inside your game world"? This is used in the Valley of the Ancients sample.
There is a "Snapper" tool in the animation tools section. THis is used for aligning usually props or controls to something while animating. A bit different than an FK/IK snapping tool. Is that what you are talking about?
These control rig videos are fantastic! As someone who is still trying to get comfortable in Unreal all your video's have been super helpful and I really appreciate you sharing your knowledge. :) Question, I tried your set up here for getting FK controls snapping to the IK, seemed pretty straight forward and simple. It functioned when I set it up, but the Set Transform node for the control has a "note" warning that reads "setting transform of parent after setting child may lead to unexpected results". Is that because the FK arm controls are parented under each other in the hierarchy? Your controls seem to be set up similarly but you don't appear to get that same error so perhaps it's something else wrong in my set up.
The order matters. I'm pretty sure in some of the vids i even had the order wrong and figure it out later. All you have to do is switch it so the upper arm happens before the lower arm for example.
@@Nabreu85 I mean switch the order you are doing things. Like make sure that anything you do to the upper arm happens before you do anything to the lower arm in the execution order.
Hello! I managed to make it work in the control rig (no pop when I toggle the switch) but in the sequencer when I toggle the switch the leg pops back to the default position, how can I solve it? It seems that the sequencer is overriding the control rig values. I'm not using the reverse foot, only the FK/IK part. Thank you very much
I've actually heard reports of sequencer doing htis in multiple cases. I haven't seen or had a chance to trouble shoot it yet. I think there was a recent post in the discord that people just turned it off or selected to animate IK or FK only until we get some clarity around it
@@davideconsalvo3563 Yes, I've seen wierd things with Manny as well, but right now I just power through one way vs the other until I can figure out what is going on with control rig in these cases. Once I feel like I have a solid understanding we can ping some of our friends at Epic for clarification
HI Kevin! Im following your series, Awesome work. I have followed the steps till 39 min and im facing issue with reverse foot snapping, as u say " ITS GOING BONKERS :P" rotating when switching IK-FK. I noticed there is a video jump around that time frame, anything of important in that jump then u do share. Hoping for solution. Thanks alot for the series.
ok. I don't see anything specific. So I would say the best thing would be to post your full Blueprint in discord forum-questions so we can take a look and see if we can find differences
This series has been invaluable to me as a newbie to Unreal Engine....do you think you'll cover how to make procedural walk cycles using this control rig? I'm struggling to find any in depth tutorials on how to do procedural walking in Unreal engine. There's only one and it glosses over it in 10 minutes
That's what I was thinking. Once we finish our control rig, we need to test it. Two different testing routes in my mind. Hand keyed animation and then I think it would be a fun project to setup a procedural walk for something like a spider
@@livinfreestyle6727 Yes please. Also if I may be so bold, procedural walk for humans. Because there's a lot more diversity in terms of personality and walking scenarios(i.e strafing,injured limp) that you can "animate with humans. Spiders are cool because it would teach people how to get the individual limbs to avoid each other and move in a consistent order
How would this work when keyframing the ik/fk controls when animating it in sequencer? Will it preserve the keyframe pose (let's say you already added keys for a pose and wanted to tweak it) or does the snapping override any keyed pose upon switching?
This is an awesome question. We have been discussing this very thing and you can setup keying, but it deserves a bit more of a deep dive which we will cover once we finish the advance leg. I have found that sometimes even the control rig out key stuff is finicky so until I have a definitive answer I'm manually setting keys or just choosing one or the other at shot start
hello again. am i correct in my understanding that a forward solve cannot override itself? that is to say: if i set the controls to a bone in the forward solve (after the construction script), and then later set the bone to a control, or vice versa. this is called a cycle you said? cant be done? im really struggling because your videos are dense and full of useful knowledge, but it isn't a complete step by step for an entire control rig setup. i got the backward solve. i actually have everything including full body ik switching as well as independent limb ik switching. my problem is with the pelvis. i dont know how to programmatically gain the function of being able to move the fk pelvis bone down in order to make the knees bend. thats literally the last piece and then ill have a perfect control rig
on a side note, sir. far be it from me to sound ungrateful. what you have put together is truly amazing. my question is: do you have any interest, perhaps in a livestream, to do a full step by step procedural control rig creation? im interested in learning how you put together your refactor when you created functions for all of your code. i see you fast forwarded 5 hours. is there a way to condense that into one harmonious video? what are the odds of that happening?
All feedback is welcome. I default to it being constructive. You can't survive in film if you can't handle feedback. So don't worry, I don't default to ungrateful and try to use comments as a means to understand how to do it better next time etc. As far as the overall style, yes the idea is to teach the understanding so you can build the bridge to connect it all, but if the gaps are too far I need to adjust. SOOOOOO....two things. Which skeleton are you working with? If it's the unreal one and you simplify to just a single control for the COG and IK legs does it work as expect. 2. As far as the "putting it all together" We're getting there. I don't want to make that video too early before we've gotten all the understanding and also make sure I myself have a clue of what is going on. We have a spine and a quadruped leg video in the works and then I think it will be time to put it all together and maybe even have a chat with our friends at epic about some of the instabilities we are seeing.
If I may suggest a potential improvement to the these tutorials, I think it would be easier to follow along if you expand the 'Item' pins on the nodes so I can see exactly which item you're working on? When they are collapsed, it's hard to trace what it is unless you click on the node. Thank you so much for these teaching materials
That sounds great. I'll do my best to remember this or at least call it out as to which one we are using. Thanks for letting me know this could be helpful
I apologize for the constant comments but, I just realized that the issue I was having exclusively with multiple axis rotations was stemming from the fact that THE GODDAMN ROTATIONS ARE APPLIED SEQUENTIALLY, i.e. when I pass a rotator with x:30 y:60 z:0 into a transform, the engine rotates the object along the X axis FIRST, and THEN wherever the Y axis ends up after that rotation, the rotation value on Y is applied to that NEW Y axis, not the original one... I was able to get rid of this unwanted effect by ditching quaternions and rotators altogether, and just using 'Set/Get Control Rotator'
Switching isn't working inside sequencer for some reason, I am tried different approaches, also a simpler setup with Parent constraints, but it never work with sequencer.
I just mentioned this in another comment, we’ve learned a lot about control rig and as soon as I finish the octa bot series we’re going to revisit this to see if we can figure out why this is an issue.
I think I missed something. I've been following these tutorials since the first and I don't remember making an L_ball_rv_ctrl_pose null. Is there are set of other tutorials that I'm missing?
@@livinfreestyle6727 I'm surprised I missed it. I follow along with the tutorials and take extensive notes so I can reflect on everything and replicate and review. I can give it another look
Day 8 of trying to get a seamless switch on my own after I got overwhelmed by your solution.... I've spent 12+ hours... Things work really well, as long as only 1 axis is rotated in both IK and FK.... I'm having the following issues: If RV ball isnt rotated in IK, I can rotate FK ball in all 3 axes at once without any issues in the switching. If RV ball has rotation in the z axis, I can rotate the FK ball in the z axis only without having issues. I'm basically having problems with the x y axes.... WHY??? I even accounted for the axes of the foot and the ball being rotated. I fed the X values to the Y, even accounting for the signs... I'll explain what I'm trying to do in a very visually descriptive way if anyone wants to read. I'm thinking simple. First, at the very end of the IK pipeline, set the FK controls' transforms to those of the joints, globally. Then, whatever I manually do to the ball joint in FK, I need to make the FK pipeline set the RV controls to a state that would make the same exact shape of the foot. I went about this slightly anecdotally (which is a bad practice, I know), but it should work, just bear with me. I took the example of raising the toes by x degrees in FK, i.e. rotating the forward ball control. To get the same shape of foot from scratch but in IK, you would need to rotate the reverse ball by x degrees to get that bend in the fingers, but then doing this alone would lift up the heel of the foot, which we need to lower back down if we want to get the same shape of foot. To lower the heel, I just rotate the reverse foot by x (- or +, one of them) degrees. That gets the foot in the same exact shape, with the only thing missing being the 'position' of the foot (it'll be raised up a bit due to the rotation at the RV foot), which CAN be easily dealt with by just moving the entire reverse foot TO the foot bone, cuz that bone wont have moved when playing around with the forward ball control. You also have to manually move the RV foot null (the one that controls IK) to where the foot bone is. You also have to constantly retransform the sibling of the reverse ball, the one that is used constrain the rotation of the ball joint in IK. The rotation of the ball in IK needs to be constrained to not the initial rotation of the ball joint, but rather whatever it was last brought to in FK. The first problem you're gonna run into is when you go into FK after having done a RV ball rotation in IK first. The rotation of the RV ball will put a local rotation on the forward ball control. (If anyone's wondering why this even happens, it is the result of a long chain of events. When you rotate the RV ball, you're rotating the RV foot null, i.e. the driver of the ankle. However, following basic IK, you're also constraining the rotation of the ball joint. So when you rotate the RV ball, you have the RV foot null making the foot joint rotate around the RV ball, but the ball joint retains its global rotation, i.e. it keeps perfectly still. Then at the end of IK, you set the forward foot ctrl to be the same as the foot joint, and the forward ball ctrl to be the same as the ball joint. The foot joint moves, the foot ctrl moves. But as the foot ctrl moves, which is the parent of the ball ctrl, the ball ctrl keeps still. This gives you a local rotation on the ball ctrl.... When your parent moves without you moving along, you get local transform...) You must not feed this rotation into the RV foot during FK. Because when you transition into FK, you're supposed to not alter any of the RV controls DURING the transition, you need to alter them WHEN the forward ball control gets manually rotated during FK. If you feed the rotation of the forward ball control to the RV foot in this case, you'll end up rotating the RV foot as soon as you enter FK, which would be incorrect because the RV ball rotation in IK wouldnt rotate the RV foot, so you gotta keep it that way when you initially enter FK. The solution is to separate the rotation that comes from the IK pipeline and the one that is done during the FK pipeline. Create a ctrl sibling (a twin) for the forward ball ctrl, and set the initial transform to be the same as his brother, and just turn off the visual shape for this ctrl, we'll just use it to store an offset. When the RV ball is rotated, that actually makes the FK foot ctrl rotate around the ball joint, which is what really gives the direct children of the FK foot a local rotation. In this case, both brothers get the same local rotation. However, when you go into FK, you'll be rotating the forward ball control only, and not his brother. This will create an offset between the brothers. When it comes to the RV ball ctrl, you want to set the rotation of the RV ball ctrl to however much it was rotated during IK, PLUS however much the ball joint got rotated during FK, and this value corresponds to the forward ball ctrl :) But when it comes to RV foot ctrl, you want to rotate it only by how much the ball joint has been rotated during FK, because only the manual rotation of the forward ball control would required the RV foot to move. This value is hidden in the difference between the brothers... Forward ball ctrl - its win = how much forward ball ctrl has been manually rotated. You'll also have to add some nodes in the IK pipeline in order to make the twin rotate (or rather, not rotate :)) alongside the forward ball ctrl. Forward ball ctrl is being set to the ball joint during IK, and that's why it globally remains unrotated during IK, however there is nothing that would make the twin have the same thing going on. Somewhere in IK, you gotta make the twin act the same way as the forward ball ctrl does during IK. It's not hard to do, should suffice to say that you just create a new ctrl that will always be equal to the offset between the two brothers, then in IK you set the rotation of the twin to that of its brother, i.e. making them equal, but then you do set relative rotation on the twin and you rotate it by the offset. So basically, do these: Create a twin ctrl of the forward ball ctrl Create a new control named 'offset_ctrl' under the twin. We'll just use this to store some value. Keep in mind the name of the null that the ball joint's rotation is constrained to during IK, you'll have to update this null during FK. Let's call this guy RV_ball_clone // Inside IK: After the 'rotational constraint' following Basic IK, set the local transform of the twin to that of his brother. // Now set these in FK: Global rotation of the ball joint = Global rotation of the forward ball ctrl // This is what we do by default Rotation of the RV foot = rotation of the forward ball ctrl - rotation of the twin (i.e. the rotation that was created during IK) // This will set the RV foot in the correct rotation Rotation of the RV ball = rotation of the forward ball ctrl // This will set the RV ball in the correct rotation // The RV controls have been correctly set now in order to make the same shape of foot that FK would make. Now we need to move the whole RV foot to the correct position Position of the RV foot = position of the foot bone Global transform of the RV foot null = Global transform of the foot bone Rotation of the 'offset_ctrl' = the rotational difference between the twin and his brother (deal the sign on your own) // We'll have to use this offset in IK // Now Go back to IK, and after setting the local transform of the twin to that of his brother: Relative rotation of the twin = local rotation of 'offset_ctrl' Once you dive deeper, you'll realize that the axes of the ball ctrl and the RV foot ctrl are not the same... The local X axis of one of them corresponds to the Y axis of the other. This isnt a huge problem and can be easily dealt with. Just pass the rotation of X of one of them to the Y of the other, and make sure you're also keeping track of the signs. But AGAIN, problem persists.
@@AndyU96 what a write up. As soon as I finish the octa-bot procedural stuff I will come back and revisit this. There is a setup in the default control rig that comes with the third person default project, it also has built in FK/IK switch. Id like to see if we have this same type of problem in sequencer with the fk/Ik switch setup in that rig. My understanding of how the control rig state machine functions has increased considerably since we first recorded those videos and maybe we can see what might be going on. I’m super impressed with your never surrender perseverance.
Maybe i did something wrong but. Looping degradation, or a dependency loop is still present in this solution, the ball offset control and the Heel control throw the foot into a dependency loop, which renders the use of the reverse foot mechanism almost useless. Because at the end of the day, you have only one properly functioning control from the entire mechanism which is a ball reverse. Anyhow you gave a discretion at the start of the video that this is A solution, not THE solution. Hope that the advanced ik you've figured a way of solving this really annoying problem. Thank you
I think we did cover a solution for the built in looping (its in the default control rig from Epic). I went over the problem/demo'd it at the beginning of the vid. If you need help finding it let me know.
@@livinfreestyle6727 Hello Kevin and thanks for your reply. I might've spelled it a bit confusing, but I've followed your rig setup from the basic FK video. In this particular video you show at the end a proper snapping of the ik/fk but you do so only with Ball RV control, for which it works just fine, but if you will try to use the heel control, or the ball offset (ball offset in this setup you use for offsetting the toe rotation), you will get the same looping degradation behavior whenever you try to snap back and forth. Which defeats the purpose of reverse foot setup. I've had to cut this feature from my own character rig for that reason. But maybe I've missed something while building it, so if you have this exact setup saved somewhere and it works with all of the controls properly without breaking I would be happy to look at it. I've tried to fix that problem myself, but failed. Anyways, thank you so much for this series, i've learned a lot.
FK IK switch doesn't present degredation for me *until* you try to use the foot roll animation channel after following all the tutorials up to this point. So it seems you'll be locked in to the control-based workflow if you want to avoid that for now given the current knowledge.
Yeah, and part of the foot roll was to demo the use of attributes. In general the teams I work with prefer the actual controls so we will be removing that in the final rig (I'll make sure I call it out) and we will have to do some performance testing on all of this for sure. We're also going to separate it out to be a "Limb" and a Foot so that we can use the limb for the Arm. I'm still scrambling to catch up with everything in 5.4 to figure out how to best get the info to you all.
Why do you do the snap on every frames? Wouldn't it be extremely costly to maintain that logic for every frame, every limb, and every character in the game?
So, you technically don't have to. And in traditional tooling like Maya you only snap when you need to, but in this case this is setup much like the default control rigs that come with third person. I was blown away that it was even possible. That said, one outstanding question and a thought, that we will answer once we finish our rig. -What happens to the animation curves as your switching back and forth. (I can mitigate this in my own workflow by selecting one way before each shot for example so I'm not worried about having the answer right now) -If we find that live snapping is problematic or doesn't make sense it's very easy to flip it to a tool instead for example. The logic is done
also one other note, I'm going to do an advance leg that will definitively solve the knee offset problem for any pose and we will update our snapping code in that tutorial
I just re-read this. One more thought. This control rig or at least the snapping is one that I would use for Animating. Not for in engine solves. Generally speaking (and per Epic) the control rigs you use at run time should be as simple as possible. This however is meant for asset authoring and I'm not really thinking of runtime case right now
@@livinfreestyle6727 thanks for the clarification On my side i use the control rig mostly for the deformer rig (twist, corrective joint.....) Your serie gave me a lot of ideas to test some pipelines with the animators, even if in the current state i don t think the anim in unreal is production ready
I'm at the 14th minute and I just cant help but think... If the issue of snapping stems from the difference in the reported transforms of the bones by FK and IK, why not just save all the transform information in some variables and pass that info to whatever control method is being switched to? Let's see what I'm missing here... Edit: Alright seems that my thinking was right, but instead of storing the info in some variable, you just grab the info and immediately feed it into the FK controls. But then I'm still only at the 19th minute... Edit 2: Alright alright, IK to FK is easy, but the inverse is harder... Because obviously, we had this pole vector that told the IK solver the plane to move the bend the bones along, but if the user does FK control and rotates the bones in a way that they arent bent along a single plane anymore, then the switch to IK will result in a snap... But the solution should be simple! Just calculate the shortest set of rotations for the bones that'll make them aligned on a single plane, rotate them as such, and feed that plane as the new forwards vector for the IK solver :D No? Let's see...
Such a great progression in your comments/thinking. YES...but not really. The problem is you can pose the the FK joints in a way that uses "twist" and the IK solver can't solve for that. So we do go over a solve for this in the advance vid. Also, worth noting that right now i"m not using FK/IK switching. I'm just using one or the other because i"ve noticed some strange things that I'm trying to narrow down as far as what control rig is doing.
The inverse world matrix A * world matrix B = local matrix to decompose the local eular rotation value so I assume, can we simply capture the reverse offset value by inv w mat B * w mat Z ? ruclips.net/video/MdjDkGNR6aM/видео.html
Maybe. When you say it like that I remember basic matrix stuff and it does seem like the inv world A & world B would be The item in the local space of B...Have you tried it? Next time I'm working on matrixy stuff I'll try it. Thanks for the ideas!
That's so smart to snap them like that. I was super tired, but I decided to play another video in this playlist and force myself to watch it anyway. Wow am I glad I did, this content is gold. You not only explain how to do it, but why.
I htought we had made these vids unlisted. I m currently chasing down a strange behavior where everything works in Control RIg but it breaks in sequencer. So take it with some salt til we sort this out
@@livinfreestyle6727 I'm watching from the ControlRig playlist
I've been rigging in Maya for 15+ years. My brain just exploded! thank you for this!🤯
Same....my head still hurts with the state machine aspect of this. Even the way constraints work is a bit different. Thanks for watching!
Absolutely love this. As a (now) long, long time Maya animator coming from 3DS Max in the late 90's early 2000's, I have always appreciated just how advanced Biped was for it's time as it's STILL an unsolved capability today!
The only thing missing here is full time FK/IK, choosing whichever transform method you'd like to use without the need to switch. Grab the foot and move it, grab the thigh and rotate, no need to checkbox. Granted Biped had explicit keys for Free, Plant and Slide, but I can't see how that couldn't be possible with Control Rig. Bravo my man!!
Its true and if you have been tracking Anzovin's stuff you can see how the ephemeral context based posing can work as well!
We could even make it so you could switch the mode and have full body IK on top of everything with the flick of a switch....
Holy shite that's AWEsome! How this flew under my radar is beyond me!
@@livinfreestyle6727
Yas!!!@@livinfreestyle6727
For anyone who doesnt understand 'why' we project L_Foot to the 'ball bone':
First of all go watch a video on how project to parent works, it'll only take like 2 minutes. As for the 'why' of it, let's just say that it's because of the fact that changing the rotation of the ball bone through IK controls always requires you to do so by moving the L_Foot ctrl in IK, and thus, wherever the ball bone goes, it must be the result of L_Foot going in the same direction. The RV_ball_ctrl in IK can't move the 'ball bone', so we know for a fact that if the 'ball bone' got globally rotated in some direction during IK, it must be because L_Foot was rotated in that direction. The two are always coupled.
And for those who dont understand the part after the 'project to new parent' part:
Kevin is technically trying to rectify a problem that is a side-product of the 'project to parent' node. Because of that node, whenever the FWD_BALL_CTRL gets rotated in FK, that rotates the L_Foot, and RV_ball is rotated along with the L_Foot due to the parent child relationship, which means that although the RV_ball wont get any 'local' rotations from this action, it WILL get rotated globally. But the thing is, we do NOT want any action on the 'FWD_BALL_CTRL' to influence the global rotation of the RV_ball in any way (kind of a long story this one... feel free to ask). So we need to UNDO the global rotation that is being done to the RV_ball as a result of the FWD_BALL_CTRL being rotated. To undo this, i.e. to maintain the global rotation of the RV_ball as we rotate the FWD_BALL_CTRL, why not just take the local FWD_BALL_CTRL rotation that caused the RV_ball to rotate in the first place, and pass the negative of that into the local RV_ball rotation, right?
That is a perfectly valid idea, and it SHOULD work! But... depending on how you do this 'passing the negative of fwd into RV', it will either work or wont. There are probably at least 2 reasons why it doesnt just simply work, so more than 1 really. But let's just focus on what I think Kevin is targeting. The local rotations of the 2 controls are NOT necessarily globally equal. For your local rotations to correspond to the same kind of global movement, you gotta have equivalent parents or something. FWD_BALL_CTRL is parented to FWD_FOOT_CTRL. RV_ball is parented to... guess who? RV_TOES! 2 completely different parents in completely different places, and we dont even know if their axes align perfectly. This basically means that you need some other way to figure out what a local rotation of X degrees in FWD_BALL_CTRL corresponds to in terms of local rotation of RV_ball... Or to put it even better (remember what we want is for the RV_Ball to sit perfectly still during FWD_BALL_CTRL rotations: You need to figure out the local rotations for RV_ball that are equivalent to IT GLOBALLY SITTING STILL :) If only we had some child of RV_Ball and made him sit globally perfectly still during FK, cuz the locality of that child relative to its parent would tell us what local rotations we'd need to do on RV_ball in order to get it back to where it was. Well, having such a child on RV_ball itself may be problematic, and besides, dont forget that we need an opposite rotation relative to the FWD_BALL_CTRL.
So to do this properly, you need to create a sibling for RV_Ball, a sibling who will act the same way as the RV_Ball. Then you also create a child for this sibling. Remember, the sibling is an exact doppelganger of the RV_ball, always equivalent to it, globally. You need to make the child of this sibling not move at all during the FWD_BALL_CTRL rotations. If you can somehow do this, the local rotation between that child and its parent will be equal to what 'globally sitting still' corresponds to in terms of local rotations in the world of the RV_ball. If you 'rotationally constrain' the child to the foot bone, who remember, won't get rotated during FWD_BALL_CTRL rotations, you'll have your child sit perfectly still during FWD_BALL_CTRL rotations. The local rotations on this child, are exactly the local rotations that'll make the RV_ball go back to its rotation before the 'project to new parent' rotated it. These local rotations are also already opposite sign, because during the FWD_BALL_CTRL rotation, it's not the child that rotates, but rather it's parent rotating and the child sitting still. This kinda thing almost always if not always gives the child local rotations of the opposite sign as the rotation.
Kevin keeps hitting multiple birds with one stone :D It's not as simple as it looks... Oh , I found that you can also do 'Take local rotation of FWD_BALL_CTRL as a quaternion, take its inverse, and pass that into the local transform of RV_ball_ctrl'. This does the job fine, no need to create extra nulls. When this DOESNT work, is if you use 'get control rotation' and 'set control rotation'... It all has to do with one doing sequential rotations and the other just 'setting' rotations.
What an amazing write Andy. Thank you for taking time to share all this. I think I have also learned a lot more since making this video about the use of World vs global (rig) space and am actually actively working on this entire setup to solve a lingering issue with sequencer. Its possible we may re-work this. Either way, what an awesome explanation and it sounds like you have this all dialed in. Thanks for watching and commenting.
You guys are just fantastic, I'm so happy I stumbled onto this channel and this series in particular. Thank you so so much and keep doing what you're doing!
Welcome to the channel. I have a few more Control Rig videos coming, just need to finish off the edits. Thanks for dropping comments
Kevin you are the #1 , thanks a LOT for this serie, I really appreciate it. Im from Argentina
Welcome Argentina!! Thanks for watching
You did such a wonderful thing. In blender rigify there are "IK to FK" or "FK to IK" button and you have to press if you want to align IK or FK, but it can't follow continuously like in this video. In Unreal Engine 5.4, I had to not convert Local Space to Global Space at 37.50 and I had to add Rotation Constraint to the end of both FK and IK sequence. After success, I achieved the same effect in TOE REVERSE CONTROL by continuing with a very similar logic. Before editing the graph editor for TOE REVERSE CONTROL, it started to rotate like CR_Mannequin_Body. Thank you.
You're welcome!
Would you happen to have an idea why this seems to work in the control rig editor but not inside of a level sequencer? That's what I'm seeing on my end :o Either way really really cool stuff!
I have noticed a similar issue. I'm still working out what might be going on and for the immediate term have disabled switching and just work FK or IK straight ahead. As we increase our CR learnings I'm thinking we will either get some help from Epic with a bug or perhaps figure out where the flaw is in our setup.
@@livinfreestyle6727 Found how to go about this I think. So on my end what I need to do is. Lets say I switch from FK to IK. I need to key the IK controls on the last frame I am in FK mode. And then key it on the frame of the switch to IK. Sounds like something that can be fixed in the CR with an extra function. But wanted to share. Cheers!
@@ElectricBlobz man, thanks!! You are my saver!!!
@@ElectricBlobz mb I will try to find a solution for this inside graph and I'll back. But really thanks
@@valerakarpenko8079 yes that is next on my to do list as well :)
thank you so much, this is soooo useful to me. the IK FK switch is amazingggggg!!!! 🤟🤟🤩🤩Do you have a tutorial is taking about the rig character with lattice? like we did in maya. a cartoon eyes which is use lattice from a perfect circle and wrap it to oval shape or artistic shape and the eyelid, eyeball just need to rotate it. the lattice will do the deformation after the rig rotate the eye.
I saw their a tecktalk: ruclips.net/video/gWsY7BONTVQ/видео.html at 12:48 they used fake FFD to do the lattice things🤔
Found the one is called graph deformer and in ue5.4 it have lattice deformer is added. and also Unreal Offical sample > content Sample> animaiton deform is have the lattice sample to show how to do lattice in Unreal. they make a custom lattice rig, and rebuild the deformer logic in graph deformer(the sample is 5.3 which is not yet have lattice deformer can use at that moment)..
Thanks for the great detals to share and I wonder there has been already pole vector placement function? if not, can we simply handle the correct ideal location based on positions of three current bone transforms ( thigh, knee, foot ) using vector projection between vec(knee, tight) and vec(thigh,foot) tp support the FK2Ik match. If there are any updates, it would be awesome! Once again, thanks for great tutorials!
I believe there is a pole vector placement function you can take from the Control Rig that comes with the third person project for example, BUT then you wouldn't have learned why it works 🤣
@@livinfreestyle6727 For sure, yap it is great way to see how it works as good example and utilizing the vector math on bone transforms seems to be pretty stable result I can see in addition! Keep up with the great tutorials!!
Thank you, is this a similar method for IK/FK on an arm twist set up?
That would be something different. Your arm twist setup should work whether you are in IK or FK
Thank you for the tutorial. Do you know about the snapper tool which can "pin parts of your control rig to objects inside your game world"? This is used in the Valley of the Ancients sample.
There is a "Snapper" tool in the animation tools section. THis is used for aligning usually props or controls to something while animating. A bit different than an FK/IK snapping tool. Is that what you are talking about?
These control rig videos are fantastic! As someone who is still trying to get comfortable in Unreal all your video's have been super helpful and I really appreciate you sharing your knowledge. :)
Question,
I tried your set up here for getting FK controls snapping to the IK, seemed pretty straight forward and simple. It functioned when I set it up, but the Set Transform node for the control has a "note" warning that reads "setting transform of parent after setting child may lead to unexpected results".
Is that because the FK arm controls are parented under each other in the hierarchy?
Your controls seem to be set up similarly but you don't appear to get that same error so perhaps it's something else wrong in my set up.
The order matters. I'm pretty sure in some of the vids i even had the order wrong and figure it out later. All you have to do is switch it so the upper arm happens before the lower arm for example.
glad the vids are helpful. More coming
@@livinfreestyle6727 When you say "switch it" do you mean you just reordered the items in the array?
@@Nabreu85 I mean switch the order you are doing things. Like make sure that anything you do to the upper arm happens before you do anything to the lower arm in the execution order.
@@livinfreestyle6727 ah gotcha, thanks for the reply. :)
Hello! I managed to make it work in the control rig (no pop when I toggle the switch) but in the sequencer when I toggle the switch the leg pops back to the default position, how can I solve it? It seems that the sequencer is overriding the control rig values. I'm not using the reverse foot, only the FK/IK part. Thank you very much
I've actually heard reports of sequencer doing htis in multiple cases. I haven't seen or had a chance to trouble shoot it yet. I think there was a recent post in the discord that people just turned it off or selected to animate IK or FK only until we get some clarity around it
@@livinfreestyle6727 Actually I have tried and it happens also with the manny control rig, so maybe it's just me that I'm using the switch wrong
@@davideconsalvo3563 Yes, I've seen wierd things with Manny as well, but right now I just power through one way vs the other until I can figure out what is going on with control rig in these cases. Once I feel like I have a solid understanding we can ping some of our friends at Epic for clarification
HI Kevin!
Im following your series, Awesome work. I have followed the steps till 39 min and im facing issue with reverse foot snapping, as u say " ITS GOING BONKERS :P" rotating when switching IK-FK. I noticed there is a video jump around that time frame, anything of important in that jump then u do share. Hoping for solution. Thanks alot for the series.
just letting you know I saw this. I am hoping to get some time to look into it by this weekend (things are crazy right now) and will get back to you
@@livinfreestyle6727 NP :) I will be waiting. Meanwhile I will retry again and search for more material for the same. Thanks for replying!
ok. I don't see anything specific. So I would say the best thing would be to post your full Blueprint in discord forum-questions so we can take a look and see if we can find differences
@@livinfreestyle6727 Sound Good,Thank You!
This series has been invaluable to me as a newbie to Unreal Engine....do you think you'll cover how to make procedural walk cycles using this control rig? I'm struggling to find any in depth tutorials on how to do procedural walking in Unreal engine. There's only one and it glosses over it in 10 minutes
That's what I was thinking. Once we finish our control rig, we need to test it. Two different testing routes in my mind. Hand keyed animation and then I think it would be a fun project to setup a procedural walk for something like a spider
@@livinfreestyle6727 Yes please. Also if I may be so bold, procedural walk for humans. Because there's a lot more diversity in terms of personality and walking scenarios(i.e strafing,injured limp) that you can "animate with humans. Spiders are cool because it would teach people how to get the individual limbs to avoid each other and move in a consistent order
Im actually thinking motion matching might be a better fit here, but we shall see
@@livinfreestyle6727 I am but a humble student...you keep doing what you do Sir
great as always, it's crazy)
New control rig video coming this weekend. Thx for always dropping comments!
How would this work when keyframing the ik/fk controls when animating it in sequencer? Will it preserve the keyframe pose (let's say you already added keys for a pose and wanted to tweak it) or does the snapping override any keyed pose upon switching?
This is an awesome question. We have been discussing this very thing and you can setup keying, but it deserves a bit more of a deep dive which we will cover once we finish the advance leg. I have found that sometimes even the control rig out key stuff is finicky so until I have a definitive answer I'm manually setting keys or just choosing one or the other at shot start
Also looking for a solution to this! Working on switching from maya to ue and can't seem to get ik fk matching to work out :)
im guessing we'll be getting into this over the coming weeks. The test rig is almost ready
hello again. am i correct in my understanding that a forward solve cannot override itself? that is to say: if i set the controls to a bone in the forward solve (after the construction script), and then later set the bone to a control, or vice versa. this is called a cycle you said? cant be done? im really struggling because your videos are dense and full of useful knowledge, but it isn't a complete step by step for an entire control rig setup. i got the backward solve. i actually have everything including full body ik switching as well as independent limb ik switching. my problem is with the pelvis. i dont know how to programmatically gain the function of being able to move the fk pelvis bone down in order to make the knees bend. thats literally the last piece and then ill have a perfect control rig
on a side note, sir. far be it from me to sound ungrateful. what you have put together is truly amazing. my question is: do you have any interest, perhaps in a livestream, to do a full step by step procedural control rig creation? im interested in learning how you put together your refactor when you created functions for all of your code. i see you fast forwarded 5 hours. is there a way to condense that into one harmonious video? what are the odds of that happening?
All feedback is welcome. I default to it being constructive. You can't survive in film if you can't handle feedback. So don't worry, I don't default to ungrateful and try to use comments as a means to understand how to do it better next time etc. As far as the overall style, yes the idea is to teach the understanding so you can build the bridge to connect it all, but if the gaps are too far I need to adjust. SOOOOOO....two things. Which skeleton are you working with? If it's the unreal one and you simplify to just a single control for the COG and IK legs does it work as expect. 2. As far as the "putting it all together" We're getting there. I don't want to make that video too early before we've gotten all the understanding and also make sure I myself have a clue of what is going on. We have a spine and a quadruped leg video in the works and then I think it will be time to put it all together and maybe even have a chat with our friends at epic about some of the instabilities we are seeing.
I don't know if it works with simplified controls. I will have to try. I am using the ue5 Manny simple skeleton
TNX
your'e welcome!
From rom video 6 ive got about 12 controls the start of this video has an entire setup for every bone plus solvers???
ROM for me means...range of motion, so can you help me out and clarify this question
If I may suggest a potential improvement to the these tutorials, I think it would be easier to follow along if you expand the 'Item' pins on the nodes so I can see exactly which item you're working on? When they are collapsed, it's hard to trace what it is unless you click on the node. Thank you so much for these teaching materials
That sounds great. I'll do my best to remember this or at least call it out as to which one we are using. Thanks for letting me know this could be helpful
I apologize for the constant comments but, I just realized that the issue I was having exclusively with multiple axis rotations was stemming from the fact that THE GODDAMN ROTATIONS ARE APPLIED SEQUENTIALLY, i.e. when I pass a rotator with x:30 y:60 z:0 into a transform, the engine rotates the object along the X axis FIRST, and THEN wherever the Y axis ends up after that rotation, the rotation value on Y is applied to that NEW Y axis, not the original one... I was able to get rid of this unwanted effect by ditching quaternions and rotators altogether, and just using 'Set/Get Control Rotator'
oh wow....what a great call out. I'm going to have to watch out for this. Thanks for sharing!!!
Switching isn't working inside sequencer for some reason, I am tried different approaches, also a simpler setup with Parent constraints, but it never work with sequencer.
I just mentioned this in another comment, we’ve learned a lot about control rig and as soon as I finish the octa bot series we’re going to revisit this to see if we can figure out why this is an issue.
I think I missed something. I've been following these tutorials since the first and I don't remember making an L_ball_rv_ctrl_pose null. Is there are set of other tutorials that I'm missing?
have a time stamp and I can help track it down
I think we would have added that in the Foot Roll video....cuz that was the one where we wanted to be able to rotate it OR use the channel to drive it
@@livinfreestyle6727 oh sure, it's at 32:15.
@@livinfreestyle6727 I'm surprised I missed it. I follow along with the tutorials and take extensive notes so I can reflect on everything and replicate and review. I can give it another look
I might have missed something too, but let me double check
Day 8 of trying to get a seamless switch on my own after I got overwhelmed by your solution.... I've spent 12+ hours... Things work really well, as long as only 1 axis is rotated in both IK and FK.... I'm having the following issues:
If RV ball isnt rotated in IK, I can rotate FK ball in all 3 axes at once without any issues in the switching.
If RV ball has rotation in the z axis, I can rotate the FK ball in the z axis only without having issues.
I'm basically having problems with the x y axes.... WHY??? I even accounted for the axes of the foot and the ball being rotated. I fed the X values to the Y, even accounting for the signs...
I'll explain what I'm trying to do in a very visually descriptive way if anyone wants to read.
I'm thinking simple. First, at the very end of the IK pipeline, set the FK controls' transforms to those of the joints, globally. Then, whatever I manually do to the ball joint in FK, I need to make the FK pipeline set the RV controls to a state that would make the same exact shape of the foot.
I went about this slightly anecdotally (which is a bad practice, I know), but it should work, just bear with me.
I took the example of raising the toes by x degrees in FK, i.e. rotating the forward ball control. To get the same shape of foot from scratch but in IK, you would need to rotate the reverse ball by x degrees to get that bend in the fingers, but then doing this alone would lift up the heel of the foot, which we need to lower back down if we want to get the same shape of foot. To lower the heel, I just rotate the reverse foot by x (- or +, one of them) degrees. That gets the foot in the same exact shape, with the only thing missing being the 'position' of the foot (it'll be raised up a bit due to the rotation at the RV foot), which CAN be easily dealt with by just moving the entire reverse foot TO the foot bone, cuz that bone wont have moved when playing around with the forward ball control.
You also have to manually move the RV foot null (the one that controls IK) to where the foot bone is.
You also have to constantly retransform the sibling of the reverse ball, the one that is used constrain the rotation of the ball joint in IK. The rotation of the ball in IK needs to be constrained to not the initial rotation of the ball joint, but rather whatever it was last brought to in FK.
The first problem you're gonna run into is when you go into FK after having done a RV ball rotation in IK first. The rotation of the RV ball will put a local rotation on the forward ball control. (If anyone's wondering why this even happens, it is the result of a long chain of events. When you rotate the RV ball, you're rotating the RV foot null, i.e. the driver of the ankle. However, following basic IK, you're also constraining the rotation of the ball joint. So when you rotate the RV ball, you have the RV foot null making the foot joint rotate around the RV ball, but the ball joint retains its global rotation, i.e. it keeps perfectly still. Then at the end of IK, you set the forward foot ctrl to be the same as the foot joint, and the forward ball ctrl to be the same as the ball joint. The foot joint moves, the foot ctrl moves. But as the foot ctrl moves, which is the parent of the ball ctrl, the ball ctrl keeps still. This gives you a local rotation on the ball ctrl.... When your parent moves without you moving along, you get local transform...)
You must not feed this rotation into the RV foot during FK. Because when you transition into FK, you're supposed to not alter any of the RV controls DURING the transition, you need to alter them WHEN the forward ball control gets manually rotated during FK. If you feed the rotation of the forward ball control to the RV foot in this case, you'll end up rotating the RV foot as soon as you enter FK, which would be incorrect because the RV ball rotation in IK wouldnt rotate the RV foot, so you gotta keep it that way when you initially enter FK. The solution is to separate the rotation that comes from the IK pipeline and the one that is done during the FK pipeline. Create a ctrl sibling (a twin) for the forward ball ctrl, and set the initial transform to be the same as his brother, and just turn off the visual shape for this ctrl, we'll just use it to store an offset. When the RV ball is rotated, that actually makes the FK foot ctrl rotate around the ball joint, which is what really gives the direct children of the FK foot a local rotation. In this case, both brothers get the same local rotation. However, when you go into FK, you'll be rotating the forward ball control only, and not his brother. This will create an offset between the brothers. When it comes to the RV ball ctrl, you want to set the rotation of the RV ball ctrl to however much it was rotated during IK, PLUS however much the ball joint got rotated during FK, and this value corresponds to the forward ball ctrl :) But when it comes to RV foot ctrl, you want to rotate it only by how much the ball joint has been rotated during FK, because only the manual rotation of the forward ball control would required the RV foot to move. This value is hidden in the difference between the brothers... Forward ball ctrl - its win = how much forward ball ctrl has been manually rotated. You'll also have to add some nodes in the IK pipeline in order to make the twin rotate (or rather, not rotate :)) alongside the forward ball ctrl. Forward ball ctrl is being set to the ball joint during IK, and that's why it globally remains unrotated during IK, however there is nothing that would make the twin have the same thing going on. Somewhere in IK, you gotta make the twin act the same way as the forward ball ctrl does during IK. It's not hard to do, should suffice to say that you just create a new ctrl that will always be equal to the offset between the two brothers, then in IK you set the rotation of the twin to that of its brother, i.e. making them equal, but then you do set relative rotation on the twin and you rotate it by the offset.
So basically, do these:
Create a twin ctrl of the forward ball ctrl
Create a new control named 'offset_ctrl' under the twin. We'll just use this to store some value.
Keep in mind the name of the null that the ball joint's rotation is constrained to during IK, you'll have to update this null during FK. Let's call this guy RV_ball_clone
// Inside IK:
After the 'rotational constraint' following Basic IK, set the local transform of the twin to that of his brother.
// Now set these in FK:
Global rotation of the ball joint = Global rotation of the forward ball ctrl // This is what we do by default
Rotation of the RV foot = rotation of the forward ball ctrl - rotation of the twin (i.e. the rotation that was created during IK) // This will set the RV foot in the correct rotation
Rotation of the RV ball = rotation of the forward ball ctrl // This will set the RV ball in the correct rotation
// The RV controls have been correctly set now in order to make the same shape of foot that FK would make. Now we need to move the whole RV foot to the correct position
Position of the RV foot = position of the foot bone
Global transform of the RV foot null = Global transform of the foot bone
Rotation of the 'offset_ctrl' = the rotational difference between the twin and his brother (deal the sign on your own) // We'll have to use this offset in IK
// Now Go back to IK, and after setting the local transform of the twin to that of his brother:
Relative rotation of the twin = local rotation of 'offset_ctrl'
Once you dive deeper, you'll realize that the axes of the ball ctrl and the RV foot ctrl are not the same... The local X axis of one of them corresponds to the Y axis of the other. This isnt a huge problem and can be easily dealt with. Just pass the rotation of X of one of them to the Y of the other, and make sure you're also keeping track of the signs. But AGAIN, problem persists.
@@AndyU96 what a write up. As soon as I finish the octa-bot procedural stuff I will come back and revisit this. There is a setup in the default control rig that comes with the third person default project, it also has built in FK/IK switch. Id like to see if we have this same type of problem in sequencer with the fk/Ik switch setup in that rig. My understanding of how the control rig state machine functions has increased considerably since we first recorded those videos and maybe we can see what might be going on. I’m super impressed with your never surrender perseverance.
Maybe i did something wrong but. Looping degradation, or a dependency loop is still present in this solution, the ball offset control and the Heel control throw the foot into a dependency loop, which renders the use of the reverse foot mechanism almost useless. Because at the end of the day, you have only one properly functioning control from the entire mechanism which is a ball reverse. Anyhow you gave a discretion at the start of the video that this is A solution, not THE solution. Hope that the advanced ik you've figured a way of solving this really annoying problem. Thank you
I think we did cover a solution for the built in looping (its in the default control rig from Epic). I went over the problem/demo'd it at the beginning of the vid. If you need help finding it let me know.
@@livinfreestyle6727 Hello Kevin and thanks for your reply. I might've spelled it a bit confusing, but I've followed your rig setup from the basic FK video. In this particular video you show at the end a proper snapping of the ik/fk but you do so only with Ball RV control, for which it works just fine, but if you will try to use the heel control, or the ball offset (ball offset in this setup you use for offsetting the toe rotation), you will get the same looping degradation behavior whenever you try to snap back and forth. Which defeats the purpose of reverse foot setup. I've had to cut this feature from my own character rig for that reason. But maybe I've missed something while building it, so if you have this exact setup saved somewhere and it works with all of the controls properly without breaking I would be happy to look at it. I've tried to fix that problem myself, but failed. Anyways, thank you so much for this series, i've learned a lot.
FK IK switch doesn't present degredation for me *until* you try to use the foot roll animation channel after following all the tutorials up to this point. So it seems you'll be locked in to the control-based workflow if you want to avoid that for now given the current knowledge.
Yeah, and part of the foot roll was to demo the use of attributes. In general the teams I work with prefer the actual controls so we will be removing that in the final rig (I'll make sure I call it out) and we will have to do some performance testing on all of this for sure. We're also going to separate it out to be a "Limb" and a Foot so that we can use the limb for the Arm. I'm still scrambling to catch up with everything in 5.4 to figure out how to best get the info to you all.
Why do you do the snap on every frames?
Wouldn't it be extremely costly to maintain that logic for every frame, every limb, and every character in the game?
So, you technically don't have to. And in traditional tooling like Maya you only snap when you need to, but in this case this is setup much like the default control rigs that come with third person. I was blown away that it was even possible. That said, one outstanding question and a thought, that we will answer once we finish our rig.
-What happens to the animation curves as your switching back and forth. (I can mitigate this in my own workflow by selecting one way before each shot for example so I'm not worried about having the answer right now)
-If we find that live snapping is problematic or doesn't make sense it's very easy to flip it to a tool instead for example. The logic is done
also one other note, I'm going to do an advance leg that will definitively solve the knee offset problem for any pose and we will update our snapping code in that tutorial
I just re-read this. One more thought. This control rig or at least the snapping is one that I would use for Animating. Not for in engine solves. Generally speaking (and per Epic) the control rigs you use at run time should be as simple as possible. This however is meant for asset authoring and I'm not really thinking of runtime case right now
@@livinfreestyle6727 thanks for the clarification
On my side i use the control rig mostly for the deformer rig (twist, corrective joint.....)
Your serie gave me a lot of ideas to test some pipelines with the animators, even if in the current state i don t think the anim in unreal is production ready
I'm at the 14th minute and I just cant help but think... If the issue of snapping stems from the difference in the reported transforms of the bones by FK and IK, why not just save all the transform information in some variables and pass that info to whatever control method is being switched to? Let's see what I'm missing here...
Edit: Alright seems that my thinking was right, but instead of storing the info in some variable, you just grab the info and immediately feed it into the FK controls. But then I'm still only at the 19th minute...
Edit 2: Alright alright, IK to FK is easy, but the inverse is harder... Because obviously, we had this pole vector that told the IK solver the plane to move the bend the bones along, but if the user does FK control and rotates the bones in a way that they arent bent along a single plane anymore, then the switch to IK will result in a snap... But the solution should be simple! Just calculate the shortest set of rotations for the bones that'll make them aligned on a single plane, rotate them as such, and feed that plane as the new forwards vector for the IK solver :D No? Let's see...
Such a great progression in your comments/thinking. YES...but not really. The problem is you can pose the the FK joints in a way that uses "twist" and the IK solver can't solve for that. So we do go over a solve for this in the advance vid. Also, worth noting that right now i"m not using FK/IK switching. I'm just using one or the other because i"ve noticed some strange things that I'm trying to narrow down as far as what control rig is doing.
The inverse world matrix A * world matrix B = local matrix to decompose the local eular rotation value so I assume, can we simply capture the reverse offset value by inv w mat B * w mat Z ? ruclips.net/video/MdjDkGNR6aM/видео.html
Maybe. When you say it like that I remember basic matrix stuff and it does seem like the inv world A & world B would be The item in the local space of B...Have you tried it? Next time I'm working on matrixy stuff I'll try it. Thanks for the ideas!
@@livinfreestyle6727 thanks for all the inspiring works!
@@hyunseungkim538 👍