Animating with Control Rig in 4.26 | Inside Unreal

AMANDA: Hey, folks! Venture to new heights in style with February's free Marketplace content including customizable characters, a diverse set of environments, and animations befitting a boss. Download all of this month's free content from the Unreal Engine Marketplace before it's gone. The 4.26.1 hotfix is now available for download on the Epic Games launcher and GitHub--head to the forums to see all the latest fixes from our devs. Or if you've been causing chaos with the Unreal Engine 4.26-Chaos Preview build, then you've got an update as well! 4.26-Chaos Preview 2 is also available on the Epic Games launcher! This series of builds enables Chaos as the default physics system, so try it out and share your feedback with us in the forums. Following last year's report, Epic and Burning Glass have broadened the scope of their research into the demand for 3D graphics and real-time 3D skills around the globe--and it's booming! Dig into the report on our feed and find out why real-time skills are providing serious advantages if you're entering the workspace or looking to advance your career. Optimized for Xbox Series X, Lovecraftian-mystery Call of the Sea from new Spanish studio Out of the Blue has made a real splash. Pop over to our interview with one of their co-founders, Tatiana Delgado, to uncover the secrets of its intriguing world, gorgeous stylized visuals, and challenging puzzles. New to Twinmotion, the brand-new Twinmotion Importer enables you to export your projects from the versatile visualization application to Unreal Engine. Explore how the tool opens up development options for architecture firms--and why it's the latest milestone on the road to a fully open and flexible AEC pipeline. Then watch our latest webinar on YouTube to see the new workflow in action. While you're checking out our webinars on YouTube, learn how to easily optimize CAD assets for real-time rendering using Visual Dataprep--the webinar demonstrates how to avoid repetitive manual data prep processes by easily creating "recipes" that import data to predefined parameters automatically. In the most recent article in the XRLO, or eXtended Reality Lowdown, series REWIND shares how they're populating real-time worlds with thousands of animated characters using instanced static meshes to render animated characters. Check out their full series on Medium and keep an eye out for their frequent dev articles. You may remember our spotlight on Rider for Unreal Engine by JetBrains, an IDE for both Windows C development and Blueprints. With plans to release later this year, they're hosting a UX study--if you'd like to help them out, they're offering a product subscription or gift card for feedback from qualified responders. And with 350 submissions and over 2000 participants, the 2020 Epic MegaJam showcased the overwhelming talent and drive of the community. From wild west duels of wit and unending paperwork, to infinite pizzas and claymation worlds, jammers created a myriad of games with a range of genres, art styles, and whimsy. Visit the Epic MegaJam Itch.io page to play through and experience their completed creations. And now to celebrate this week's top karma earners. A shout-out to: ClockworkOcean, Detach789, Everynone, T_Sumisaki, chrudimer, GrimStarGames ugmoe, pseudocheesy, SteelWoolAnthony, and Thoeme. This week's spotlights are dedicated to our phenomenal 2020 Epic MegaJam winners. Wispy Bois took first place with their mysterious adventure Forfax's Castle. You'll make your way through a dark, cold rain towards the castle in search of answers and meaning. In second place, Eons Unfolding from Team Sartial is a well-built strategy survival game where you work to evolve from the tiniest of microorganisms to full-grown animals. And in third, The Rude, the Mad, & the Ugly by the Five Fancy Mustachios. Take on the role of a man returning to a small town in the old West with some scores to settle - after all, it's been a long time, but we're not done yet. Thanks for watching this week's News and Community Spotlight. VICTOR: Hi, everyone and welcome to Inside Unreal, a weekly show where we learn, explore, and celebrate everything Unreal. I'm your host, Victor Brodin, and with me today I have Helge Mathee, senior engine programmer. HELGE: Hello. VICTOR: Hello, hello. Jeremiah Grant, technical product manager. JEREMIAH: Hello, hello. VICTOR: And last but not least, Greg Richardson, product specialist. Welcome all to the show. Today we're going to talk a little bit about animating with Control Rig. And I'm not going to do much of the talking, so I will hand it over to Jeremiah. JEREMIAH: Hey, everybody. We're going to be talking about animating with Control Rig in Unreal 4.26. 4.26 has brought a lot of things with Control Rig and its integration with Sequencer. And we really want to dive into that and show you guys some of the features and capabilities. So quick agenda for today. We've kind of packed it full with a lot of things. First thing, we're just going to give a quick intro to what Control Rig is. And then we're going to talk about the new sample update that we released just a couple of weeks ago. And then we're going to dive into some little gameplay demos of the Rig Sharing, attaching Control Rigs to other rigs, a slope warping demo-- it's a runtime example-- a robot attacking gameplay example, and then we'll cap it off with this Meerkat Virtual Production demo that was just released recently, which we actually see here sitting over on the right. So first off, what the heck is Control Rig? Control Rig is a plugin for Unreal that allows you to create animation rigs, runtime rigs, procedural animation, and allow you to interact with it in a bunch of different ways. So you can build animation rigs. You can expose its controls for animation. You can use a variety of ways to create procedural animation and drive them at runtime or in Sequencer. And then you can write your own Python scripts to automate your workflows and really customize your process for your own specific production. By the way, Control Rig plugin by default is turned off. So everything going forward, we're going to assume that you want to turn on that Control Rig. Just go to your plugins. Search for Control Rig. And it'll be available to you-- you'll be able to create a Control Rig asset. And in there, you'll see a full graph that we'll dive into here in a little bit. And so let's dive into a quick example, the mannequin rig demo. We released one for 4.25 that had a basic rig. In fact, I think this is the rig we see here on this slide. And in 4.26, we've done quite a few changes to it. And let me demonstrate that. All right. So before I go into the rig itself, when you open up the project, you should see something like this. Here we have two mannequins in this scene. Here we can see a Control Rig on our guy on the left. And we have Sequencer open that can drag through and we have a pretty awesome animation here that is created by Ray Arnett, one of our animators here at Epic. One of the cool things in this sequence is how the previous one is just Manny waving at the screen. We have two characters now not only playing in Sequencer and animating, but also being animated in context of this environment. So we have the table moving and reacting, the statue, the chairs, and the mannequins actually sitting in those chairs and jumping in. If you were to go into something like Maya you'd have to bring those chairs into Maya, adjust your character, and then go back to Unreal. But here you're able to just do it all in one place. Also you could just see, if you open up this sequence, it's level sequence, you'll see there's chair tracks, which have some curves in them. The two mannequin tracks, feel free to jump in and take a look at them. And we can always look into our Curve Editor and adjust our curves there, as well. So you have a variety of ways of interacting with your animation. And let me talk a little bit about this project that's available. I do have some demo content in here for later. Those things are not included in the project. But the core things that are is everything that's under this Control Rig folder. There's going to be a Blueprint, which just has a tutorial. We've received some questions in the past. Hey, there's nothing in this tutorial. It doesn't do anything when I open it. There's no text. That's absolutely true, except for the fact that it does do something. There's just no tutorial text. Whenever you run this, it's going to automatically load this level sequence. And we make it so that whenever you open this project, it will autoload that level sequence for you, so you are already prepared to start playing around in Sequencer. So that's the purpose that it serves. It just gives us a way to load that asset whenever this project is opened. And then we have just our generic level assets that we see here, the chair and the props and our mannequin. In addition to the core anim set that we have included here, I want to talk about another thing. We have added in the female mannequin Control Rig, which is the same as the original mannequin Control Rig. And so we have a skeletal mesh for both of those, as well, as physical assets. They both use the same skeleton. And then we have our map, this map that we have loaded here by default, and then our level sequence. I'm going to jump into Control Rig here and dive into some of the changes, both in Control Rig itself and in the changes it made to this rig available to everybody. So we designed this rig kind of in a specific way to make it accessible and digestible for people new to Control Rig. I know it looks pretty complicated right here. But we structured it in a very specific order. First we just have the forward solve. Actually, before we even get to that, let me describe this editor for people who are new. This is our Control Rig editor. We have our viewport here at the top left. We have a rig hierarchy, execution stack, and a My Blueprint editor here in the lower left. And then we have our main rig graph. This rig graph is where we're going to construct everything we need to drive bones or controls, to generate procedural motion, interact with our environment. And we'll see a lot of ways that we can do that later on today. So a couple of changes in 4.26. We've renamed a couple of things because we've added a lot of functionality and these names kind of help us address that. So one of the things in 4.25, the core node that you'd start out with was called Update Event. We've changed it to Forward Solve. We changed it to Forward Solve because we've added another event called Backward Solve. Forward Solve is what allows you to drive your bones with controls. So when I move the control, the bone moves. When I move the control on an arm, it may move an entire IK effect here. And Backward Solve lets me do that kind of inversely. So we call it an inversion graph or a backwards solve graph. And that's going to let you-- it's kind of like a bake mocap to controls. So you can get the animation that's on your character and apply it back to the controls and then continue modifying your animation with your Control Rig. So this is great for bringing in mocap. But you want to clean it up using a Control Rig. You want to tweak the arms without having to deal with just FK. And we'll show some examples of that here in a few minutes. And here at the top, you can see we have our Forward Solve. And if I just click on the arrow next to it, we have a setup event, which is also note 4.26. We'll talk about that after this-- Forward Solve, which we're seeing right here, and Backward Solve, which we won't really see any change. One key change-- I'm going to zoom out, and I apologize for big graph here. But we see this is our Forward Solve and this is our Backward Solve graph. Both are represented as graphs. So you have complete control over how your rig is driven by motion or how your rig drives motion. And as I change this between Forward Solve and Backward Solve, you can see the highlighting of the lines showing you which graph is being run. When you're handling motion as an animator, you don't really need to worry about this so much. The Forward Solve is supposed to be being run, for the most parts, and you won't really be in this Control Rig editor. You'll be in Sequencer. Or you'll have a Control Rig node in your anim Blueprint that's going to be doing some sort of corrective motion. And the Backward Solve, I'll show you how that can be run here shortly in Sequencer. All right, so let's dive into some changes with this specific Control Rig with the mannequin updates. So in addition to adding some behaviors, renaming and updating these nodes, we've adjusted the hierarchy. This does mean that, by default, if you're creating animation on our experimental version of this Control Rig on 4.25, these control names have changed so that motion will come through. But I'll show you how to get around that here. These control names have changed to represent the bone names as more natural, root_control. The bone's name is root and if you want the control, it's going to be the name of the bone plus underscore control. It's very easy to map between these. We've also added in some finger controls. And in this case, we decided to put it in the hierarchy, just to show you guys a different way of building hierarchies and driving them with your rig. In this case, we have a hand space. And that's carrying all the fingers along with it. And we've also added in twist controls. In order to fully represent Backward Solve, we needed to have the entire rig represented. Additionally, if you look at this hierarchy, it's much cleaner than it was previously. And that's because we no longer have the need of having a space in which we need to control. We can represent this offset of the control in the world directly on the control as an offset transform. So this transform represents where it is in space. And the initial and current transforms represent its animated positions or starting positions. So in this case, this initial position is 0, 0, 0 relative to this offset transform. This is more of a rig setup thing, not something you really need to concern yourself with if you're just trying to interact and animate with this in Sequencer. Another thing to note, if you were to open up the 4.25 Control Rig version of this, which will be fully compatible and you'll be able to open it. But you will see deprecated flag under a majority of these nodes. That's because we've done kind of a low level restructuring of how we're handling data. And as a quick example, let's take a look at this Get Transform node. So instead of getting the control transform or having a bone to get the transform of a control or a node to get the transform of a bone, we have one node now that takes a type of item, an item I could quickly choose which type I want to get to transform for. And then I can choose the name. And additionally, we have a checkbox to choose whether that's the initial transform or it's-- or its current transform. So that took about nine different nodes and consolidated it down into a single node that's multipurpose and much more flexible. And our set transforms are the same way. Here it's taking an item type. And I'm able to feed in a transform. And again, I can choose whether that's initial or not. I could propagate the children. So I have all the same options that I had before, just in one node instead of a bunch of nodes. And that really-- one of the things that, as a control room team we've focused on is kind of reducing the mental load as you're going through. You don't have to remember as many different nodes types and as many different ways of doing things. You're able to just duplicate things and work as quickly as possible. All right. So going through this, we have our root pelvis, which just makes it so when I move this control, my character moves. By the way, there, by pressing Control G, that resets my control to its initial position. Control Shift G will reset all controls in your Control Rig to your position. Super handy hot key there. So these top three, all I'm doing is I'm getting the transform of my control and setting my bone to that transform, very much like a constraint. And I'm doing that for this whole-- from root all the way up to head. And then we go into some arm logic. Our arm logic, we add a little bit of complexity, because now, in addition to setting or clavicles, we're also introducing basic IK. A basic IK previously only took in bones, but we refactored it to use items. So now you can actually do IK across controls, if you wanted to. In this case, we're still just using bones. We're using our upper, lower, and hand bones and feeding in a control our left hand, in this case. And just a quick tip, I can right click on this control and I can select rig elements. And that will quickly select my control here in the viewport. You're trying to get to that without scrolling through your hierarchy. And then we have some twist bones here. Instead of sending a full transform, we're going to go ahead and just set rotation. So we're just representing different ways you can drive controls. You don't always have to drive with a transform. We have a lot of different ways of driving. We do the same thing for the right arm. Left leg, we add, again, a little bit more complexity. And like I mentioned before, I wanted to give people a way to read through this graph and slowly build their knowledge and complexity as they go through it. So in this case, we've added a little bit of a foot rule situation here. So I can grab the toe or grab the ball of the foot and interact with those here. So here we got a little thing-- oh, let me turn off snapping. Turn you guys off. All right. And again, basic IK, the same thing that we had on the arm. Then here's my foot rule set up where I'm taking my toe pivots and rotating it relative to the ball control. And then our effect list, thigh twists. Thigh twists and calf twists. And once more, in this case, we did slightly different between the left leg and the right leg because we wanted to introduce a new node. There's a node called projected new parents. And a great way to think about this is a parent constraint with the maintain offset. You can control the transfer of one object relative to another object, all with one node instead of building the actual make relative and multiply that we're doing up here. So this is this logic consolidated into a single node. And we've built it this way just so you can follow the logic of how we're slowly consolidating nodes when we're doing repeatable logic. All right. Next I want to talk about something that the items refactor that we did has enabled. And this we're calling collections. And part of collections is the ability to loop through. So we can create a collection of things. In this case, I have a collection of all of the fingers on the hand. I just get all the children of my left hand recursively. So I get all the fingers and I can loop through them and perform some sort of action. Additionally, I'd be able to loop through and read the names of each one and get the left and right. So I don't have to build a big graph. I can do it all at once using unions, concats, and other string operators they may be used to in other places. We have some pretty cool options here in this foreach loop. Not only are we uploading the item, but we can upload the type and the name of the object, which is kind of our core item struct. You can also get the array index, the number of items in your collection, or the ratio. And ratio gives you a 0 to 1 position of where you are in this loop. So you can do some pretty cool things with mapping the position of where you are in your array to some sort of procedural motion or interpolation. So in this case, I am getting all of the bones in the left hands. And I'm going to go ahead and get a collection of all of them on the right hand, too, just using this replace items. And I'm going to combine those two collections, loop through all of them, and get their associated control just using this concat. And very quickly, I'm able to get the control transform for each finger and set the rotation for each finger bone. In addition, we added a new node here called Set Control Visibility so you can turn on and off the controls based off of a Boolean control. In fact, let me go ahead and demonstrate that real quick. I'm just going to right click and Select Rig Elements. And here we have a control that, instead of being a type of transform is a type Bool. And that allows me to very quickly create what people may associate with an attribute or a parameter on a control. In this case, it's just a Boolean. And it may be hard to see. Let me zoom in on the hand a little bit better. There we go. And so as I toggle this, all this looping is setting the visibility for all of those controls with a very small graph. HELGE: Hey, Jeremiah, just one thing to note here, which I think can be interesting. Now that these nodes don't operate only on one piece of data, but they're actually looping, so there's multiple iterations and lots of things are affected, people can also see that by watching the value. So if you were to right click on the A pin on the concat node, for example-- not this one, sorry. On the concat, like the one above, just to watch this value, so this now shows you-- usually you only see one value here, which is the value that's flowing through. And here you can now see all the values that this is affecting. So as expected, you're going to see all the pieces for the fingers that you're changing. JEREMIAH: Yeah, that's a great point. Oops. Good. Yeah, so it's a great way to quickly debug your array. A common thing that we've seen when people play with this, in fact, is they often, after this foreach, you go to the end of your graph and you do some sort of behavior-- like, let's say, create another foreach. And you do some sort of behavior here. And they're wondering why their graph is taking so long to run. And it's because it's looping through for every element of this and then looping through every element instead of doing the-- after the loop's completed is kind of the logic they're going for. And the way that we've been able to discover that, quite often, is we just right click and watch all the items that you get this massive list of 1,000 items. Like, oh, you're looking and then looping and then looping instead of going through the completed. This is a great call out. We do the exact same thing again with the twist visibility. And in this case, instead of doing a-- generating a collection from the children or something, we're doing a preset of items. In this case, you just go to item, items, and you can start adding elements to it and populating it yourself. In this case [INAUDIBLE]. GREG: Something I want to add in here in terms of the items, if you have any sort of items that you have selected in the rig hierarchy, you can just track over to your rig graph and it will automatically create your items there for you, as well. JEREMIAH: Yeah, exactly. And that's what it's going to show real quick. So in this case, I can grab these. And I can-- sorry, drag up here and say, create collection. There we go. So now I have a collection of just those selected controls. And additionally, another way that we can do this is I can right click and go to Collections and Item Name Search. And so in this case, I could just say twist. And to make sure that I'm only getting controls, I can choose type to search control. And I should have the exact same behavior that this would do, but dynamically. So just a couple of different ways to create collections. You can do some really cool things with this. I highly recommend you guys take a look at it and see what you can do. HELGE: I mean, the main difference being that if you use the name list, just reiterating what you just said, if you say you have a creature with six fingers, then this particular approach wouldn't scale. But if you use a search, which is another collection, then you-- depending on how you set it up. So there's downsides to this, as well, of course. So if you wanted only three fingers, then you know, but you can combine these search operations with saying something like, give me all the fingers on the left side except for the first three or something like that, right, so you have a bunch of different ways of doing this. The other thing, if you don't mind me nerding out for a second, is the foreach. The way that all the loops work in Control Rig is actually visible to the user. So if you wanted to debug something like this a bit more, you can actually look at the execution stack. So if you were to open up the execution stack and then select the for each loop in the graph-- not there, sorry. In the graph. So just click on the node. Yeah. And then you just scroll in the execution stack to see which one it is. So there-- it's a bit hard to read here-- but you can basically see what's going on there is a collection loop. And then there's actually jump instructions that are telling you now we're jumping forward or backwards. And then there is a block. It says this is the stuff that's happening within the loop, and so on. So you can actually see what the VM is doing when it's running. So you can get down to all the instructions that the VM is actually operating on. So we're sort of giving away some of the functionality in how the VM is implemented here by showing you the actual sort of lowest level of operations that we're applying when we want to use loops and branches and stuff like that. JEREMIAH: And that's something I didn't call out when I went over this editor release, these three panels. So rig hierarchy, we've been working in that. We've been selecting controls, bones, and spaces through this rig hierarchy. The execution stack, this is-- and this is kind of a big difference in the way that Control Rig is developed versus other systems. Everything's executed in a stack linearly so we can do some sort of behavior that would generally be cyclical in something like Maya. But here you can move a control and then set position for control and then do some sort of procedural motion, then run an IKM that controlled all on a tick. And as you click through here-- well, as we saw here-- as I click through, you can see that it's actually selecting the nodes. So you can click through and see, oh wait, why is this value coming at the wrong place? And click through this and help debug some trickier issues that you may run across. HELGE: Can you do me a favor and just zoom back and just show the first couple of things that you're doing on the root, like just the nodes on the top? I know I'm sort of destroying your flow going through the rig panel. JEREMIAH: Oh, no. HELGE: If you go to the top and just sort of click on this and just press down on the keyboard-- that's what I usually do when I debug. So you just press down and you're going to see, what it's showing you is basically, what are the things that are happening in which order? And that can be quite interesting sometimes, especially if you have branches where you might not be expecting a jump or stuff like that. You'll be able to see what's happening here. JEREMIAH: Right. Yeah. HELGE: The other thing that the execution stack is doing is actually showing you errors, as well. So if you have an error like, I don't know, you have a node that as an invalid item set in it, right, you'll see the error in this list. And then you can right click the execution, like the instruction, and say, show me the node where this error is coming from. This can be quite interesting for large graphs where you might not be able to find the error because, I don't know, because you didn't build the graph yourself. Like, as a good example, you get a large rig from someone and there's an error in it. And the execution stack can be very useful to find things. JEREMIAH: Yeah. All right, so now that I've kind of gone through the big changes that we have in this Forward Solve, I'm going to go through the Backward Solve pretty quickly. It's a smaller graph, as you can see, because we're not going to be doing operations like IK, necessarily, here. But you can. You don't necessarily have to. VICTOR: Jeremiah, could you quickly describe the difference between Forward and Backward Solve? JEREMIAH: Yeah, absolutely. In fact, let me demonstrate it. In this case, I have my mannequin here. And as I move these controls around, my character responds. So this is running the Forward Solve. This is saying, whenever I move this control, my bones go along for the ride. My IK solves, et cetera. But if I go to Backward Solve and I move this control around-- in fact, I can't even move this control. And that's because this very first thing is saying, get the transform of my bone and set my control to the transform of my bone. So it's the exact opposite. And let me show you what that allows me to do. I'm going to go to my animation of my previous scene settings here and go to my preview controller. And use a specific animation-- use my favorite, stand to prone. Now, what we just saw is me playing an anim sequence, a skeletal anim sequence, on my Control Rig and all of my controls solving to where they need to be in order to represent that pose. And so before I dive into this graph, let me just show this one more time. Let me go ahead and just clear this out as default. Let me show this one more time. And I'm going to show this in sequence. That's really where the power is. I'm going to grab my mannequin here. Just going to drag it in. It's going to create a quick level sequence. And we'll drag my mannequin in here and add an animal. We also added some things there. So I'll show that later. All right, so now I have my stand to prone animation. I went through that pretty quick. But all I did is I dragged my mannequin into my level, created a level sequence, and added my mannequin-- skull to mesh to my level sequence. And then I added my stand to prone anim sequence to that character in Sequencer. In fact, just to show you one more time-- this is the animation that I'm playing. This comes with our-- I think with our default animation on our character. So-- HELGE: Just to clarify, Jeremiah-- I know you've said this already, but just for the people who are not familiar with the system-- there's no rig here, right? There's no rig. We just have bones and FK animation right now. JEREMIAH: Yeah, exactly. And so this is just FK animation on the skeleton. In fact, if I expand this animation, all we have is a weight. So you can't really do much with that. And then I can right click on my actor and I can say bake to Control Rig. And this is going to give me a bunch of options. I'm going to choose the Control Rig we were just looking at, so mannequin Control Rig. It gives me a quick option. Do I want to reduce keys or not? In this case, I'll just leave it one to one. So I'm going to make this-- bam, it's done. So now I have my animation on my controls. And I can now interact with my animation. And so we get directly here with the Control Rig. I can even go into-- let me grab my pelvis here, full control. There we go. And go into my Graph Editor. And let's see what I'm looking at here. Oh, that's not what I wanted. I wanted body control. There we go. All right, so I can now grab my curves, and they feel like this. There we go. That is exactly what I wanted. So now he lays in a puddle. Sure. So this means that I can do things like bring in motion capture directly into the engine, bake that directly onto Control Rig, and now manipulate with higher level functions like IK or any number of other controls that we have available in Control Rig. This is a really powerful thing, and probably one of the things I'm most excited about. It gives a lot of power to virtual production artist, motion capture animators who may want to do a quick fix, for example, on their animation without having to go back to Maya or Blender. And you can just make that fix here in the engine. HELGE: So just to reiterate where this came from, which is the question from Victor, is difference being forward and backward. So to me, the way I always describe it is, forward is solving from control animation onto FK, so from controls that you animated to the FK pose. So if you play it back in Sequencer, that's what's running. When you play it back in Sequencer and you have control animation, we solve from those controls onto the pose. And then that's what you're seeing in the Skeletal Mesh. Backwards is the opposite. It's when you already have bone animation in the skeleton but you don't know where the controls are supposed to be. You can run it the other way. And basically, when Jeremiah was saying bake to Control Rig, really what's happening is, we're playing back the whole FK animation, right? We're doing the same thing. We're just playing it very quickly without you seeing it, running the backward solve for every frame, and then sort of recording where the controls were. And that's what you're going to get as curves. Does that make sense? JEREMIAH: Yeah. And that's exactly right. We did add the ability for you to reduce keys. I saw the dialogue popped up. And that's a post-process. That's not sampling when to capture this backwards solve per frame. So this backwards solve graph is pretty straightforward. This is something that a rigger would set up when they created Control Rig for an animator. They create a forward solve and backward solve in order to have this behavior. We provide one for you here with this mannequin Control Rig. And this will be available for you to take and apply to any animation you may have on your mannequin in your own projects. So looking at this, the graph is very consistent. We are using this new projected parent here on the root control, basically saying, get the position of my root, wherever it is, and move my root control to that location. Same thing for the body control. In this case, we have the pelvis, and we want to move both the body and the pelvis control at the same time. And at the end of day. We're just stepping through each one of these and doing this behavior. We absolutely could have done this as a for loop and gone through all of the controls and just connected them with the bones. But this way, you're able to open up and just see exactly how it's going, trying to be as transparent and as easy for you to read as possible. HELGE: So I mean, you can build all this stuff without looping, right? So I just want to reiterate that looping can be maybe a bit intimidating at first because it's sort of the next level up in terms of building a graph and abstraction and so on. So it's perfectly fine for you to just build it with single nodes. And then as you encounter repetitive patterns, as you notice, oh, I'm doing this five times, you can start thinking about introducing looping. And as this is a learning example, we just haven't collapsed everything into one single big loop. That wouldn't have made sense, right? But we could. You could build it with looping. And it would be even faster, I think. GREG: Yeah. Absolutely. And plus if you do it in single elements, it's also much easier to debug as you're exploring and kind of playing with the preview controller and playing whatever preview animation that you want. JEREMIAH: Exactly. And here, we actually did use looping for the fingers, just so you can get some parity between what we're doing with the forward graph and the backward-- or forward solve, backwards. One last thing I want to mention before I move on is, there is also this backwards and forwards operation here. And this is a little unique. And this is great for debugging your backward solve and your forward solve to see if they're working the way you expect them to. So what this is going to do when I go into this is it's going to first run the backward solve graph and then it's going to run the forward solve graph-- I guess kind of implied by the name. We won't see a difference here, hopefully. So I'm going to play that animation again. So this all looks as I would expect. But if, for instance, I had connected up something incorrectly, like let's see if I could break something. All right, maybe not that guy. I was expecting that to go somewhere weird. I see it pop every time you do that. But the idea is if, for instance, I was solving my pull vectors incorrectly, then it would solve the backward solve to my animation sequence and then run the forward solve based off where those control locations are. If I had created my backward solve incorrectly, I wouldn't be able to see the same animation play, because the Forward Solve would be stomping over the backward solve-- the backward solve, yeah. Helge, you want to expand-- clarify? HELGE: Yeah, you make the backward stuff look like not needed. If it never breaks, it just-- [INTERPOSING VOICES] HELGE: So a good example is-- a great example is, if you're just doing incorrect computation for where, for example, an effector should be for an arm. Like, if you're computing the hand effector in the wrong position, then what will happen is, after we run forward again, the hand will be in the wrong position. That's what will happen. And this mode allows you to debug it. So basically, we're first solving our controls by sort of the ground truth, which is the FK animation. That's what we expect to get out. And then we're running forward again. And of course, those poses should match. That's the goal here. So if it doesn't, then you've just identified it there now. So that means as you're building the backwards self, as you're building the graph, you can use this mode to figure out, have I made a mistake? Is this pose still the right one? And you can toggle back and forth between-- so can you go just back to-- just backward solve in the event that you're running? Just a quick tip, as well. So if you just click the big button instead of doing the dropdown, it's a toggle. So you can go back and forth. And this is a typical-- like, it basically goes back to the current and the last event that you're on. And so as you're building the graph, you can try-- is the pose correct, right? Well, we've seen a lot-- so when you have controls like pull vectors and they're incorrectly computed, they'll slowly wander off into space. It's a good bug that you'll see when you're doing a version incorrectly. So this helps you find those issues with the rig. JEREMIAH: So in this case here, I have the left hand control getting the position of the head and feeding that transform in. Now, when I'm running backwards solve, the skeleton-- the animation looks correct. But if I look at that left wrist, I see that there's no control there. It's going to be very apparent to me when I go to the backwards and forwards solve because now the forward solve is actually running the IK after that control has been moved to the incorrect place. So is this like being like, oh man, yeah, that's not the right bone. HELGE: Yeah, so if it were to use this rig with this bug for baking into Sequencer, that's what you're going to get. You get the hand on the head. And then this whole baking result is invalid and you'll have to start over. So this is a way of debugging it before you start using the rig for backward solving in Sequencer. JEREMIAH: Yep. Exactly. Thanks for the save. I was struggling with that description. All right, so I think that covers a lot of the changes that we've made here in this Control Rig. I see that I broke my leg as I was doing random changes. Let's see if there's anything else. I talked about these guys. Oh, one last thing. My Blueprints-- this may not be open for you by default, which you can go to just Window, My Blueprint. And in 4.26, we've changed the way the variables work. Before, we had parameters and variables. And they were about whether data is coming into Control Rig or whether data is being used within Control Rig. And it was a little confusing. So we simplified that just by going to a paradigm that everyone's used to in Unreal, which is the My Blueprints. You see this in other actor Blueprints or animation Blueprints. In order to create a variable, you just hit that plus button and name it My Variable. In this case, now I have a Boolean. I can change my type here. And I can drag these directly into my graph to get or to set. I can also go into my-- I can also go into my details panel. And just by default values, put them in categories. Is there anything else that you would expect for variables? Initially you should be able to right click and search and find it in your context in your graph. HELGE: There's one other really big thing that these guys give you, which is that any other Blueprint can access them. So before we sort of had our own magic variable functionality and it wasn't great in that it wasn't working with everything else in the system. Now, if you make them nonpublic, so if you just don't have this eye icon on, then you can use them for internal simulation. You can store stuff as you've solved the rig and remember things that you might be-- maybe only remember certain frames, anything like that, like internal state. If you make them public, however, you can have settings on the rig that other procedural logic in the game can drive, so any real-- like, any other system. They're also available as variables in the Python reflection, and so on. So it's pretty powerful. Basically this opens up wiring Control Rig to other systems. JEREMIAH: Yeah. And I think we're going to show some of that in some of the demos later. VICTOR: Jeremiah, before you move on, do you mind showing the mirroring function that's in the hierarchy and also the nodes? JEREMIAH: Sure. All right, so in order to-- so we've added some sort of mirroring in a few ways. Greg, I'm just going to let you demo that, because you've been doing a lot of-- [INTERPOSING VOICES] JEREMIAH: And I will stumble over it right now. But you can right click on nodes. And we have this mirage. And this will allow you to mirror in space your controls. And also you can mirror graphs. In fact, I think, if I can right click this-- I can search or replace mirror and determined what direction I want to mirror and do some search and replace, so left to right side. I don't know. Actually, I need to say more. It's a very simple and very powerful tool for building complex graphs. All right. Let me go back to my handy dandy slides. Unless if we should have any questions around that mannequin, we can answer more questions later. VICTOR: We have a lot of questions. But I think going through all of the content first and then we'll tackle some of them at the end. JEREMIAH: That sounds good to me. VICTOR: Yep. OK. JEREMIAH: All right. I'm going to pass it over to Greg and he's going to talk about rig sharing with Control Rig. And he's going to dive into the Setup Graph and the new Control Rig component available in 4.26. VICTOR: One thing just before you do that, Greg. There was a little bit of confusion between the naming convention of the word rig and how you are using it. I believe in most instances you're using the word rig referring to Control Rig, which is a different rig versus the rig that most typical animators might be used to in Maya and other DCC tools. JEREMIAH: I guess we could refer to them differently. But at the end of the day, there is Control Rig, which is the asset itself. I come from a rigging background. And I refer to both this and this as the rig. This is just the result. This is the animation rig that an animator would interact with in Maya. Here we're just doing it in the engine. And this is the editor in which we construct it. So Control Rig is just the editor of the asset itself. I use them fairly interchangeably, because at the end of the day, I'm driving an animation pose or an anim sequence with these. Does that answer the question, or is that still confusing? VICTOR: I guess the terminology is usually to refer to the skeleton as the rig. JEREMIAH: I see. OK. Yeah, I think we refer to that generally as the Skeleton. So in Unreal, there's a lot of different naming paradigms. We have a Skeleton, Skeletal Mesh, and now Control Rig. And to confuse things even more, we have a Rig Hierarchy. And we specifically call that Hierarchy, because although this looks like a Skeleton, we actually import these bones from Skeleton asset type, which means that these aren't referenced. And I can make modifications to it, like parenting controls under it, or parenting other things under it. Now, this does mean that if I, for instance, update my character and add new bones to my skeleton, I need to refresh from my Skeletal Mesh. I know that gets a little confusing with all those different terms. And rig, at the end of the day, becomes a kind of an overloaded term. But in this case, I'm talking about the animation rig that an animator would interact with to create anim sequences. HELGE: There is a-- just to add something there. And I think I just have a slightly different view on this. I feel like if you look at it from Maya or from Blender or these environments, basically a rig for a character usually is both what the rigger would build in terms of building, I guess, a scene content with all the curves and the things you can click on and all the bones and all the things and the meshes and everything in one big graph. And they'll sort of mix both the animation controls that you use and the logic that is run to compute the pose. They're usually one thing. So it's a bit harder to differentiate. Here, we're actually separating these two things completely. So this a sort of a new paradigm. So some users may be coming from something like Maya or Blender where we differentiate between the logic that's running inside of the rig that computes the poses-- this is the graph you see on the right-- and sort of the UI to the character, so the controls you click on that you interact with when you pose the character. So both are the rig. It's just they're slightly differently interacted with, either through Sequencer for animation or through the Control Rig editor here. Does it make sense, Jeremiah, or was it even more confusing? JEREMIAH: I think that it makes sense and there are different answers for different audiences. We probably have both on this, so-- HELGE: Yeah, that's fair. VICTOR: Cool. Let's hand it over to Greg. GREG: All right. Yeah. So Jeremiah talked about some different events, including the Setup Graph or Setup Event. And I'll be going over that and talking about how, with 4.26, you can share Control Rig assets. So in here, I have a level with four actors and I'll open up my little sequence and I'll play it. So I have four actors playing the same animation, same one for the mannequin sample. And basically, what I have here is I have three skeletal mesh actors all sharing the same Control Rig, as you can see in Sequencer. We can see that they are sharing the same track name. And if I select the Control Rig track on each, you'll see that they all apply the same Control Rig. This one is using a Blueprint actor, a custom Blueprint actor, that is using a Control Rig component that also is using the same Control Rig. So there's two different approaches on how we're going to share the Control Rig asset. So let's take a look at the Control Rig. And here-- I'll full screen this-- what we have is using the set up event. So set up event, basically, is a way to initialize controls, bones, or transforms. And in doing so, we're going to set the initial transforms or set additional control offsets before any forward solve or backward solve logic. Do you guys have anything to add on to that? JEREMIAH: I think that covers it. GREG: Cool. So basically what we have here is I'm grabbing the bone, the initial-- so I'm grabbing the initial transfer of the bone. And what I'm doing, as Jeremiah had illustrated earlier, is with controls we are having this offset transform. So what I'm doing is I'm grabbing the initial transfer of the bone and putting it to the control offset. And we're doing that across all of our controls, including some looping. So we have a new item chain node where we can loop through that and concat, doing the same thing as before. And just slowing down here. JEREMIAH: Let me jump in real quick, actually. GREG: Yeah, sure. JEREMIAH: I want to talk about why we want to do this. In the demo that Greg just showed, we had four different characters running through and using the same Control Rig. A big problem with that is that the controls are always going to be in the same location and the bones are always going to be in the same location. So if we played the same animation on all four of those characters, they don't get skewed to that one proportion. So at the set-up graph, this allows us to initialize that rig in different proportions, like Narbash there to the female and the male mannequins. And I'll use that same rig and reinitialize that rig to adapt itself automatically to all those different character proportions. And so what Greg is going through here is the setup graph and how we're able to pull that data in and adapt our control rig on the fly and then play that animation on the controls. GREG: Yes. Yes. And something to note, as well, is that the female mannequin and the mannequin both share the same skeleton. However, Narbash from Paragon does not. He has a unique skeleton. So the ability to where we're passing that through is all via names. So Narbash's skeleton has more bones than a mannequin. However, his face armature-- his face might be the armature-- has the same bone names as the mannequin. So therefore, that's passing it on to the rig hierarchy and we can grab the initial transforms from that. So in here for the arms and the legs, it's the same thing. There's a little math involved in order to calculate the pull vectors and the reverse foot controls. And then for the fingers, we're-- all I did was I just duplicated the same graph from the forward and backward solve and just changed it from the control transform for the get control transform and set that to the initial. And that set the control offset. And so looking at the Sequencer again, you can see that for the mannequin and the field mannequin, for these three Skeletal Mesh actors, they're sharing all the same animations from the sample. HELGE: Greg, can you do me a favor and just stop one frame, maybe with us standing in the back there, and just go through and click on each one, just so you can look at all the controls for each one? GREG: Yeah, sure. HELGE: Because it sounds pretty obvious, especially between Narbash and the mannequins that the controls are in different places to represent the same pose. Basically what you're showing with set up is conforming the rig onto a new skeleton. And this allows you to make a generic rig work with lots of different proportions. This is something that if you guys are used to autoriggers and Maya gear or other ones, where you can create a rig and then run a script that creates the same rig for a different proportion, it's the same idea. It's just we're doing it live. Every time when you click on the character, we're basically fitting it on there. So you can use it for animating it. GREG: Yeah, exactly. Something that's unique about this actor in particular is that we're actually able to swap our Skeletal Meshes on the fly. So if I go to this-- if I go to the Skeletal Mesh component and look for Narbash, see that Narbash gets changed. However, the Control Rig will also be reinitialized to the Narbash Skeletal Mesh. So I can go back, look at the mannequin. And you can see how the Control Rig gets retrofitted. This is using our new component called a Control Rig component where if I look at the Blueprint-- JEREMIAH: Surprise, surprise. GREG: --we have in our viewport-- we just have our Skeletal Mesh, which is just using mannequin, all default settings. And then we have a Control Rig component. And this is our new feature where you can set the Control Rig class and you can see that it's the same-- the mannequin shareable Control Rig. But if we take a look at the construction script, what we have is a new function for 4.26 called Add Map . Skeletal Mesh. And basically what we're doing here is we're telling Control-- or we're telling Control Rig to add this skeletal-- to add the Skeletal Mesh within the Skeletal Mesh component to map it across. JEREMIAH: Something to highlight here is since we can create this mapping in the Blueprints, that means you can have multiple mappings. So you can say drive Narbash and with a backpack and another character. And you can have that same Control Rig driving multiple Skeletal Meshes, similar to driving a body and then a head attachment or something like that. GREG: Yes. Yes, exactly. HELGE: Greg, can you do me a favor and pull out the Control Rig pin just to show the other options? We don't have to open any of them. But if you just look here, basically-- you don't have to click on any of them. But there's other ways of mapping things, as well. You can map Static Meshes. You can map general primitive components, anything that has a transform if you want to drive things which are not Skeletal Meshes. And you can also have very granular control over, I want to just map this one socket or this one bone. The node that you're showing here, which makes a lot of sense, is the high level one that just does the job for you but you can't customize it. There are, however, other functions in here that are very customizable, very like granular in terms of flexibility. JEREMIAH: And I think Greg's going to dive into those more when we get into the gameplay. GREG: Yep. So also within our Control Rig component, we'll also have some different events. So we'll have, I believe, that's what, five different events where we can say on post initialization of the Control Rig, or on pre or post the setup event, or on pre and post forward solve. So what does that mean? That means that we can-- before the setup event-- so if we go back to the Control Rig-- So before the logic that happens in set up event, we can run some sort of logic on the Blueprint, whether that's passing it down to the Control Rig or grabbing something from the Skeletal Mesh or some other Blueprint functionality that might be needed. In this case, what we're doing-- and this is a new function strictly in 4.26.1-- is we're grabbing the Skeletal Mesh from the Skeletal Mesh component. We're grabbing the Control Rig component. And we're just saying, hey set the set the initial bone transforms from the Skeletal Mesh, so that way when we change the Skeletal Mesh on our component, it'll get passed down to the Control Rig hierarchy and then all the initial transforms will get updated towards that new Skeletal Mesh. So let's take a look at it again with a little sequence. See that I select the mani. Can change this to Narbash. And it will automatically retrofit and also all the animations will stay the same. JEREMIAH: One minor tweak is the controls animation, so the current animation of the keyframes in Sequencer, are going to be relative to the new initial positions. So in this case, since Narbash's arms at ref pose are much wider, his hands are going to move relative to that wider position. GREG: Exactly. VICTOR: Anything else to add before we move on? GREG: All right, let's move on to the next demo, the Ridig' Pig demo. So this is a demo in order to show different ways to possibly approach attaching Control Rigs. So let me go ahead and open that level. So here we have Manny riding on a pig holding a gun. And having some sort of customizable pose, as well. And what we have here is in the little sequence, we just have two Skeletal Meshes that are running Control Rig tracks. I'll go ahead and select the pig, which conveniently enough, was using the backward solve. So I took a pig animation and I recorded a rip motion. And then I applied a run animation. And so that way I could backward solve onto a Control Rig so that way it can run. And then we have a gun, gun rig, which just has just a simple attach track. And then we have the mannequin, as well. So with the mannequin, we're using a mixture of a Control Rig component and additional Control Rig logic. So let's take a look at the Control Rig. There are some key differences that I'm doing in here in comparison to the mannnequin sample. So for one, I've manipulated the Control Rig hierarchy where I've added something called the body space underneath the offset control and moved all the IK controls and the pole vector controls and all the body and spine FK controls underneath this body space. And additionally, what I've done is also I've created another control called input control. In terms of the graph, I've basically copied exactly the same as the mannequin sample. However, I added one last thing at the end, where we're grabbing a follow variable, which Jeremiah illustrated how to create variables within the Blueprint tab. And I've exposed that. And what we've done is we've branched from there. And if it's true, what we're going to have is the input control-- so this one. That's outside-- control the transform of the body space. So that's kind of how we're handling the attachment. On the Blueprint, what we have is, once again, it's just a Control Rig component and a Skeletal Mesh component. And if we look at the construction script, for the first part, it's very similar to the sharable control rig, where we're mapping to the Skeletal Mesh. However, we're also mapping additional element. So what I've done here is I've created two variables, a follow variable, so that way we can attach it to the Control Rig object later on, and also a actor variable. This allows me to-- when I create the instance of this Blueprint, I can set the actor variable to anything that I need, because eventually what we're going to do is we're going to take this actor variable and we're going to make a Control Rig component mapped element. What this means is that whatever this actor that I've assigned, it's going to control the input control that I have in Control Rig. And it's going to control it in worldspace. There's a bunch of different options that is available in the the Control Rig component mapped element. You can change the different types, the bones, spaces of curves. You can also change the directionality, if you wanted to. So right now I have the actor driving the control. However, I could have the opposite effect where it could be the input control controlling the actor. And also there's a bunch of different spaces that we can do, doing world in this instance. And what we do from here is after making this element, I make it an array. And I use the Add Mapped Elements function that's available on the Control Rig component. JEREMIAH: I want to note-- sorry. I want to note real quick that that Maps component elements node represents the data structure that you could manually populate on the control room component itself, if you wanted to. Yep, there's mapped elements right in there. Ah, right here. So you can click that plus and drop down. And you'll see the exact same data there. It's just much easier to build it dynamically with your graph rather than populating that detail screen there. In fact, the second that you apply your map's data, I believe it overwrites the main stuff you did there. So it's created at the graph. GREG: So let's take a look at the event graph. And this is where I'm using the Pre Forward Solve a bit where I can grab the component, I can grab the Control Rig, and then I can cast it to the Attach Control Rig and then set the follow variable. So like how, again, Jeremiah said earlier, after changing it more to the variable workflow that is across the board in Blueprints and animation BPs, this is following that same workflow where you can cast to the object and be able to set variables very easily. So let's take a look at the sequence again. And there's some additional things that I've done in order to attach the mannequin onto the pig. So what I did was I created an empty actor and I attached it underneath the pig's spine. And then what I ended up doing, for the instance, is I turned on the Boolean variable and also assigned it to the attach actor. So that way it will follow-- mannequin will follow the pig. HELGE: Greg, can I ask you a question? And I'm putting you on the spot a bit, I know. GREG: Yeah, sure. HELGE: Is there a reason why you're setting the space for the body at the end of the rig evaluation? Looks like you're doing it at the very last step, right? GREG: Yes. So I had initially did that just to not mess with any of the previous logic that we had on the sample. You could technically put it before. You could technically put it after. HELGE: The reason I'm bringing this up-- and again, apologies if this is uncovering something here. But I just noticed that there is a frame delay. Like, there's basically a frame delay of the body pose with the guy on the pig. And so if you were to connect this space copy from the follow before everything else in the body, then the frame delay would go away. So I did review this content before and I didn't actually spot it. But I spotted it just now on the livestream, so sorry about that. But it's like, for the users, if you want to rewire, I can also have it on my screen. I did the change. So it does show that-- it makes sense, right? Basically, what you're doing is you're solving the body, everything, putting it in place. And at the very end, you're setting the space. So in the next frame, we'll use the results from the animation. So if you just wire it before, then that's what you're going to get. So you'd have to add another sequence node, I think. GREG: No, we'll just do it before the sequence. Yeah. So hopefully-- HELGE: Yeah, that should do. GREG: We'll see if this breaks anything. HELGE: It shouldn't break anything, but yeah. So then-- GREG: Oh, yeah. Let me compile the Blueprint. HELGE: Oh, OK. Yeah, that makes sense. So now the frame delay is gone, basically. But it does make sense. I was just spotting this. And I was like, I don't want to confuse people out there. So if you're bringing something into the character that is needed for the post computation of the character, you need to do that first. You bring it in and then you can use it for other stuff. It makes sense now. GREG: Gun is-- I don't know why the gun-- oh, that might transform did my transform track disappear or something. I think my transfer track got moved on accident somehow. HELGE: So feel free to reload-- [INTERPOSING VOICES] HELGE: --if I managed to screw the presentation now, sorry about that. GREG: All good. Well, something to note, as well, is that now I won't fix the gun transform. But with another way that you could attach Control Rigs is to use your attack track. One of the reasons why we were using the Control Rig component in order to handle this was if we did an attach track in Sequencer, it would be attaching it to the actor transform versus what we would need it to follow for the body. So if you had it on the root, then you have to counter constantly every time. So that's why we did it to the Control Rig component. However, for the gun, since we're just having the root attach it to-- attach it to the hand, we can just use an attach track and we can manipulate any sort of additional controls that we need and animate that accordingly. HELGE: It's very cool. I mean, there's also-- I will carefully say, without saying what we're going to be working on next, but this clearly is an area we want to focus on making this easier. So what you're presenting here is great in terms of, there's several workflows of attaching things together. You might pick one over the other, depending on your use case. So you can already do that. And of course, you can find a very sort of pipelineish pattern for this. So you can always do it the same way for your show or whatever you're animating. However, we're aware that currently it's a bit, like, let's say clunky-- and it's something we'll look into in the future and we're aware of. GREG: Absolutely. And something to note, as well, is that this shows a lot of power within the Control Rig component. You can pass in data. You can get data. And you can manipulate it all within Blueprints. You can create additional actor variables and pass it down and pass it forward, because I know there were some questions about being able to assign certain actors in the world to certain controls or some sort of a factor like that. HELGE: I'm quite excited about you showing this-- what you're showing sort of slowly diverging from the classical path of rigging, like as the presentation is going on, you can see. First you have a character and then you have a rig. Now we sort of-- we have a component that hosts a rig. And we're doing some custom massaging of the data. And what this means, really-- and especially with the vents you're showing-- like, you can run some custom logic after the forward solve is done or before you can hook it up to Blueprint and do all this stuff, right? What this means is you can start using the rig as a tool instead of your characters or instead of whatever you're using it for. You don't necessarily need a Skeletal Mesh. So it opens up all sorts of interesting workflows for people to use rigging in other creative ways. GREG: Yeah, absolutely. Absolutely. JEREMIAH: Greg, did you talk about the pre-forward solve? Did you mention exactly-- GREG: Yeah. I can mention it again, just so that way we can-- JEREMIAH: Because previously we talked about the pre-setup events in the previous demo. But here we're doing a pre-forward event, pre-forward solve event. GREG: Yeah. So basically, what we're doing, since we're back in the Control Rig, we're querying for the Boolean. What we want to make sure is that before the forward solve happens, we want to set the follow variable from this Blueprint down to Control Rig. So we can have this logic down where we're setting to follow and then that gets populated down. And then when this gets ran, it will actually run the true function, set to false. HELGE: It's basically giving you the ability-- I mean, for people who aren't familiar with the events in Blueprint-- it's basically giving you the ability of getting very granular messages from Control Rig when it's doing what, and then react to that, right? So in this case, just before the rig is supposed to do the forward solve, you can change some data, or bring in some data-- in this case, a Boolean. It might as well be a transform or very high level data that you have into the rig for consumption. After solve, you might decide to take the transforms the rig has solved to and do some additional changes in your logic or whatever. You get full messaging from-- or full notifications from the rig for what's going on for these series of events that you're showing there at the bottom right. And you can build custom logic against that. GREG: Yep. All right, let's move on to the next demonstration where I'll pass it back to Jeremiah to talk about slope warping. JEREMIAH: Yeah. All right, so slope warping is something that we talked about a little bit before. In fact, if we go back to the Paragon days, Laurent, who's one of our lead engineers, animation engineers here at Epic, did a talk about slope warping as an approach that we use to adapt our characters to different environments. So I'm going to demonstrate here what we have. So I'll just go ahead and play. There we go. So I have my mannequin here. And my character just automatically adapts to a different terrain. And I can run around, climb up some stairs, and see my feet are going to adjust automatically. All right. So there's a lot of different ways to do this. Oftentimes we'll just see this as IK foot tracing, or something like that. And oftentimes this approach can get pretty cumbersome, including actor Blueprints and animation Blueprints and other processes all passing data back and forth. But in this case, let me show you real quick what this looks like. There we go. I actually wanted to show you the Animation Blueprint. This is my Animation Blueprint. All it is is a Control Rig node and I'm taking in the speed. There's no extra attribute key or anything. So this is how simple it was for me to get to add this into my anim BP. I don't have to change the logic across my entire character. All right, so first let me show you kind of the theory behind it. And in this case, I have a mannequin here. I have this square that, in this case, we're going to pretend like this is the ground. And as the terrain changes, my character is going to automatically adapt to the differences in terrain. In fact, the feet are going to change their angles. My hips and knees are going to react accordingly. If I bring this up, in this case, my pelvis is going to stay in its current, animated position. And the legs are going to come up. I could just as easily make it so that there's a max compression, just like I have a max extension here. You can also actually see, as I do this, there's kind of a little bit of a lag. I wouldn't call it a lag. It's just a damping effect, so that as my character moves over quickly changing terrain, the entire character isn't jittering. And last but not least, this demo is taking advantage of our new experimental full body IK plugin that we've released in 4.26. If you go onto the plugins and search for full body IK you'll see that plugin built for you. It's currently in experimental mode and available to use in Control Rig. So let's take a look at how this demo works first before I get into the full slope warping Control Rig. So this demo taking in a couple of things, taking some controls in and setting to transform. So actually, let's look at the hierarchy first, because that's pretty important. In my hierarchy, I'm using the default mannequin. And default mannequin already has IK mode. So it has IK foot roots, IK left and right roots. And I'm going to-- or IK foot left and foot right. And I'm just going to take advantage of those. So kind of like we were just talking about where we pulled data externally into our graph before we do any other processing, that's what I'm doing here. I have my chest coming in from my spine 3. In my final one, that chest animation is going to be taking in my incoming chest pose so my upper body stays as true to form as possible. IK foot root is going to be driven directly from my slope control, which this is my slope control. And in my next graph, that's going to be driven through a sphere trace. And then I have each foot driven by a foot control. So that allows me, in this example, to then offset my foot as if I had uneven terrain. And then I had a sequence. So now that our rig is kind of set up, I'm going to do two things. One is I'm going to calculate the hip compensation. So the longer my leg has to reach, the more I have to adjust my hips so that both feet are planted on the ground. Now, I do this in as data driven of a way as I can. I actually measure the length of my leg in its initial state, so the distance between my thigh and my foot. And then I measure the distance between my thigh and my IK foot, which is the projected position of my foot. And if it's greater, then I return the value. Otherwise, I return zero. So I do that for both my left and right leg and I see which one has to extend further. And I pass that data into my pelvis. And this is just to accumulate lerp with a speed so that I can kind of arc direct how quickly my pelvis is reacting to changes in my foot position. And then I pass that data to the x transform of my-- or translate x of my pelvis control. And then adjust my pelvis bone to my control. So something I have seen often is people are driving bones directly. In Control Rig I could drive controls this entire time and then really manipulate exactly how those controls are solving before I apply any data to my skeleton. It also helps to visualize very quickly what's happening. So as I just rotate this foot back and forth, you can see the length of my leg gets hyperextended and my hips start to compensate. In fact, if I zoom out here and I start dragging, you can see the graph running and telling you which leg is extended, not how it's [INAUDIBLE]. So at this point, all I've done is I'm manipulating my pelvis control. I'm using this under control as my pelvis so that my source body location is always consistent. And then I just use that second control as an offset. Once my pelvis has been compensated, then I'm going to use my new full body IK plugin. And we're going to feed it in all the data I've gotten so far. So in this case, I'm bringing in the root bone for my chain. And then I'm going to feed it a couple of factors. I'm feeding it my pelvis controls, my left and right feet, my left and right IK feet, and my chest, just to kind of help lengthen the body. I also have a couple of constraints here, just to keep the knees oriented a little better. And I also have the pull vectors here. So in this case, I can manipulate my pull vectors directly. But I'll show you another example of that later. And then after I've solved my full body to compensate for what's going on-- so let's go ahead and kind of tweak this a little bit-- then I'm just going to force the feet rotation to the ankle of the foot controls here, or in my next example, to the orientation of the terrain. So I think that's the general theory behind this. One thing to note is this slope warping aspect of this is actually the rotation of this IK foot root bone. So that root bone is going to orient to the terrain. And as that rotates, it's going to take these left and right IK foot bones along for the ride. So those feet will automatically be oriented to that terrain in their own unique spaces. And then I can offset those feet individually. So that's the slope aspect of this. So let's jump into this full graph that I was running here in my previous step-- in my demo as its running around. And while I do that, let me show you one of the debugging abilities. I'm just going to hit Play. And since I have this set for maybe a little slower, but I'm going to choose in my debug filter and Control Rig. Now you can see my demos Control Rig available. And now as a runaround, you can see my character adjusting to the terrain here in Control Rig. And let's go ahead and just rotate around so you can see how my character is adapting. So you could debug your character and see exactly what's going on. You could see the body positioned came in there. You could see it rotating actually with an incoming bone pose-- skeletal pose from my anim Blueprint and then offsetting from there. I also have here some visual debug squares that were released in a previous release. And so I've turned on those visual debugs in my Control Rig so that I can easily debug here at the Control Rig editor. So I'm going to keep running around, just to show you what it's doing. I've got to adjust there. There we go. Now we'll get some feed at a different angle. All right. So what's going on to make all of this work? As always, start with that forward solve. And then I'm going to pull in some data externally. So before I do anything, I'm actually pulling in the left and right starting foot positions. So this is the incoming pose, the animated pose of this run. And I'm going to set my IK left and right feet to those. You could do this with virtual bones. It's not really a problem with virtual bones, but one of the things to consider with virtual bones is that those bones exist on the skeleton itself. So you would have to modify the skeleton. In this case, I can do the data all in Control Rig. Or in this case, these bones already exist in this mannequin rig, so I'm just leveraging this. So I'm pulling in my left and right foot positions for my animation and setting my IK feet. And then I'm going to calculate some pole vector positions. In this case, I just kind of cheated and I took the direction that my foot is facing and offset it with a value to just keep my knees pointing generally over my feet. You could do a more complex calculation if you want to. But this seems to work pretty well in here. And then I pull in a little bit more animation data. I'm pulling in my spine 3 animation coming in. And I set that to my-- I drive my control with that position. And then I pull in the pelvis animated position and drive my body control, which is, again, this yellow hexagon I have here. So now at this point, I've gathered all my external data that I need from my incoming pose. And I can start doing some offsets. Before I even do offsets, let's see if I need to do offsets. So I have a branch here. Branching is, we seen a couple times now. And this is new in 4.26, so you can build some more complex graphs. And I have a condition off of this sphere trace node. This sphere trace node is also new. It takes a start and end position. And so I'm just taking the position of my root bone and I'm measuring up-- or I'm sorry, I'm only measuring down 50 units. I don't want my character to pop up. I would rather my castle move up and then compensate my character back down to fit on the ground. If I'm not hitting anything, then I don't want to change my character. I want to leave it alone, so if I'm jumping or vaulting or something like that. But if I do hit something, then I'm going to start aligning some bones and setting my character up for adapting to my terrain. Let's move this out of the way so I can make this a little bigger. So first thing, I'm going to align my IK foot root with the ground. So coming from my sphere trace, I'm going to get the trace position and-- or the hit position and the hit normal. The hit normal, I've actually clamped. So if I'm hitting the edge of a stair surface, I don't want my whole character to rotate 90 degrees or nearly 90 degrees. So I'm keeping it within kind of an angle that I think is reasonable in this case. It isn't absolutely necessary. You may want something different. But this is what I chose in this example. And now that I have that normal, I'm going to use the in math node to orient my IK foot root with that normal. I'm feeding in this target as a direction since I'm getting a normal instruction. And once again, I'm going to use accumulate lerp just to dampen the movement a little bit so I'm not getting any jerky motion as my terrain adjusts very quickly. And update that new rotation in and that hit position in. And now I have my translation for my-- or my transform for my IK foot root. Now I'm going to do a couple other things. First is going to be adjust my feet. So now I've adjusted my entire IK root. And then I'm going to offset each foot to make sure that they're landing on the ground and planting if they have unique normals. I just wanted to add a little bit of a performance consideration in here. There's a lot of different ways to do this, but in this case, I'm only going to do the feet if my character is basically idling or slowly starting to walk. So I'm going to use looping. And instead of using a foreach, I'm actually just doing a count. So I could have done this different ways, but I wanted to show it as just a standard for loop. So I'm counting twice. And if I'm in the 0 index, then I'm going to get IK foot left. If I'm on the first index, then I'm going to get IK foot right. I'm also going to use variables here to make my life a little easier so I don't have lines stretching over the entire thing. So I'm setting what index I'm in. And I'm also setting what item I'm using. So in this case, first IK foot left, then IK foot right. And then I'm just going to call those later on. I'm going to zoom out so I can talk about the logic here. This chunk is just doing a smear trace again above and below the foot. So my hips have already moved and I may need to move one foot up, one foot down. So that lets me trace above and below and see if step up on a step or step down on a step. Then I'm going to orient the flip to that surface normal. I guess before I even do that, I'm going to see if I hit anything. Otherwise, we're just going to go back to our incoming animated pose. I'll gather my surface normal and orient each foot individually. And again, these variables aren't the ones that I collected before. And one thing I did before is I gathered that-- the index that I am in the for loop. And that lets me select different values. In this case, I needed to feed in a different axis, whether it's left foot or right foot, since the x direction of the bone chain is different whether it's left or right. And so I'm able to use the select node to do that type of behavior. And then I pull all this together with, again, one of my favorite nodes, the lerp, with a flip lens speed so I can art direct this however I like. And at the end of the day, I am just setting the transform for my left and right IK feet. So as I said previously, at this point, all I've done is I've collected the data before I fed it into the system. So now I have my IK feet bones in the right place, my IK root bone in the right place. And now I can start acting upon it. I'm going to measure my hips. This is the exact same thing that we saw in my previous demo where I'm measuring the length of my animated-- or my projected leg extension and my initial leg length to see if it's hyperextended. And then I adjust my hips down. And then I get back to my Full Body IK. And this is basically the same thing, my pelvis body, left and right feet, and my chest. And then I have my pull vectors going into the constraints. And then fix up my feet rotations at the very end just to make sure that they're landing exactly where I want them in my level. So once again, we'll run around with this. Let me make this a little bigger for you. It can run around on this sphere and see the feet adapting to different terrains, whether they're soft or not. So in this case, I could do more complex foot tracing. In this case, I'm tracing essentially from the ankle down, which is why we see it hitting the heel but the toes are going through. If I wanted to, I could do more complex and trace the toe and the heel and do all kinds of cool stuff. All right, so this is my slope warping demonstration. HELGE: There's one thing I want to point out. Sorry, Jeremiah. I feel like I did the same thing to Greg and now I'm doing it to you. I found something that is a little mistake on the rig. And I just want for the viewers just to clarify it. So if you go back-- it's actually not a mistake in terms of the output. But if you go into-- yeah, that one. JEREMIAH: This is Helge code review time. HELGE: I know. I'm sorry. I just want to make sure that if people watching, they don't get confused. So can you go to the area where you're computing the pull vectors? This is like in the top left somewhere. JEREMIAH: Well, yeah. I mentioned I cheated on that. HELGE: I know it's a cheat. But the only thing I want to call out-- so sorry about being so particular. But basically, where you've connected up to the bone the input, which is I think supposed to be the parent of this, right? So you're basically saying, take the bone space. And then within the bone space, add like 3 and 50 or whatever you have there? Is that what it's supposed to mean? JEREMIAH: Yes. HELGE: Or are you just trying to globally offset? So basically the order of operations is different. The parent goes into the second slot. This is something I've seen in lots of rigs where, because what we're doing in Control Rigs are actually reflecting what the Unreal mass library is doing, and our transforms are post multiply. So the parent goes in the B slot, which is really confusing, which is why we have another node. That's what I want to point out. We have another node, which is called Make Absolute. We have one called Make Absolute and one called Make Relative for doing these kind of operations. So if you were to replace this with that, I think it would be a bit more readable. That's the only comment I have. So for the viewers, if you want to take a transform, you want to offset a certain way, my recommendation is use the make absolute or the make relative nodes instead of the multiply because for the multiply, you don't actually know what's what. Does that make sense? JEREMIAH: Got it. HELGE: All right. I'm shutting up now. JEREMIAH: So users, feel free to make those changes on your side when you recreate this. We've gone through this several times practicing for this. HELGE: I know. So what's interesting to me is-- it's my fault, absolutely. What's interesting to me is that it just works still, right? Because a lot of times with these kind of math operations, you don't notice. You will notice eventually if there's some extreme rotations happening on the feet source animation. But due to the fact that your animation isn't actually turning the feet in crazy ways, you don't see the problem. JEREMIAH: Yeah, I'm sure if I did a rotate 45 degrees or something, or 90 degrees, if my character rotated in place, then I might-- HELGE: The only reason I mention this is so that if people are using this video as a reference that we clarified this is where you wanted to go. JEREMIAH: Yeah. VICTOR: That's why we have you here, Helge. JEREMIAH: Exactly. HELGE: We're still friends, right? Sorry. It's OK. JEREMIAH: All right, so this demo represents a prototype and the general concept of slow warping. There are a lot of different ways to do this, but this is one approach. And using Control Rig I'm able to kind of gather all this data into one graph and reach out to the world, trace against it, and pull that data directly into Control Rig. I don't get that frame delay that I may get if I had to pass through an event graph. And I'm able to visually debug it in Control Rig while I'm running live in the editor. VICTOR: Jeremiah, do you think we'd be able to upload this little example? JEREMIAH: I'm sure we can find a way to do that. VICTOR: Cool. Yeah, just hit me up after the stream. JEREMIAH: Yeah. I think we shared this on Twitter, and it's been-- just the video is very popular. I'd love to share more stuff like this with the community. All right, so now we're going to move on-- HELGE: I was going to say, I think it's the most technical Control Rig in terms of implementation I've seen so far, using loops for switching between values and doing the rate casting all this stuff is pretty impressive. JEREMIAH: Laurent does this fantastic talk about that importation of Paragon. And I wanted to see how far I could go not being someone that's incredibly math savvy or technically savvy when it comes to programming. But I was able to go through it and replicate as much as I could with those concepts and get a pretty good result. So I'm pretty happy with how that turned out. GREG: It definitely shows the power of Control Rig, where you can manipulate that without having to write your own plugin. JEREMIAH: Yes. And I mentioned one thing in here, runtime post-process. So as we go through these, we're showing a lot of different use cases for Control Rig, both animator-centric where you can author new animations in Sequencer, and even use those later on to fake the dance sequences, and also runtime post processes where you can use it to fix up or correct or do corrective motion. Like in this case, where we have a Control Rig node in your NVP. So a lot of different uses. And the next one that we're going to talk about is When Robots Attack. And this is driving gameplay with Control Rig. So previously we just had an animated pose going in through Blueprints and feeding into Control Rig and adapting. In this case, we're going to drive Control Rig completely with gameplay. And I'm going to pass it over to Greg, who's going to talk a lot more about this. GREG: Yeah. So my screen's OK? VICTOR: Just a second. Can we switch to Greg? Perfect. Yeah, you're good. GREG: All right. Cool. So I'm going to play this little demo. And I'm going to full screen it. And we have a character. And as the character is moving towards the robot arm and the robot arm is following the character, you can also see that it goes up to an uprise position with the pinchers being animated. One thing that Jeremiah said earlier, this is all procedurally animated. There's no pose assets, no animation assets. And these are just all running in anim VP through using a Skeletal Mesh on these robot arms. So as I'm running around, if we look at this arm in particular, as I go away, it goes back to its initial position. I can go ahead and do this for the other arm, as well. So let's see how I did that in Control Rig. So in Control Rig, what we have is we're going to-- actually, let me open up the anim VP first. Be a little easier to show it from there. So in anim VP, I have the Control Rig, as Jeremiah's shown earlier, with the slope warping. And I'm selecting my robot arm Control Rig class. I can also pin my variables that I have from the Control Rig and pass it along from the anim VP. And if we look at the Control Rig, what I'm doing is I am grabbing the attack position, so basically where the character is, and I'm comparing a distance between that and one of the bones on my robot arm. And then I am going to ease that value and input some custom values or set a distance multiplier. Then down here, I'm using an accumulated lerp, where I'm grabbing the attack position again. I'm grabbing the initial position of the arm pivot and setting an aim. So that will help with the-- when the character goes towards a certain distance, the robot arm will aim towards that character. Then this is something to know about the-- where I'm setting an IK. However, because the aim is going to be constantly moving the entire robot arm, what I'm doing is I have an IK space and an IK control. And I'm setting whatever the hand pivot is of basically wherever the hand is after the aim to the parent of the IK control. So then that way I can run a CCD IK in order to handle the up and down movement. Then what I'm doing elsewhere is I'm checking the state of the attack and then I'm making another blending weight multiplier, so that way I can pass that off to-- interpolation to interpolate between the initial position of the arm and putting it upward, and also the same for the pincers. And for the pincers, what I'm doing is I'm just using an accumulated time node with sine and remapping it for a certain rotation value and passing that along for the rotation of the bone. So let's take a look at that again. So as I move closer, it's aiming. If I move back, it'll go back to its initial position. Start aiming towards this. And if I move a little closer, it will interpolate up, and those pincers get animated. I don't think I went over this, but in the robot, what I have is, in order to handle the attack state is I have an attack range capsule. So basically, when the character moves into this capsule, then it will change the state for attacking. JEREMIAH: And then in that-- is it in the level Blueprint that you're passing in the action position? GREG: Yes. So in the level Blueprint, what I'm grabbing is I'm grabbing the actor location and seeing if it's overlapping on the actor and then setting the-- and then changing it to the attack state. That's all there is to it. JEREMIAH: Very cool. HELGE: It was very cool. And nothing to criticize, Greg. Can you believe it? JEREMIAH: Yeah. It's awesome to be able to just generate animation and gameplay really quickly. Even if this is just prototyping, it gives you the tools to do that type of stuff. You can layer in animation, if you'd like. We've had a lot of fun with this type of thing here. HELGE: It's really cool but as well is that you're actually starting to merge-- so the same character pipelines for various use cases. So it's kind of nice that you're able to build certain things for solving robot arm and then depending on how you're giving it the data, how you're handing in the data, you can animate a Sequencer, or you can build something like this instead of procedurally. So there isn't a big differentiation, I guess, what I'm saying, between if you were in a CG studio animating a feature film with this, there isn't a difference between something that's procedurally driven completely or had animated in terms of the rigs you can build for it. Does that make sense? There's no multiple systems that you need to use, which is classically the case. GREG: And something to note, as well, is if you have any procedural animation that you do in Control Rig, you can record it with some of our cinematic recorders and have that down to an animation sequence, which then, if you wanted to author that, you could do a back resolve on one of your authoring rigs and then adjust accordingly. VICTOR: Jeremiah, I think you showed that during the last Control Rig stream we did, right? JEREMIAH: I think so. Yeah, I talked about baking anim sequences. We do have some new features in 4.26 which I don't think I had quite planned to talk about, just because I'm not prepared. We have a lot to talk about already. But in 4.26, we have not only bake anim sequence, but also bake linked anim sequence. And the linked sequence is slightly different. It's definitely a complete departure from what Greg is talking about here. But it provides you the ability to edit in Sequencer and save your level sequence. And as you save your level sequence, it's automatically going to update the anim sequence in the background. So you no longer have to overwrite that-- remember to overwrite. You can just animate the author directly in Sequencer. I might be able to demo that here in this next bit. GREG: Well, speaking of which, I'll pass it back to Jeremiah to talk about the Meerkat demo and demonstrating a film quality rig in the Control Rig. JEREMIAH: Yes. Let's do that. All right. Let me know when I'm good to go. VICTOR: You're good to go. JEREMIAH: All right. So this is a pretty incredible sample that the Verge production teams put together. And there was this incredible short film that Weta released using these tools with this Meerkat and this Eagle. If you haven't seen it, please go and check it out. It's really, really cool. And it represents a lot of the technology that's available in 4.26 beyond Control Rig. For these purposes, I'm going to focus on Control Rig, of course. And we're going to take a look at this Meerkat here. Now, included in this demo, in addition to all the other incredible stuff that the teams have put together, is a full Control Rig that we've modeled based off of my animation rig originally created. I'm going to open this up. Just going to take a sec here. And it represents one of our most complex Control Rigs put together to date. And it has an incredible amount of detail. I don't have time to go over everything in detail. But I do want to give you some high levels of what's available in this rig. So I'm just going to go all the way to the beginning. My goodness. And the person who rigged this, Chris Havreberg worked on this. And he structured this in a way that's very easy to read and deconstruct. So we can start up at the top because we drive the root. And we're using sequence nodes all over the place because it gives you good readability. Sequence nodes are also, as their names, run in sequence, which means it will complete everything on pin A before it begins pin B. So you can take that into consideration as you're building your rigs, driving your route before you drive your feet or something. So in this case, we're driving our route. And we have some spine logic here. And not only do we just have a spine, but we have IK and MK switching between them. We're also using item chains often through here so that we can propagate our motion and interpolate it throughout a full chain. And we're using looping, as well, to really minimize the length of this graph. 4.25, this would have been an incredibly large graph. It already is a large graph. But it's doing so much more in that amount of space than we were able to do before. We also have just some switching controls. In this case, these are float controls. And using that to automatically toggle between the states, branch between them, and then turn on and off the visibility of these controls, like we saw previously. As I go through this, I think you'll see a lot of similarities between what we're sharing in our Control Rig mannequin sample and what was developed here. We're just building off this same logic and expanding it to more and more places. We're also able to clamp all kinds of things. So in this case, we're only letting the spine stretch a certain amount and we're using spatial clamps to do that and doing some calculations to figure out exactly how far we're going. So again, my intention is not to go through this entire thing. I just wanted to point out a few key things. So we have spines. We have the ability for our legs to follow along with the pelvis, our arms to follow along with the pelvis. And then we go into neck again, IKMK switching, with some limit stretches driving the eyes. Here we see our FK and twist bones throughout doing their interpolation automatically. I think I've seen some questions about driving twist bones procedurally. This is a great example to take a look at and see if you can create this behavior in Blueprints. This also represents, if I'm not mistaken, driving the position of controls dynamically. So if you stretch the spine, you may want to position a middle spine control automatically based off of the direction of the other two controls. And you can do that automatically and then still rotate that control in animation, you're not locked out. And continuing on, shoulders, scapulas, the tail is actually really interesting builds. Throughout these on the spine and the tail we're using curves. We're using the fit chain on curve note. And so we're creating a curve representation, attaching the bones to that curve, and then driving that curve to do some pretty cool logic. And that can give you kind of that spline-based IK behavior. Not exactly IK, but that type of behavior here controlling it. And then using these interpolate nodes to determine exactly between the positions of these controls. A very cool setup. And then copying those transforms over for FK so that when you toggle between the two, it all just works. And then we get into limbs. It goes on and on. This is an incredible resource and I'd love to see what people do when they deconstruct it to try and create these level of characters in something more than just this lovely Meerkat. Additionally in this Meerkat, this guy is animated in a control rig with these controls. He does have full facial curves. And we have implemented the face in here, just because we are focused on getting the body control rig represented. But you can expand this yourselves. And in fact, I've seen some examples in the community who have already done this, driving the face curves themselves. In Control Rig, you can go to Window Curve Container. It'll bring this up. In this case, we haven't imported the curves. But you can always right click and either add a group and name it your own-- and you can use that curve for whatever you'd like-- or you can import a curve from your Skeletal Mesh. And it'll bring in-- I'm not going to do it now because there's a ton of them. But it'll bring in all the curves for you to drive. Let's see how long it will take. Let's go. That was really fast. Good job, Helge. I can right click here and say set curve value and choose a curve [INAUDIBLE]. So we do have auto compile that compiles most changes that you do to the graph. The auto compile won't compile hierarchy changes. You need to manually compile hierarchy changes. And if you add or remove curves, that may be true for adding and removing variables as well. HELGE: Yes, I believe so. JEREMIAH: Yeah, so now that I've recompiled after adding the curves, I can just choose something. Let's do jaw open. That's an easy one to see. And very quickly-- oh, there we go. Very quickly adjust my jaw. In fact, let's take this one step further. And close this. I should be able to do some procedural motion here. That looks awful. Well, I can fix that real quick. I'm going to right click on that pin and add interpolate. And I think this is stuff that I talked about last time, as well. And you can see there's a little bug icon there. That's good. Let it interpolate on a pin. And in here I can now clamp that range, incoming out of 0 to 1. But I'll just clamp it-- sorry, incoming I have minus 1 to 1 since it was assigned. And I'll clamp it 0 to 1 and we'll see it just open and close. GREG: Something I want to mention, as well-- while you're manipulating morph targets and their curves, you can also create material curves in your Skeletal Mesh and drive material parameters, if you wanted to, as well. So if you wanted to use Control Rig to change some sort of color or some sort of a texture within your materials, you can also do that. JEREMIAH: Yep. Very true. HELGE: Yeah, the one thing I want to add here is just-- it might be a bit late, but I feel like some viewers might not know that curves here actually refers to the float values that drive morph targets and other things. So we're not talking about bezier curves or NURBS curves. This is something that, when I started, I think confused me quite a bit. So we call curves here the things that, in the animation Blueprint, are also called curves, so morph targets or other kind of float values used for information. JEREMIAH: That's right. If I open up the Skeleton and look at my Meerkat, you can see anim curves here. And this represents all those curves. So this open is the curve that I was driving before. And these toggles represent whether it's a work target or a material curve. So I can create material curves, create a parameter in my material with that same name and drive that. All right. So additionally, in this graph-- GREG: I believe it's over on the-- JEREMIAH: In fact, this is a great opportunity for me to show you can use Find Results. So when you have these massive graphs like this, I can search for backward in my Find Results. And it'll show both my backward solve node, I could double click there and it'll take me, or it'll show me the comment, which has that name, and it takes me to that whole comment section. So this is a really great way to navigate your graphs. And this is the same behavior that you have in anim Blueprints. All I want to point out here is this also has full back solve. So taking the same thing that we did before on the mannequin and taking it to the next level. I'm going to go and close this. And I've already opened up our master level and our master sequence. So that's what we see here. And this is incredible. You drag through and we have our Meerkat with a full fur set up. I'm just so amazed by this. Anyways, enough of that. I'm going to just bake a small section. We don't need to do the entire thing. And I'm going to go to my Meerkat Blueprint. I'm going to right click. Bake to Control Rig. And choose my Meerkat. I will not use keys. I'll just do one to one. And now I have my Meerkat fully baked on Control Rig. And I can start manipulating this guy. I'm grabbing my controls over here. All right, guys. I can't do it anymore. VICTOR: Hey, nice little tips and tricks in the middle. JEREMIAH: I have invert my middle mouse pan. I'm one of those guys. We'll see if chat explodes over that. Oh, there we go. So much better. I tried. I tried. So once I baked that, a couple of things happened. And I didn't mention this so much before. The anim sequence we now see is greyed out. And I right clicked. By default, whatever I bake my bake to Control Rig, it deactivates that anim sequence. If you ever want to get it back, you can just turn on active and you can click on that Control Rig and delete it and you'll be back to where you started. So it's non-destructive. And another thing I showed here is it will automatically bake between the region that you set. So in this case, I only wanted to bake these 100 frames or so. And so I moved my start end to that section and then baked. And now I just have that section. All right. And now I can drop down in Sequencer and see all my controls available. Also, when I baked, I now have my animation mode, which you can get to via Modes, Animation, or it turns on automatically when you bake. I have my control hierarchy. So I can go to Controls directly in my hierarchy. I can click on Controls here in Sequencer. And then I also have-- this specific part isn't new, but cool to show. I also have the channel output of where my control is. So this is where I would type in new values if I wanted to do it that way. We also have a settings control here. And the settings control, I think, is just a location, rotation. So it's not a full transform, but it's a position in space. And under it, it has a bunch of Booleans, or bunch of float values , actually. So this is a great way to demonstrate kind of parameters or attributes that people are used to seeing. Here you can see them all located under my settings node by their own names, by their control name. And let me see if I can grab something, tweak it so it'll make sense. Now I can also search for things. Here let's do this one. I think we animated the eye cam. There's a lot in this rig, by the way. So let's go ahead and pause this just to un-root. Yeah, so I can tweak my animation. It's not the most incredible tweak that someone can make, but-- I think this guy lowers and raises the entire body, if I'm not mistaken. And I can go to my Curve Editor. And I can continue to do all of those manipulations here, as well. It's a really powerful tool. I'd love for everyone to download this project, take a look at it, not just for the Control Rig that would provide it, but for all of the tech that we're showing for this project. There's so much to share, not enough time to share it. We've already been doing this for two hours. We could spend two hours just on this project, just on this Control Rig. But yeah, I think with that, that goes to questions. I want to pause there. We went through a ton of stuff. So even the same people are watching and still have questions. I'd love to get an opportunity to answer them. VICTOR: I believe I'm up to three pages right now and-- [INTERPOSING VOICES] VICTOR: So yes, Jeremiah, there are plenty of questions. And we shall try to get to as many of them as possible. I've been trying to categorize a couple of them into more generic topics that have been asked several times. But before we dig into that, let's simply just start from the top. Can we go back to grid view and then you all can see our pretty faces. We might be digging into some of the screen share again, all of you on the call. If you do, just give us a moment so that we can switch over when you're demonstrating. Thank you all, first. That was great. I think the amount of questions really shows how much interest there is in the tool, and also that there is still a lot to learn. loolarge asked, is it possible to export point caches from animation made in Unreal? JEREMIAH: Point caches as in vertices? [INTERPOSING VOICES] JEREMIAH: Or just general transforms in space? HELGE: Do you mean like alembic, probably? Like, once you have the animation, can you take, I guess, the vertex positions and animate the-- export them to alembic? JEREMIAH: So I'm going to answer this in a couple of different ways. Control Rig right now does not deal with specific deformers, if that's part of the question. So I'm getting asked this question a couple of different ways. One, Control Rig isn't dealing with deformers or alembic caches, that type of thing. We're manipulating transforms in space, whether those are bones or something else. Due to the way that we set up Control Rig, you can pass a lot of information into Control Rig, including transforms. And so if the question is something around, can I feed in the positions of my VR controllers into a Blueprint to drive Control Rig with that, the answer is absolutely you can. If the question is can I feed in vertice positions and automatically place bones, the question is no, not at this point. HELGE: And also to the alembic thing, in case you were looking for doing the rigging and all this stuff in here and then exporting the actual vertix positions for some other use, like offline rendering, I don't know. I don't think we have alembic export right now. I know we have import plugins for it. But I don't think we have exports for out-- [INTERPOSING VOICES] HELGE: Yeah, I don't actually know. GREG: No, but if you wanted to just extract the data out, you could bake it to an animation sequence and then export that as an FBX. JEREMIAH: So overloaded question. I don't know if we answered it. VICTOR: There's going to be more of those. jordanariel04 asked, when using Control Rig with Sequencer, it overrides the Animation Blueprint. Is there a way around this? GREG: I'm guessing that they're talking about having the Animation Blueprint running with like authoring in some way in Sequencer. JEREMIAH: Yeah, so if you're animating in Sequencer, generally you're the one creating the animation and the poses. But if you want things to still be happening with the Animation Blueprints, you can add a post-process Anim BP onto your Skeletal Mesh. And that can allow you to do things like post drivers or adding in physics asset nodes, et cetera. So that gives you a lot of control to build up. But if you're talking about using Sequencer-- yeah, I think that's a good answer for now. I don't know if I directly answered the question. Looks like Helge might have more to add. HELGE: So basically you answered it correctly. So basically, when you use Sequencer on a Skeletal Mesh, the anim instance is overwritten by Sequencer to be a Sequencer anim instance. So anything you had on a Skeletal Mesh will be gone. However, the post-process approach is really good. That's the way that I would recommend doing it. So have Sequencer drive most of it and then have procedural animation coming in and an animation Blueprint stored in a post-process one. JEREMIAH: Yeah. And something cool about that, too-- we showed here just a bunch of Control Rigs doing all the work, a single Control Rig doing all the work. But in that type of layered approach, you can have an animation Control Rig animating your character that you are manipulating in Sequencer and in the Level Editor and making some sort of animation. And then you can have a post-process anim BP that has another Control Rig that does all the procedural stuff. So it could do like your pistons and maybe like moving the shoulder pads out of the way when you raise your arms. And so you can have multiple control rigs that serve different purposes and combine them all together using anim BPs and Sequencer together. VICTOR: All right. Let's move on. E_Frame asked, is the Sequencer window going to stay the main animation keyframe window for working with a Control Rig? JEREMIAH: Currently it is the main animation editor for working with Control Rig. That's all I can say about that. VICTOR: dcoletrainman asked, is there Python access to adding and connecting rig units within a Control Rig graph? JEREMIAH: Good question. Yes, there is. And it goes beyond that. You can use Python to not only connect your rig units-- and I said rig units, so someone's familiar with this. Nodes in Control Rig, by the way, are referred to as rig units. You can use Python to connect up, to create those nodes, to place them in your graph in a visually appealing way. You can also use it to create controls and bones in your rig hierarchy itself. So you're not limited to only building logic, but also to constructing the hierarchy that gets driven by that logic. And we are working on documentation right now for Python and Control Rig that is in the works. VICTOR: Cool. Maybe we'll do a stream on that someday. JEREMIAH: Look forward to it. VICTOR: Jason Osterday asked, what is the preferred process for duplicating execution stacks slash rigs to new meshes and characters? JEREMIAH: Can you ask that again? VICTOR: What is the preferred process for duplicating execution stacks slash rigs to new meshes and characters? JEREMIAH: There's a lot of different ways to do that. And just highlighting your controls and your graph and pasting it into another Control Rig works really well if you want to take chunks of logic. In fact, that works really well for copying and pasting your rig hierarchy. So if he wants the controls that are nested inside of a hierarchy and controls that are outside and pasting that between rig hierarchies, you could do that. You can even-- in fact, let me-- well, I don't need to demo. In a Control Rig, in that rig hierarchy, you can right click and say Refresh or Import. And that gives you the option to import an entire new skeleton or refresh your hierarchy if you changed your skeleton, like inserted new bones into your Control Rig so you don't have to reconstruct from scratch. So there's a lot of different options for you. And I think it depends on your case. So if you're iterating on a new rig, then I would use that refresh approach. If you're trying to create an entire new Control Rig, even just duplicating that Control Rig and importing in your new Skeletal Mesh and adjusting your control positions is probably the right approach. HELGE: Or what we've shown, which is that try to-- depending on the case. If you have, like, 15 different characters and they have completely different Skeletons, then what Jeremiah is suggesting is sort of trying to copy and paste as much as you can between them. If you do have 50 characters and they share the same Skeleton but they have different proportions, look at to using the setup graph and making it generic so you can use the actual same exact one on all the different characters. GREG: Right. And something I forgot to mention during the rig sharing demo was that if you-- especially for the craft that I had shown, that was on the mannequin. So technically speaking, if you're an indy studio or something like that that is using the mannequin skeleton as a reference, you could populate one Control Rig with that and then just have that with all of your skeleton as long as they're sharing the same names. It could be different skeletons. It could be the same skeleton, as long as they have the same root pelvis spine one, all of those bones they can all share. HELGE: Finally, I'll just say, for environments like Maya or Blender, people may be familiar with auto riggers and Python scripts that set up rigs that build bones, that do all this stuff. All the same pipeline typeish approaches could be deployed here, as well. Like, you have full Python reflection. You can create a new Control Rig, create a hierarchy, create all the nodes. So if you're looking into-- I have a show and I have 20 characters to rig, you might as well rig it one once regularly and then start putting in Python scripts, as well, the way that you might do it for my other environments. So same thing possible here. VICTOR: Emilche asked, is it possible to access variables in a Control Rig from an Editor Utility Widget, or would it be better to do that in C++? JEREMIAH: To access variables in your Control Rig. With-- Greg? GREG: You can. You would be able to. Hang on. I'm thinking on the spot here. Yes. If you were to pass it down as an object, yes, you would be able to do it. You can actually, with editor utility widgets, you can actually perhaps create a picker for your character, as well. So for studios that are used to having a bunch of characters and then they have pickers for similar characters, similar bipeds. You could also follow that same route with editor utility widgets. So for example, variables for IK/FK matching, perhaps, or turning on and off of control visibilities, et cetera. VICTOR: gilhacco asked-- let's see. We've covered this already. Let's see. TheGuyNUKER asked, are there any animation tools like tweeners planned for faster animating? JEREMIAH: We are actively working on improving the animation experience. And so I'd say look forward to hearing more from us about that later. I got to add one more thing. Not only is Python available directly in Control Rig, but it's also accessible Sequencer, along with editor utility widgets. So it is possible right now to write some tools that can give you some of that behavior. VICTOR: Black Fang asked, can this be used to retarget animations? Retarget Manager tends not to produce usable result, meaning we always have to go external software when we want to stock animations from the market. JEREMIAH: That is a good question. We've done tests with using the full body IK node, for example, for retargeting. There's a lot of different approaches here. As we saw with the rig sharing demo, that's kind of an example of retargeting. And you could apply more logic to it. Yep, that's how. VICTOR: M Homde asked, can this be integrated-- OK, so now we're getting into something we got a lot of questions around. So let me try to rephrase this in a general matter. A lot of people are asking in regards to combining physical animations and other ways to use collision in the scene to modify the character then the meshes dynamically rather than explicitly setting up IKs to look for the ground and other various objects. JEREMIAH: So there's a few different things you could do. So since Control Rig takes-- the Control Rig node takes an incoming pose, you can do physics-based actions before that modify the pose. So you would have-- in your anim Blueprints, you would have a rigid body node. And then you'd have your Control Rig node. You have that order of operations. So the rigid body could do whatever you'd like it to do to modify the pose that Control Rig can do. Or you can do things like creating an actor BP that has some sort of physics simulation that's outputting transforms. And those transforms can be fed into Control Rig to drive it with whatever method. So there's a couple of different ways to approach it. So you can build a really low res skeleton cage that has rigid bodies that you throw against the wall. And those rigid bodies are just feeding skeletal transforms into Control Rig to drive a higher risk something. I don't know if that exactly answer the question, but it approaches it from different angles. GREG: Yeah, I think the use case would be sort of applying a physical animation profile and using that injunction with Control Rig for procedural animations, as well. JEREMIAH: Yeah. You absolutely can, especially with Control Rig component as it is and our public variables. You're able to pass data in and then layering on anim BPs for procedural kind of clean up, however you want to handle that data, you can do it in multiple ways . VICTOR: Charlie_NC asked, what is the purpose of being able to include controls slash spaces as part of the IK chains? Could you give some usage examples? JEREMIAH: I'm going to pass this to Helge. HELGE: Yeah, I don't think I understand the question, sorry. JEREMIAH: So do you have another question-- [INTERPOSING VOICES] JEREMIAH: Was the question applying what's the use of having controls or spaces in part of the IKG? You can do a lot of clever things by moving controls based off of some other logic. In fact, I think we've shared some things around this before. But you can-- HELGE: I think I realize now what he's asking, maybe. Sorry for interrupting. Go ahead. JEREMIAH: So you can apply IK on controls themselves before animator ever interacts with it. Or you can-- and rather than using bones, if you don't want to use bones for whatever reason, you can just drive with controls. There's a lot of different ways that you can interact with the rig. And this isn't something that you have to do. It's something that you have the option to do. So we tried to create the system as open as possible and give it a lot of flexibility to how our nodes are designed. But I'll let Helge take another stab at this. HELGE: So basically, the way I look at it is, within the forward solve, it doesn't seem obvious that you might want to use an IK on controls, for example, or soft stuff like that. I think it's a pretty advanced case and you might have found a use for it. But it's not obvious. The cases where it's rather obvious is when you have other events, like the backward solve or the set of events. So if you're running something as part of setting up the rig, you might actually want to run IK ones to figure out where controls need to go. And you might want to do that on the controls themselves, and especially for the backward solve. You're trying to figure out where things are. Let that be IK or any of the other motion nodes that we have. Having the ability of not running them only in bones but on anything else can be really useful when you're setting up backwards, basically. That's one of the reasons why we changed this implementation. So you can always do everything to everything, basically. JEREMIAH: Yep. VICTOR: Finishing a message. All right. Scrolling back up the list. Jason Osterday asked, do you have interop plans to exchange rigs with Maya or other DCCs so that there's parity? Would you force Control Rig? JEREMIAH: That's a question we received a lot. I don't have an update on that right now. But it is something that's been asked and we're definitely aware of that request. VICTOR: maddiealso asked, is there a way to enable or disable parts of the Rig Graph at different LOD distances? JEREMIAH: There's not currently a way to enable and disable parts of the Control Rig graph. Well, I can think of ways. So one way is you feed in an LOD index into Control Rig and then use braching to enable and disable. So you could do it that way. But anim nodes, by default, have this LOD threshold. I think that's kind of what he's asking. So the LOD threshold will automatically enable or disable anim nodes. Control Rigs acting on a full hierarchy that it owns entirely doesn't quite have that same logic right now. That's something we can absolutely consider. But I would recommend passing in an LOD and controlling the behavior of that through branching in Control Rig for vertices. HELGE: Yup. GREG: Yup. JEREMIAH: Unanimously. VICTOR: Sergio G asked, can you talk a bit more about what you envision for consolidating nodes? Can there be an arm node, a canine hind leg node, a chicken leg node, et cetera, where the controls just appear? JEREMIAH: Probably not a chicken leg node, but possibly-- more serious answer, it's something that we know is needed for Control Rig is something that we've looked into. For 4.26, that's not something we have. But we definitely recognize the need. VICTOR: ARMRgarden asked, is it possible to add face bones for expression? JEREMIAH: You can add-- [INTERPOSING VOICES] VICTOR: There was a follow up question later on. Let me find that. JEREMIAH: We also demonstrated in the Meerkat how we have curves for expression. Those could just as easily have been bones, just like if you drive a finger, you can drive a jaw. VICTOR: Can you edit or add bone complexity in Engine? JEREMIAH: You cannot currently modify a character skeleton in Engine. But a Control Rig, you're able to create custom bones. Those custom bones are purely for calculating an output pose. So you can't use those for deformation, like skinning vertices to that. So if I'm understanding the question correctly, no, you cannot modify the skeleton itself in Engine. VICTOR: brimblashman asked, is there a way to make the viewport behave more like Maya slash Blender instead of the FPS slash walk mode when animating? JEREMIAH: That's kind of a higher level Engine question. I'm sure that we're always looking at different ways of interacting with the editor. As we get more and more into not just building levels but authoring full animations in the Engine, we're continuing to have conversations, discuss with our community how we can improve that experience. So that's an ongoing conversation and something we're actively looking into. VICTOR: There are some more controls. So you can hold right click to move in and out. JEREMIAH: Absolutely. And in fact, I have a top trick around that that I can talk about if I can share my screen again. VICTOR: Yeah, if we can get Jeremiah on the big screen. JEREMIAH: And all I'm going to do is drag in-- so all I did is I dragged in a Control Rig in my mannequin Control Rig. Here. Dragged it into my editor. VICTOR: Hang on, Jeremiah. You're not full screen yet. JEREMIAH: Listen to my voice. VICTOR: Houston, come in? Come in, Houston. Houston's not responding, guys. We're going down. JEREMIAH: Got a lot going on. VICTOR: Yeah, let's see. VICTOR: Liam, can we get Jeremiah full screen, please? JEREMIAH: That's my editor summed up. So let's see. VICTOR: Yeah, the quality. We did get you full screen literally that moment. JEREMIAH: Perfect. That's great. Well, it promises to be. So of course my internet hangs up right when I want it shown. But I will just talk over this and tell you what I was going to show. I can drag a Control Rig into my editor, which looks like this right now. And that'll automatically set up a level sequence on this. It'll automatically set up a level sequence in the control slot. But interacting with the editor, I also have some-- hey, it works. All right. Let's do this. I'm going to drag by my Control Rig in. It's automatically going to create a level sequence. So I'm going to start animating. And I have my rig in here. Top tips two and a half hours in. Now we're getting into the good stuff. When this opens, go into your animation pane. At the bottom, there's an animation drop down. And check Only Select Rig Controls. This is the best checkbox that you can check. And then make it so I can't select my environment anymore. I can only click on controls. So when you're animating, it's super helpful. Next, in your editor preferences, you can-- I'll pop it over here-- I believe you search for an arc. I can never remember the name of this. Arc ball rotates, so it's actually a look and feel. In level viewport port, there's enable arc ball rotate. And there is enable screen rotate. You also have this combined Translate and Rotate Widget , which I prefer not to turn this on. But these two are incredible. They make it so that as I click on these objects now I can rotate screen space or I can click in this middle and rotate dynamically my controls that way. I found this really helpful as I'm animating. It makes it a lot easier to animate a little more similar to how you're seeing in other DCC packages. VICTOR: Super helpful. All right, Cinematography Database asked, can we set morph targets in Control Rig, or is that better to do in the Animation Blueprint? JEREMIAH: You absolutely can. If you're available for that Meerkat demo, which I just closed, I actually was dialing on the jaw open and close through curves. So when you say morph target in kind of real speak, we're talking about curves. And so as I import curves for my skeleton into Control Rig, again, let me just open this up and show where we would do that. All right. I can go into Window, Curve Container. And I can right click and enforce curves from my mannequin. So let's just grab my mannequin here. And so I just have a Blend Orients on this guy. But if I had morph targets on my character, those would show up here. And in order to drive them, I just create a new set curve value. And I could drive my curves that way. So this just takes values 0 to 1. And as I mentioned before, you could do that with materials as well. VICTOR: Awesome. Joshua Cohen asked, I think the future of computer animation will involve machine learning slash AI for many things. Are there any plans to incorporate new feature sets utilizing those techniques in UE? JEREMIAH: I can't speak to all of UE. I can speak to Control Rig. That's not something we're actively developing right now. But we're always looking at new possibilities for making it easier to create rigs and author animation. So we haven't ruled it out. VICTOR: Mark Fitzpatrick asked, will there be a Maya rig export plugin that converts your rig to a Control Rig? Did I already ask that? JEREMIAH: That's similar to the, can I import my Control Rig into Maya question. And the answer still stands. It's a request we've had. It's something that we're aware of and we're putting some thought into. And to piggyback off of that, Helge kind of alluded to this when we were talking about Python. And it's something I've encouraged people to do. If you're already building a Maya rigging package, for example, if you create some sort of abstraction of those, then you can build Control Rig modules that mirror the Maya modules and use that same data to construct a Control Rig and construct a Maya rig or a Blender rig with that same data. So that's the path I'd recommend, at least for 4.26, that we're talking about here. VICTOR: AllAboutAnimation asked, as a rigger in Maya, what's the advantage and what would make me transfer from Maya to Control Rig? JEREMIAH: Yeah, that's a great question. I'll put on my little sales hat here. What I was talking about earlier with our initial Control Rig, that example-- I don't know if my screen is still being shared. But I'm just going to open up a map. One of the key advantages is being able to animate in context and iterate in the environment that you're working in. So if you're doing cinematics, linear content creation then you want to be able to animate in the environment with the right lighting and effects and everything. So in this example, I'm able to animate in my chair-- [INTERPOSING VOICES] VICTOR: Let's hang on. [INTERPOSING VOICES] VICTOR: Yeah, I don't have controls anymore. Houston, can we please-- JEREMIAH: It still stands. [INTERPOSING VOICES] VICTOR: You're full screen. JEREMIAH: OK. When we're looking at that Meerkat example, that entire terrain is built in the engine. And to be able to animate to that terrain is super important. You don't want to have to recreate that terrain, bring it into Maya, animate to that terrain, and then, oh, the designer tweaked it in the engine. Or the animator tweaked it in Maya, and then get this disparity. And also in things, again, with that Meerkat, which is a great example, it just includes things like fur adds those to the runtime elements, you'd have to duplicate that effort in your DCC. And it's easier to do things in one place. Now, that doesn't mean that our goal here is to remove Maya or bush builder or Blender from your pipeline. But we're trying to make it easier for you to iterate once you are in Engine. So if you want to just quickly clean up some animation or tweak an animation for a specific purpose-- maybe you want to do your aim directions in Engine just real quick based off of your animation prototype. You can do that. You can also-- we have lots of different ways to author animation, feeding in different vocab solutions, like a Vive or Xsens suit and drive your character directly. And you can bake that animation that you're feeding onto Control Rig or onto your skeleton back into Maya to iterate again. So Helge referenced this a little bit, of using Control Rig and using the Engine as a tool. It doesn't have to be your end all, be all solution and final pixels-to-screen with this animation. And Control Rig doesn't have to be your final rigging solution. But you can do some really cool clever things in there that can generate motion for you that you wouldn't be able to generate otherwise and iterate really quickly on those. All right. Toss my sales hat off. I didn't even use my screen for that. I just talked to the camera passionately. VICTOR: We looked at the table and chairs we've seen for the last, I don't know, six years. JEREMIAH: Anytime. VICTOR: inu_games asked, are there plans to add more coalition nodes to Control Rig? JEREMIAH: Collision nodes? Also, Enu Games, awesome stuff that you're sharing on Twitter. Love all of it. If by collision you mean the sphere trece, I think that's something that we're exploring. We wanted to provide an initial implementation. But we know that there's a lot more methods available in other areas of the Engine. So we've definitely called that out. But if you're talking about collision in other methods, or if you're speaking specifically about that node and the collision profiles available to you, that's also something that we recognized as a need and something that we're looking at expanding. VICTOR: Making sure I get some of the new questions here. aadtwitch01 asked, is Control Rig suitable slash ready for quadruped character animation? JEREMIAH: There is no limitation to the type of characters you create with it. We've already seen people create very cool quadrupeds with Control Rig. Why stop at four legs? You can do as many as you like. VICTOR: All right. You all good to keep going on for a little while? We have more good questions. GREG: Yeah, that's fine. VICTOR: All right. Just making sure everyone is OK. Karl Fredberg Sjöstrand asked, is it possible to resize the control gizmo in the preview with a transform gizmo? JEREMIAH: Good question. I think that was something that was called out and-- it's something that we definitely recognize. So the question, if I'm understanding correctly, is right now, in order to change the gizmo look itself-- as a matter of fact, you still see my-- you have to go into your gizmo transform here. I don't know if my screen is being shared. You have to go to your gizmo transform and Control Rig and type in values. VICTOR: I think we want to see this. Can we get Jeremiah full screen again? There we go. You're good. JEREMIAH: Well, that was perfect timing. It's like every time my screen gets shared-- HELGE: Bad luck. JEREMIAH: All right, well, anytime. Happy to help. VICTOR: We'll get back to that one. I think it's useful information, because if there are actually exposed variables for that, it would be cool to show them. We'll move on for now. We'll get back to that. And then there was a couple more questions. And you tackled this a little bit already in terms of using a live mocap shoot and pipe that data straight into a Control Rig. Do you have any examples of this or anything rather quick you could show during the stream now that we'd be able to cover? JEREMIAH: I don't have a good example of this right now. But to give a quick idea of how this would be done, Grant's example of this robot here is actually taking an external input of the actor position and driving an IK effector with it. So if you take that basic principle and expand upon it, you can take multiple inputs of IKs, head and arms and feet, and feed those into effector positions in Control Rig, or even our full body IK SL rig in Unreal 4.26 to drive a full character pose. HELGE: So it's also-- there's also-- I've just checked if it's shipped with 4.26. So there's also a plugin that is well experimental, which is called Live Link Control Rig, which exposes Live Link access directly within the Control Rig graph. So this is not something I would recommend for the general case. But if you want to experiment with streaming poses directly into a rig, you can do it that way. You can actually get some nodes, get the subject in question, and then pick the right bones. But it's quite manual and granular. But with looping now, you can actually build some pretty sophisticated small graphs that copy mocap pose onto your character or onto controls or onto something else and then iterate based on that. If it was me in production, I would probably make that a branch that you could-- in the rig, they can enable, disable. So that way you have part of the rig that can receive mocap or you can turn it off if you want to just animate on the rig. VICTOR: All right. Emilche asked, will there be any tutorials on how mapped elements works? JEREMIAH: I believe we're actively working on some documentation around the Control Rig component. So look for that coming. I don't have a date on it. But we're actively working on the documentation for that. VICTOR: Yeah, there was another question just came in. What's the earliest Engine version Control Rig supports? GREG: 4.20. JEREMIAH: 4.20-- well, probably 4.24 is the first I would recommend to use Control Rig. But the samples start at 4.25 and the latest is 4.26. They are not backward compatible, because we introduced pretty major paradigm shifts. [INTERPOSING VOICES] VICTOR: Yeah, it's been actively developed for a while. And it's only fairly recent that the tool is production-ready, right? JEREMIAH: It's actually currently not production ready. It was experimental at 4.25. But at 4.26 is changed to beta, which basically means that as we ship, we are not changing the core underlying structures. So we are maintaining backward compatibility and trying to keep things as stable and consistent as possible. A preface on that is Control Rig has been used actively in Fortnite for the last few years, is used in other games, as well, that have shipped. So we do our very best to keep it in a stable state. And although it doesn't quite have the production ready label, I highly recommend people dive in, look at it, and start using it to your heart's content. VICTOR: Inu_Games asked, can you access variables of a control rig used through Control Rig anim graph node like you access nodes of a Control Rig Blueprint component? JEREMIAH: Yes. And Greg demonstrated that on I think this robot demo. Is that right? GREG: Yes. I'm not sure if my screen-- JEREMIAH: So in order to do it, all you have to do in your Control Rig graph is to press a little eye next to your variables to make it public. And then in your Control Rig node, anim node, in your anim Blueprint, you're going to check the pin-- the use pin next to the name of the attributes or the variables. If we're able to share Greg's screen, he could show that real quick. VICTOR: Yeah. We're full screen, Greg. GREG: OK, cool. So yeah, I have some variables that I've exposed with the eye icon. There's additional settings that you could do for your variables. In my anim BP, when I have this Control Rig node, I can just turn on this use pin. And this is also active in time. So if I created a new Boolean variable and turned that on, then compiled, and then I go to the anim BP, I can automatically have that exposed and available to me. VICTOR: Awesome. Inu_Games has another question. Is there a way to show Control Rig debug widgets, like pull vectors, et cetera, in the level? JEREMIAH: Not debug widgets, as in the visual debug, currently, though that is definitely a common ask and something that we're working on. But there are other ways to-- I'm assuming at this point we're talking about runtime, so when we're in pi. I'm thinking on the fly. So while I'm thinking, we can ask another question. VICTOR: For sure. Also another question from Inu_Games. Are there plans to integrate Control Rig and Anim Insights? JEREMIAH: It's a good question. Anim Insights is, for people who don't know, a new debugging framework available, I think, in 4.25. Anim Insights right now dives into Anim Blueprints, I think degenerate poses, along with a lot of our other systems. We don't currently have it integrated with Control Rig. But the general-- how do I say? Debugging in general in Control Rig is something that we want to make a lot easier. And we're looking at a bunch of different ways to do that. But nonanswer. VICTOR: Cinematography Database asked, is there a Live Link node in Control Rig? I'm doing that in anim Blueprint still right now. JEREMIAH: I think Helge just answered that with the-- it's not production ready. I think it's an experimental plugin that's called Control Rig Lifelink available for people to get or to-- HELGE: If you enable the plugin, the nodes will start showing up. And then you have the same sort of introspection. It's beginning subject, getting the poses and everything out that you have accessible to you and a node. GREG: There's a lot of different ways that you can pass Live Link data down to-- or just any data, whether that's control or Live Link or any additional inputs down to Control Rig, whether that is inside Control Rig, in a BP, or to a Control Rig component. For editor use, I would recommend going more towards the Control Rig component route, because you have a little bit more control that way. But explore all the ways that are possible for you. VICTOR: Can you convert-- sorry. Beneviolant asked, can you convert-- sorry. Can you convert your baked Control Rig animation into an animation sequence? JEREMIAH: Yes. Absolutely. HELGE: Yes. JEREMIAH: So I didn't demonstrate that this time, since I demonstrated that in our previous stream. VICTOR: We can just go ahead and drop the link then. JEREMIAH: Great. VICTOR: Because we got a couple more questions to go through. Make sure to get that in chat. muchashca asked, are in Engine weight painting tools something the team is planning in future updates? JEREMIAH: For this team, we're focused on Control Rig primarily modifying transforms. A deformation in general is something that is a common request and something that we're always looking at. VICTOR: Got to make sure I actually grab that link and paste it in the chat. There we go. And on YouTube. I'm not going to forget about you all. All right. Now we're getting to the questions that are really exciting. Sathish Koththolla asked, will we get any default facial rigs from U4 for just a UE4 character, just like the skeleton? I would point to the Live Link app documentation and how you can go ahead and use-- [INTERPOSING VOICES] VICTOR: Yeah, how you can go ahead and use kite boy. Kite boy does come with a facial rig. I think that-- JEREMIAH: That's our current best that we have available. VICTOR: Andre Wells asked, will Control Rigs work with USD. The USD file format, I assume. JEREMIAH: So that's very similar to the question about exporting or importing control rigs through-- into Maya. And I'm assuming that that would be the expectation. I don't think that's something that we've tested-- well, we haven't used USD on Control Rigs and we haven't brought it out of the Engine. So if that was the expectation around it, then the answer is no. Kind of a rough answer, but-- VICTOR: Better than none, I guess. Garrett Blaine asked, is it possible to drive groom splines with Control Rig? JEREMIAH: Groom splines. Groom splines right now are attached to a Skeletal Mesh to a location on a Skinned Mesh. So I think that falls a little bit under the deformation side. And currently we're not driving deformation in itself with Control Rig. That's an interesting thought. VICTOR: Yeah. Let's go back to the-- you want to show off how you can resize the control gizmo-- [INTERPOSING VOICES] JEREMIAH: Am I ready for that? VICTOR: Are you ready for that? JEREMIAH: I'm not. But I will talk about a node that exists. [INTERPOSING VOICES] VICTOR: See if we can get Greg back. Oh, there he is. Oh, sorry. It was Helge that dropped. He did mention his internet was-- JEREMIAH: Sure. VICTOR: --iffy. Houston, Jeremiah full screen, please. Now I'm going to have to keep referring to them as Houston. JEREMIAH: It's official. VICTOR: Just the way it makes me feel when I'm telling someone else to do stuff online. Cool. Just a moment. That is Greg's. There we go. You're good, Jeremiah. JEREMIAH: OK. So I'm not quite prepared to set this up fully right now, because there is a little set up involved. If you go into actors, you can search for Control Display Actor. And Control Display Actor gives you the ability to draw the controls themselves in a Py session. So again, I'm not prepared to actually set it all up right now. But essentially what you would do is you would choose your actor to track. You can populate this in your Level Sequence and Blueprint. Or you can do it manually. And the Control Rig class, too, follows. So in this case, it would be-- I was going to do our slope warping Control Rig. But since my actor has spawned at runtime, I don't want to write the Blueprint code to [INAUDIBLE] this. And then you can drive whether it's visible or not through this actor hidden in game. One key thing to note with this is, if you want it to be overlaid on your actor, then you probably want this to be parented under your actor. So I'm just going to fuss around and see if I can do this, which I [INAUDIBLE]. Let's see if it's going to get me this guy. There we are. And I don't even know where this is. Go ahead and zero this out. I don't quite think this is going to work, just with this set up. But if I were to set this up correctly, I would populate this actor to track at runtime if my character doesn't exist. And in fact, this might work now that I'm thinking about it. I'm going to go to Greg's runtime demo. Please don't crash. It's like only when my screen is being shared does [INAUDIBLE]. So since these are placed in the world, I should be able to do it. So I'm just going to drag this in. I'm going to drag it under robot actor. I'm going to zero it out so that I'm in the same location. Then I'm going to take this and track robot our first one. And this is [INAUDIBLE]. See if this works. I don't know what controls they actually have in here. So I don't know if we're actually going to see anything. Yeah, I think we're driving bones, primarily. So that's my awesome demo of how theoretically you could see controls. But what we would expect to see if there are full controls on there is you'd see the controls moving around in [INAUDIBLE]. And again, there is an ask regularly that we add in maybe a command line or something that makes sense. Yeah, so there's not much of a control. I can try and make this guy bigger. Let me stop there. While I'm doing this, I'm actually manipulating the gizmo, which there was a question around that earlier. I think right now, if I may inflate this setup mode, it's actually going to manipulate the initial transform or the offset. HELGE: There isn't a way to do that right now. But that's all you get. You currently have to go into the Gizmo in the Details panel. JEREMIAH: So what you could do is you could resize copy and paste into your gizmo. Go back. All right. [INTERPOSING VOICES] JEREMIAH: 10? HELGE: Sure. JEREMIAH: Let this play again and see if I get anything. I don't. Well, that's as far as I'm going to debug-- VICTOR: Yes. We will try to tackle that afterwards. I have had this happen before where the guest goes offline right at the moment and is like, oh, I know how to do it. If that happens, Jeremiah, feel free to jump into the forum announcement post for the livestream. That's generally where the conversation happens once we are no longer live. Please make sure you check that out and you can continue to ask questions and discuss topics related to today's topic. I have another question from Cinematography Database. And I don't know if this is going to be the case, but can you do a quick overview of inversion logic for pole vector, for example, elbow. JEREMIAH: Yeah, there's a couple of ways to do this. So since you already have the pose itself-- and let's, in this case, pretend that the animated pose is planar. So you don't have a twist along one of the limbs of the arm. There's a lot of different ways to do this. You can do something very basic, like project directly off of the elbow joint a couple of units, or even have the control set to the position of the elbow. And in that case, the control will always be relative and on the plane of your basic IK. It could also do more complex logic, like calculate the midpoint between your shoulder and your wrist and then project a point from the midpoint through your elbow and stay along the plane. There's a couple of different ways. But when I do something really quick and dirty, I essentially attach it to my midbone, my elbow. And I offset it by a couple of units along x, usually-- I don't know if my arm is visible. But as if I had a spike sticking off the back of my elbow and I just attach my patrol 20 units off. So that would be-- if we're talking in the nodes, it would be get the transform for my-- or get the position for my elbow bone. Add 20 units to x and feed the results into my elbow control. VICTOR: Thank you, Jeremiah. With that I'm going to-- we're almost at a hard cutoff, 5:00 PM Eastern time here. But I did want to ask-- Toekneemonsterb asked, how can we replicate the annoying cycle check errors from Maya in Control Rig? JEREMIAH: How can we replicate it? HELGE: You can't. I'm sorry. I mean, there's a lot of things that are not quite done, it looks like. But we got the cycle stuff under control. That's for sure. VICTOR: All right. And with that said, I want to thank you all for coming on and sticking around for the long Q&A. I will make sure to send you all the questions that we received in case there were any that you thought were good that we didn't ask today. Beware, it's a long list. But really appreciate it. Chat, please give it up for our guests today. It's been a pleasure having you on the show. It's very exciting to see the future developments of sort of animating an Engine. The closer we get to one tool rules them all sort of mentality, less skipping between different DCCs and Unreal, it's an exciting time to work with the tools. Is there anything you all would like to leave chat with before we sign off today? JEREMIAH: Thanks so much for joining us for this whole thing. It was a long stream and we had a lot to share with you. Really exciting to share it. And thanks, Victor, for the opportunity. VICTOR: For sure. Any time. You have my email address. [INTERPOSING VOICES] JEREMIAH: --behind the scenes. HELGE: Thank you for having me. VICTOR: Cool. With that said, next week, we are going to cover the Asset Manager. Ben Siegler's coming on to do a pretty good explanation for us of how to use it, what it's used for, and the mentality behind it. Make sure you don't miss that. If you are excited about how you can optimize the use of data in your projects, do want to go ahead and mention, as well, that if you are streaming on Twitch any kind of Unreal Engine content, make sure that you use the Unreal Engine tag so that we can follow along, check you out. And if you are streaming during the day of our stream, we might even go ahead and raid you, which I think we might be ready to set up to do. I saw some recommendation earlier, so we might go ahead and do that. If you're new to Unreal Engine and game development in general, make sure you check out unrealengine.com. You can download the Engine for free. If you already have the Epic Games launcher installed, you can just head over to the Unreal Engine tab, click it. Download latest version, 4.26.1, which we released yesterday. Yep? No? Two days ago? I have no idea. It was one or two days ago. Right now at times it feels like, time, what is it? I don't really know? [DOG BARKING] Hey! And with that, my dog really needs to walk. So I'm going to say goodbye for now. We will see you all again next week. Take care everyone. JEREMIAH: Bye, everybody.

Channel: Unreal Engine

Views: 165,448

Keywords: Unreal Engine, Epic Games, UE4, Unreal, Game Engine, Game Dev, Game Development

Id: UyCziUcnqxM

Length: 181min 31sec (10891 seconds)

Published: Thu Feb 04 2021