Paragon Feature Examples: Animation Techniques | Feature Highlight | Unreal Engine

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
👍︎︎ 3 👤︎︎ u/corysama 📅︎︎ Jan 19 2016 🗫︎ replies
Captions
>>Chance: Hey, everybody, and welcome back to the weekly Unreal Engine Livestream. We are your Community Team. I’m Chance. This is Alexander, and we are now presenting Jess Hider. >>Jess: Hi. >>Chance: Who is going to be heading up our community management efforts across Europe. Jess, tell us a little bit about yourself. >>Jess: Okay. I am a Scottish game developer. My games career started using indie games for mobile platforms where I used a lot of UE4, met you guys. After that, I did a little bit of triple-A work working at 4J Studios on the console edition of Minecraft, and now I’m here. >>Chance: Awesome. We are super glad to have you on the team. We’re probably going to be having her at all sorts of events across Europe. If you’re going to be out and around, you’ll find her at shows, different meetups, and all across our internet channels. Stop by and say hello, be friends. We’re going to hop into the news really quick, and then we’ll have Laurent and Ray hop on and take us through all the great animation things about the Characters in Paragon. If we could do the monitors. >>Chance: Earlier this week, we put out 4.10.2 Hotfix. This solves a number of issues that were still lingering around after 4.10.1. If you’re still working on 4.10, we definitely recommend you going to download it. Pull it down and see if your fix is in here. See if it makes your life infinitely better. We certainly hope so. Actually, give me this whole keyboard. >>Alex: Oh, take the whole keyboard. You ran over my foot! I’ve got to close the tabs. >>Chance: Oops, wrong window. Let me get back over here. Sorry for rushing through news a little bit. Laurent has got so much to show today, so we want to make sure we can get it all out there for you. Preview 2 for 4.11 is out. As you know, Preview releases aren’t really for production work. However, this is a really great place for you to get in and take a look at what’s coming and help us find out some of the issues with it so we can try and get as much as we can in before it actually releases in the coming weeks. Steven’s team - they’ve got a new post on the forums where you can check everything that’s been fixed in Preview 2. Download it; tell us what you find. We are all ears. We can’t wait until the full release is out there, and you guys have been instrumental in helping us make these as robust and bulletproof as possible, so thank you. Unreal Match 3 is a learning sample that we kicked off a few weeks ago, right before the break. We had Lauren and Alan Noon come on and talk about it. It started as an Epic Friday project where Alan was working on some mastering mechanics and it turned into a full-on game. It’s a learning example that goes through a number of different aspects of game development from in-app purchases, C++, programming, Blueprint scripting, building analytic packages - everything. It is pretty solid, and not only is it available for download in iOS, through the launcher and the project files themselves there in Android, all of the documentation Lauren has told me have all come online now. If you’re looking at making a mobile game, this is a really good one for you to understand a lot of the different specific things you’re going to want to keep in mind working on mobile. But even if you’re just building a game in Unreal Engine or you just want to get started and see what the process stem to stern actually looks like, this is an extremely valuable asset for you there. If you just want to play a Match 3 game on your iPhone, it’s free right now in the App Store, so go check it to. >>Alex: It’s very addicting. Fun fact - I talked to Lauren earlier. She just got feedback from the UX Team, so she’ll be doing an update and then explaining through some of that stuff too in a future post. That should be really good more information, and there is a postmortem. >>Chance: Even more learning. >>Alex: Even more learning. >>Chance: Lauren’s got a great postmortem about the process and how it all came together on our blog as well, so I’ll be updating it with links to all of the places you can get Unreal Match 3. Check it out and let us know what you think. Next up, Jess and I are actually going to be heading up to FIG Talks 2016 which is an extension of BFIG, which is Boston Festival of Indie Games. They’re basically having three different tracks, so it’s design, development, and business at the Microsoft NERD Center on Saturday. We’re going to be presenting a Why Unreal Engine? We’re covering pretty much end to end what Unreal Engine and Epic offers developers and some of the great things that people are building in the Engine. It’ll be a really good time. We’re hoping that if you’re at the show that you swing by. Even if you’re not planning on coming to the show, we will be there until Monday where Seth, our user group lead for the Boston Unreal Engine Meetup is throwing an event at the Jacob Wirth Restaurant there downtown. We’ll be there with everybody. There are a lot of UE developers locally that are going to show up. We can’t wait to meet you all. Bring us your projects. We really want to see what you’re working on. There’s so much talent in Boston. Every time I’m there, we’re just really blown away and excited to get back. I encourage you to show up. We’ll be there, and we hope to see you there too. Here’s the Epic Unreal Meet and Greet and Drink. It’s all on Meetup.com where you can check out more information about the event. Really quick, before we move on to the next thing, I wanted to say something about Meetup.com. Just to reiterate from the past, we do a lot of sponsorships for user groups that are all over the world, and it’s growing. We’re seeing organizers and passionate UE developers everywhere reach out to us and try to get connected to others in their areas. We offer a full support package for that whether it’s branding materials, promotion - we’ll even come to events just like what we’re doing here in Boston. If that’s something that interests you, reach out to us. Find us on some of the number of avenues that are out there. There are some Twitter names across the bottom here. Feel free to hit us up. We’re more than happy to work with anybody that’s willing to organize something locally. We think it’s super awesome, and we’d love to come visit you when we can. The last thing we wanted to bring up here for the news today is the Virtual Reality Hackathon in Brussels. I think we’re going to be there. I think Osman is going and maybe Tom Looman are both going to be there this weekend. I think it starts tomorrow and goes through the weekend. If you’re in the area, definitely get in touch with Osman, Tom, or even Juan, the organizer there. We’re hopefully going to be doing a little bit more in that space for the greater Brussels community, if you will. Apparently, it’s pretty easy to get there from the surrounding countries. If you’re there, reach out and find one of us, or if you’re a developer in Brussels, reach out to me or somebody else on this team. We’re happy to get you plugged into others in the area. I’m actually really upset that we’re not able to go to that, because that sounds like so much fun. But at the same time, Boston is going to be a lot of fun too. It always comes down to these things where they happen to be on the same day and we’ve got to make those tough decisions. >>Alex: We only have so many Chance clones. I’m so sorry. >>Chance: Yeah, two of my clones right now are upstairs writing things and monitoring the chat, and then here I am. What did you do with the other one, the fourth one? >>Alex: Shh, he died. Yeah, sorry. >>Chance: Let’s hop over to the Community Spotlight really quick before we talk about some of the great things community is doing. For anybody that’s new, every week we try to highlight some of the coolest projects that have come across our radar for the week. We always encourage people to reach out and show us what they’re working on. That’s how you end up on here, and we’ve got a running list of them on the forums as well if you want to see what we’ve highlighted in the past. There’s a number of you in the chat that we’ve shown off your project before. Alex is going to take us through what we’ve got now. >>Alex: Sure. First thing up is we have the top Karma earner of the week on AnswerHub. First thing isn't on the screen. Top 3 Karma earners of the week. Cancel, a first-time winner. Moss and Devils D, both of you already have badges, but Cancel is getting a new badge. Congratulations on that. Good work. Thank you everybody else on the list who is trying for it. You’re going to have to fight pretty hard, though. These guys are pretty competitive. >>Chance: Well, it’s funny. I’m looking at the list here too. We’ve got a number of really high earners in the past. I can see Horacio on there. Hey, Horacio. Pretty much hop on the Answer Hub. We really love seeing the community help each other out. That’s what makes it so great. We have so many people that are willing to support each other. It’s humbling to us. Thanks for all the hard work. >>Alex: Thank you guys so much for coming on and being out there with everyone. Onto the actual thing. This actually kind of happened pretty quickly last night. BananaKing932, Chris Robertson. >>Chance: Oh, I thought you were saying last night at 9:32. [LAUGHTER] >>Alex: No it was probably around 10:30 or something. He and I were talking yesterday and he said, hey, I know you have OSVR. I’ve precompiled the plugin. They have a 13-minute video instructional guide of how to install their version of it. But he’s gone on and just precompiled it and is now giving it out. It makes it a lot more plug and play. If you’re using OSVR, it’s super easy now. Thank you so much. He’s updating it for 4.10 and all that, too. He’s also in here making updates as he goes along. If you are someone who is interested in VR and you were one of the people who got an OSVR because they were 350... >>Chance: “Because I’m not some god like figure like our ‘Hero of the Peole’ Michael Allar.” I’m reading his... >>Alex: Yeah, he mentions Kitatus. He’s talking about all you guys out there that are always in the chat. Thank you so much. Good work. Next up, we’ve got a Loading Screen tutorial. This one’s actually relatively new. It’s a proper C++ tutorial series, a really long tutorial of here’s how you go through it, how you can do a nice loading screen. It’s pretty straightforward, which is what I like. You can just go in, read it. He’s got a great description. This was written by James Baxter. Thank you so much for making this awesome tutorial. >>Chance: Yeah, it’s funny. I get asked that a bit too. It’s like, hey, I want to build a proper loading screen; do you have any resources for it? >>Alex: That’s why I had to highlight it. It’s one of the most common things that shows up. It’s just, how do I make a loading screen. Here you go. Really, really easy. Thank you all so much. >>Chance: Thanks, James. Does that wrap up for Community Spotlight? At this moment, we are going to get over to the meaty conversation of animation where we’re going to see some really cool new features that are on the way. We were poking around earlier. >>Alex: Yeah, I was having fun poking at controls. >>Chance: Jess, thanks for joining us. >>Jess: Thank you for having me. >>Chance: I’m sure you’ll see her around. >>Jess: Yeah, come say hi if you spot me anywhere in Europe. >>Chance: Take care. >>Jess: See ya. >>Alex: This is why it's awesome to have these mics. >>Chance: Then we can sneak a few people in. >>Alex: They'll hear you walking on. Such a great trailer. I’ve actually watched it at home a few times too. >>Chance: This segment of these 4.11 Paragon tie-in streams has been what I’ve been excited about for quite some time now. Jay Hosfelt and Ray and Laurent and I have been talking about this for a couple months now since before the end of the year. This, for me, Animation and AI are the two parts of game development that I know the least about, so every time I see tools that make that process easier or more intuitive for me, it’s huge. I really can’t wait to see what we’re going to get into. >>Laurent: Yeah, animation is very visual, so it’s always nice to see you have some subjects or a lot of theory or math or something very abstract. But animation is visual. You can see it. It’s always interesting to watch. >>Chance: Absolutely. I know that you’ve got a project currently loaded. I think it’s down there at the bottom. >>Laurent: Perfect. Before we start showing any gameplay, I kind of want to explain the goals that we had. Obviously, when you do animation for a game, the game will dictate what you’re trying to achieve, your constraints, your limitations. Working on Gears or Fortnite or Paragon, these goals are very, very different. >>Chance: I can imagine. >>Laurent: It’s important to start by sort of framing what we’re trying to achieve and what kinds of limitations we had. That will explain the choices that we made. The first one was next-gen quality. When you look at Paragon, everything looks fantastic. We have very talented people. We had the stream on Character rendering. It looks fantastic. The World looks fantastic. The Characters look fantastic. We’re trying to match that level of quality. They raised the bar so high. We want animation that matches that. The number one goal was trying to get something that was really next-gen and have that look. The second one was high performance. Paragon we wanted to run on a lot of hardware, very different hardware. It’s not only for high-end PCs, so performance is very important. The third one is we have a very small team, so we want something that’s fairly quick to author. We don’t have just a single hero. It’s not Gears where you have Marcus and that’s who you play throughout the entire game. You have many heroes. They’re all very unique, and we have many of them, so we can’t spend too much time on a single hero. We have to be able to go really fast. We want high quality, but at the same time, we want very short time frames to achieve that with a fairly small team. We don’t have hundreds of animators or programmers dedicated to just animation. It has to be efficient. The last one is -- What we’re going to show and what we did is purely cosmetic, purely visual. We don’t want animation to get in the way of gameplay and controls. I have a lot of games that can play with motion animations. For example, they can take away control to play a nice transition or a recovery. We don’t want to do any of that. We still have abilities that the heroes can do, and in some cases, when you do a leap or a jump, we’ll take control away from the player for these. But as far as regular look motion, just running around and jumping and moving through the Level, animation is purely cosmetic there. These are the constraints that we had, and the goals. Traditionally, our animations have been fairly simple in terms of number of clips that we used. We would typically just one idle animation when you’re not moving, and then a loop of a jog when you’re in motion. We just do a simple crossfading between them, very simple stuff. That’s how we did it in Gears of War, and that’s how we’re doing it in Fortnite. To try to bring that to make it a bit more complex and interesting, we had layers on top of that. We have a lot of additive animations that will play. We’ll have deep dips and leans and we’ll try to simulate getting into a run by doing a little lean and a dip and a stop. >>Chance: Got it, so it’s not just like two states you’re blending between or even three states. You’ve got other little modifiers too. >>Laurent: You have a base of a static idle and then your jog, and then you do the crossfading on top of that. You add additive animation to it even more, complexity. But these tend to stack up quite a bit and be kind of complex. When you have so many layers, it’s hard to control the output, the quality that you have. For us, next-gen meant that we wanted a lot of organic motions. We want some anticipation in recovery. When you do a jump, before you do your jump, you sort of crunch. Then you do the jump. Then when you land, you have this little compression and recovery phase. When you look at any action, you always have a little anticipation when you prepare to do that. Then you do your action, and then you have the recovery. Typically, in the past, we cut that all out completely. You end up with animations that just don’t look very realistic. >>Alex: Yeah, they feel like a video game. >>Laurent: Yeah. We wanted to try to focus on that. I’ll show quickly a video of kind of how things were before. That’s the hero we’ll be talking about today. This is Kallari. What you see here is really what we had before we started any of this work. You see there’s basically the idle, and then you have the jog forward locomotion loop, and there’s a crossfade in between. It’s not very grounded. You see when she starts and stops the feed slide a little bit. There’s really no anticipation and no recovery there. It’s very stiff. >>Chance: Yeah, it’s clear that it’s two states you’re looking at. >>Laurent: Yeah, and that was fine 10 years ago. But 2016, we want to do something a little better to match just the quality and visuals of Paragon. I will show that again at the end. It’s a nice comparison of kind of where we were and where we got to. The strategy that we used on this, we wanted to reduce the number of layers that we use. This adds a lot of complexity, and it’s really hard to control the final look of the Character. When you have so many layers and so many steps, it’s easy for them to not play well with each other. Additive animation has that problem. It can look good when you author it on a certain base, but if you change that, you have unnatural bends, rotations. >>Ray: I think an example of that, during pre-production, we did a lot of layers, very few anims. We would say have an additive layer if you run a slope. Then we would have an additive layer that would play if you started to run. Those two would combine. Then say you jump. We’d have an additive layer that compressed you. So all three or four of these things would combine and suddenly you’d see an arm start to turn weird or you’d see a knee turning funny because things would just -- all those things would pile up. They’d all look good. >>Chance: You’re instructing all of these different bones to do different things that they’re not necessarily expecting, right? >>Ray: Yeah, everything is just getting added up, added up, added up. >>Alex: The rotation is going to -- you eventually get sort of a weird yaw or something. >>Ray: It could be. >>Laurent: Yeah, and every piece is very fragile and requires a lot of tinkering to get it to look right. When you have something that looks bad in a game, you have a bug and you need to fix and improve it, it’s pretty complex to track down just what was wrong about it. When you have no layers or very little, it’s a lot easier to deal with that. Pretty much when you author animation, what you author is what you’ll see in-game. You won’t have a lot of additional steps in between. It’s easier to correct and improve it. We wanted to do that, basically, reduce the complexity. At least from the animator’s point of view, what they do is Maya is what they’ll get in-game as much as possible. We wanted to add a lot of frames before and after these actions. More anticipation, more recovery, a lot more transitions, try to get the organic and realistic motion that humans have. >>Alex: It's very fluid. >>Laurent: Yeah. That’s what makes I think animation more next-gen, is having these types of things. We wanted to try to have longer cycles too. We’ve always done one cycle for jog. It’s very repetitive. We tried to play additives to try to mix it up. But nothing beats mocapping a real actor and getting many cycles. We tried to shoot for four. In some cases, we made it. In other cases, it was difficult. But tried to do that as much as possible, and then use mocap as much as possible. It’s super easy when you’re dealing with human bipeds, but Paragon is a game where we’ll have very different heroes. >>Alex: Yeah, you’ve got some monstrous-looking guys in there. >>Laurent: Yeah, and you can’t always mocap that. As much as possible, we’ll try to. And where we can’t, we’ll try to use inspiration or have a model to create this sort of anticipation or recovery again. The first step that we did is do a big mocap session. That’s the very first thing we did on that Character. We planned out a big list of moves. We planned it very quickly. It was only a couple of days when we decided we need to do a mocap shoot for this. >>Chance: You were the model, right? >>Laurent: No. [LAUGHTER] I wish. No, I don't know actually, because we did some scary things. >>Ray: It was Melissa May, right? >>Laurent: Yeah. >>Chance: Awesome. >>Laurent: We wanted to capture her going up and down slopes, and so we tried to put a platform, but we had no real platform to do that. >>Ray: It’s like eight by eight. It’s what was used for the trucks in Gears 2. They had these inner tubes they bounced it on, so it’s a big eight by eight platform. We just stood it up, and then it basically has poles coming through each side. We just put them in the rungs of a ladder, so it was the most sketchiest -- >>Laurent: Unstable. >>Ray: -- thing anyone’s ever stood on ever. >>Chance: Ehh, it worked. >>Laurent: You were at the end, if she would fall, you were ready to catch her. >>Ray: I just stood back there because she would sprint backward up this crazy, rickety... >>Laurent: You’ve got to sprint backwards up that thing. >>Ray: But it was great. I got some of the best stuff I think in the game. I love it when the slope animations play, because you just feel it. It’s so much more physical now when they hit, and it grounds them in the world. Because they’ll hit a slope and then start digging in to climb a slope. I think it’s one of the best things we did. >>Laurent: Yeah, a lot of that realistic next-gen feel is really in the details. I think motion capture, you capture that very easily. Trying to reproduce it by hand is very, very difficult. It’s also very time-intensive, and we want to be fast here. We want to avoid tinkering forever on small details if we can capture that right away. >>Chance: Especially when you say small details, they’re like the biggest thing, right? You’re going to want to prioritize them at some level, so however you can make that more efficient. >>Laurent: Now we’ll get to look at a bit of gameplay, what we’ve done. The first thing that we’ve tackled is our transitions. For start and stop transitions, our idea was to do motion prediction. Basically, we’re trying to predict where the Character is going to stop. In a game, when you move around, you’re just that capsule. This is what moves in the game. The Character is, as we said, purely cosmetic. It’s kind of a layer that plays on top. What you move around is this capsule. What we’re trying to do is predict when it’s going to stop. You see the red sphere. This is predicting the location of the stop. When we start, we leave a green sphere, and this is where we started. Essentially, for the stop, we’re looking ahead. We’re predicting where you’re going to stop and we’re looking ahead. That gives us a few frames to do the anticipation for the stop. When we do the start, we drop the marker and we look backwards. We look back in time and for the stop, we look ahead in time. When we do pivoting, the purple is basically the pivoting point. We see that we look ahead a little bit and then we look back quite a bit. We basically predict the motion the Character does and we place these markers in the world. We do the same for jumps. We predict the apex, that’s the purple, and the red is the landing point. Very easy stuff. Purple apex, and the red is the landing. A good way to think about that is we’re dropping these marker locations in the world, and then we’re using them to synchronize our animations. >>Chance: It’s kind of like a new node of data that you didn’t calculate distances and rotations, right? >>Laurent: Yeah, so looking at our start transition, this is the start forward that we use. We recorded the motion of the actor in the studio. Just like with Root Motion, if you’re familiar with the term, it’s really just Root Motion. What we did is we translated the physical movement into a curve. We have it here. We call it a Distance Curve. In the case of a start transition, you’re looking back in time at where that marker was. That Curve describes the distance of the Actor to that marker. When you start the distance is zero. That’s what the curve indicates. As you go forward, increase the distance. At the end, we reach 500 units. That’s about five meters. We mocapped our start transition to be a distance of five meters. You see in the start, we have a little bit of anticipation. Then we sort of build into that jog speed. The stop transition is very similar, except the stop, instead of looking back in time, you’re looking ahead. When we start, we have about 105 units, so about a meter away. Then we go all the way to zero when we reach that marker, basically. You see we have a little bit of distance from the anticipation to the stop. Then the rest is just a recovery after that. Pivoting is a combination of both, because you reach a point and then you leave that point. In that case, the Distance Curve is going to stop being negative. Here we have about 60 centimeters before you hit your pivoting point. That’s where you go into your stop, and then you push away. For this one, we have about three meters away from that. We’re really synchronizing the animation to the movement of the capsule in the game. When we recalled the actor in the studio, the actor has its own speed and acceleration. In a game, it’s obviously different. We’re trying to remap the motion and we record it to the motion that’s in the game. When we do this, by using the distance, we get really precise foot placement, no foot sliding at all. But the flipside of that is we play the animation either a little faster or a little slower because both speeds don’t match exactly. >>Ray: For people who are familiar with Root Motion, basically the animation tells the capsule where to go. If I crossed the room in the animation, the capsule will just follow the animation along. This kind of flips that on its head. Basically, the capsule is going to cross the room, and then it looks at that curve to say, at what point across the room am I in this animation? Then it plays that frame. It uses the motion of the capsule to pick which frame to play in the animation. Basically, the animation stays locked to what the capsule is doing movement-wise. If the capsule is sitting still and then starts moving forward, the animation says, okay, I’m two units from where I started; I’ll find that on this Curve and play that frame. When I’m 100 units away, I’ll play the frame that... >>Chance: It’s predictive, right? >>Ray: Yeah, right. >>Laurent: You can see the start and the stop in there. If you remember the video we showed earlier, it’s a huge difference. The Character feels a lot more grounded. We don’t have this crossfade between the idle and the loop causing the foot sliding. On the way back, we get a little step to stop, and then a nice shift in the body. A nice anticipation and recovery there. We get the same when we do pivoting. See, she kicks her leg out and then pushes out of the way. That’s the kind of detail that that gives us. We’ll get back into trying to match both girls and playing the animation a bit faster and slower. We use Speed Warping to solve that. We’ll go in detail about that in a little bit. The next thing that I want to talk about is synchronization markers. Basically, when we go from our start transition into our looping locomotion animations. To make that seamless, we put markers on the animation for where each foot is. If we look at our looping animation for the jog forward, we have about three or four cycles in there. You can see these green markers here. Right, left, right, left. This is where basically the foot crosses with the hip of the Character, basically. The right foot goes through and then the left goes through, and so on. What we've used here -- Actually let me see if I can show the bones. We look at the toe bone. It’s this one, when it crosses the root bone of the Character. We do this for every foot that’s on the ground, every passing foot on the ground. The reason for doing it that way is this sort of tells us spatially where the foot is, and we can synchronize animations that way. We thought about this, and a lot of people seem to describe the movement as when the foot touches the ground and leaves the ground, sort of like the amplitude of the step. We decided to go instead with spatially where it was around the player to minimize foot sliding. When you transition between animations, we’ll sort of try to get the closest position to where the capsule is, basically, to minimize sliding. We sacrifice a bit where the foot is, in terms of being up in the air or down on the ground. But we try to keep the position in the World to minimize foot sliding. >>Ray: Basically, we favor its position relative to the hips, then where it is in the cycle. >>Laurent: Exactly. >>Ray: The hips may be down on this one, or they may be up on the other one, but if the foot is in the same position, we choose that so that foot doesn’t slide. Even though it may slightly fight with the overall motion of the arms or the hips, the feet won’t stay locked. >>Laurent: It seems to work really well, and it’s a lot simpler because we just have -- for one cycle, you just have two markers every time. >>Ray: This has been just such a huge feature for us, because in the past in Gears, all the jog anims that needed to blend together needed to be the same length so that they could be synced. Now, this has a three-cycle jog. Jog left may be one cycle. Jog backward might be two cycles, and it matches everything up using these feet markers. >>Chance: It allows you to be much more flexible and loose when you’re designing the animations. >>Ray: Especially when we’re mocapping a lot of stuff, because we can kind of take what the mocap gives us. If the mocap gives us three good cycles, great. If it gives us one, that’s not the best, but it will still work with the other ones. Where before, if we could only get one good cycle of jog backwards, that really meant we only had one good cycle of any other direction regardless of how it looked. >>Laurent: That’s the start transition and basically, we start, stopped, and when we pick up speed and we go transition into our jog loop. We have these feet markers, and that allows us to find a good spot in the loop to transition so it’s completely seamless. We use this for pretty much all of our transitions. Well, the ones that go to and from the looping. >>Ray: Again, this is a big difference of how it has been before. Because before, we would need to get out of that transition as quickly as possible because you need to get the jog forward out of jog forward start, because from jog forward, we may branch into any other direction or anything like that. But since we have sync markers, we can slowly crossfade into jog forward or into any other direction. >>Chance: And it doesn't care. >>Ray: No. >>Laurent: Yeah, so the pivoting is the same. That’s basically what we used to connect our transitions to our looping, locomotion cycle. This is a feature that Martin Wilson in the UK worked on, so a little shout out to him. Martin Wilson, thank you for your help. It’s a great feature. We’ve been wanting that for a long time. It’s great to finally have it. After that, the next thing we'll look at is -- We’ll come back to locomotion in a little bit. First, I want to show Turn In Place. Turn In Place we use basically the same technique. We use the same Distance Curve, except here it’s not distance, but it’s rotation angle. We have 90 degrees left and right. We rotate the head first, and then the body will catch up. We have more of a lag on the 90 degrees. When we go to the 180s, it’s a lot more responsive. She’ll turn it a lot faster in that case. >>Chance: Yeah, because clearly the player wants to turn and look that way right now, right? I like that the head tracks almost exactly one to one, just a little bit of lag behind the Camera. >>Laurent: Yeah, there is a very small lag on the head, barely. Then the turn lags a little bit. The setup for that stuff -- Basically, your Distance Curve describes the angle remaining. Here we have minus 90 degrees. That’s a 90-degree turn. Then we go all the way to zero. Again, we start the animation with Root Motion where we have the turn. We back it out, and then we translate into this curve. We could use Root Motion as is, but that curve is an optimization. It’s easier to work with. We know how much turn you have left. We know when you are finished with your turn. >>Ray: It may be interesting just to play the animation in show the perspective so people can see this is what actually gets brought into the Engine as a turn. The curve that you see down there is us basically backing, counter-rotating the Character out so that they basically do that little shuffle instead of physically turn. >>Laurent: We back out the head turn as well, and that is procedural in the game. >>Ray: Basically, the capsule turns and we use that curve to sort of sync them up. >>Chance: At the same time. >>Ray: Right. As the capsule’s turning, it basically puts the rotation motion back in it that we pull out of it Maya. That curve, it might be interesting also -- the Distance Curve that you see down there is just a custom attribute on the root bone of the Character’s rig. Then for people who have used the art tool that ships with UE4, I just take one of the Offset nodes, back that rotation out of the Character, and then copy that curve to this custom attribute on the root. It just gets imported into UE4. There’s a checked box on the FBX import that says, “Import Custom Attributes." It’s just like that. There’s no work or anything extra. >>Laurent: Yeah, and before we had restrictions where the rotation had to be constant. That curve would be linear, and that’s not very organic. Here, we just stick with what the mocap does, and we can use it. You can see there’s almost no turning in the beginning. That’s going to be your anticipation frames where we prepare the turn, and then we do the turn, and then we slow down and we have the recovery phase after that. You see the movement in the hips. The way that we’ve set it up is as soon as you finish a turn, your angle reaches zero, we go into a different state. We’ll show this State Machine a bit more in detail. Basically, you go from your idle into your TurnInPlace, and that’s going to be your active turn. As soon as you enter the recovery phase, we’ll go in the recovery state. This one can be interrupted. If you change your mind, and just to make the rotations more responsive, we can abort the recovery and then take another turn right after. >>Ray: Having a long recovery on a turn is something we’ve never had before. >>Laurent: Yeah. >>Ray: That’s something you just try to get through as fast as possible, because they’re going to do something else. >>Laurent: That’s the Character that’s not directly aiming with a weapon, so we made the turns lag a bit more. But you could make them more responsive, and then the interruption would matter a lot more to increase the responsiveness. That’s what we have for TurnInPlace. Then the extension of that is we do turns and we tolerate quit a bit of lag before you catch up. What we added is spin transitions. If you start moving before you turn, then we have this spin transition where you do a turn while moving. We mocapped forward and back, clockwise and counterclockwise. You do these little spins. The setup for these is basically a combination of what we’ve seen so far. We have a Distance Curve that we use for the turns. Then we have the synchronization markers that we use to go from the jog back into the jog. You can see that we have basically all of this here. There’s a couple jog cycles so we can come into this animation. Then we have the turn. Then we have a recovery phase with a few cycles to branch back into the jog. We have four of these forward and back and clockwise, counterclockwise. >>Ray: This is definitely one of those anims -- if you play that, it’s hard to tell what you’re looking at with the rotation backed out. That really doesn’t look like what you see in game because the rotation is completely backed out of it. She’s actually changing direction during that part, and that’s just described by that curve again. You see the curve goes 180 during that part where she makes that weird sidestep. >>Laurent: Now we’ll go back to talking about Speed Warping. Initially, we mentioned Speed Warping for transitions. We mocap an actor, and he’s locomotion, so he’s speed and acceleration. Then the game has something completely different. To minimize foot sliding, we try to use the animation exactly as it is, but we’ll play it a bit slower or faster depending on what the capsule does in the game. Playing animations faster and slower looks really bad. You have very little range that you can play with. Usually, you push it to maybe 10 percent, and then after that, it completely breaks apart. Even these 10 percents you have to be careful with. >>Chance: One of those that you just try it out a few times to kind of see what you can get away with? >>Laurent: Yeah, it’s funny because when we did our mocap, we decided to take the Actor and record her on a treadmill. We wanted to sort of study how she would change from a slow walk into a jog and into a sprint. It was pretty slow. I think we did that over two minutes. It was a really slow progression. We wanted to study how do you change that? How do you adapt? What we saw is that her upper body didn’t really change speed all that much. There’s definitely a little acceleration, but not a whole lot. What happens is the legs, they tend to take bigger steps. This is a big difference. That’s what we tried to do with Speed Warping essentially, is instead of playing animations slower and faster, we’re going to change instead the size of the steps that you take procedurally. We will show a bunch of examples of that. That’s essentially the idea behind it. I have a video showing the difference between Speed Warping and not. On the left here, you see Speed Warping. On the right is when we change the Play Rate. As we go to 1.5 and keep going up, it plays faster and faster. You reach very quickly that hill phase, and then beyond that it’s just unusable. When you slow down, it’s the opposite. You completely freeze. Eventually, you reach zero and you stop. You see with Speed Warping, you’re basically jogging in place. This is one animation. It’s the same animation, and we just sort of stretch the steps that you’re taking. That gives us a much bigger range than we could get with just changing the Play Rate of animation. >>Ray: A game like Paragon or any game where the speed can change dynamically because of a buff or because you’ve killed some jungle minion, that gives you extra speed or something. >>Alex: It was just hopping in place. >>Laurent: That’s a very important point. There’s many things. Adapting the curve that we do for transitions is one case where it’s useful. Changing speeds dynamically in a game, [inaudible] change that, but design as heroes change and get tweaked, you can get huge speed changes. Without a system like that, that means a lot of animations have to be redone, and usually we don’t have the time to do that. >>Ray: No, that would be a terrible email to get. After all the locomotion is finished, oh, it needs to be 50 percent faster, 25 percent faster. Oh, my goodness. >>Laurent: But at the same time, you don’t want to get in the way of design. If they need to make these changes to make the game better, then we should support that. That’s a great tech to have, because nobody stresses. Just try it. It will still look good. Everybody’s happy. Perfect. >>Chance: I don't know, I’m kind of liking this one on the right. >>Alex: That still has the little fast legs. >>Ray: You can see like at 2.0 and 3.0, you wouldn’t really animate it like that. But if it’s only going to be on screen for 10, 15 seconds or something like that and it will save us from having to make a whole other motion set at that speed. >>Chance: You can get away with it. >>Ray: You sort of start saying you're picking your battles. Maybe time would be better spent working something that has more impact on design or on gameplay or on the player. >>Laurent: There’s another case where it’s really useful. Paragon can also be played with a controller. You can also go much slower, basically push on your stick. You’ll go much slower. That allows us to adapt the animation dynamically, and we don’t need to authorize many different styles. This is not a silver bullet where you do only one locomotion set and you cover all cases, because it doesn’t change the style. Between a jog and a sprint and a walk, your upper body will do something very different. You still want different locomotion sets for that. But for each set, this system gives you a much greater range where you can use it. With that, it would have to probably double the locomotion sets we have just to support all the speeds that we have in the game plus the Controller [inaudible]. >>Alex: How expensive would you say using warping as a technique is for systems? >>Laurent: It’s not expensive at all. We’ll go in a bit of details of how it works. But the good news is the setup that it uses is the setup that we require on all the assets on the Marketplace. It’s kind of a standard setup that we’ve had at Epic for many, many years. I can show you quickly. It’s a Post Processing node that you just slot in your graph. This is our looping locomotion state here. We have two main locomotion styles. We have the travel mode and we have the regular jog for this Character. It’s just a little node that we place in there, Speed Warping. Essentially, what you tell it to do is just scale, and then you also tell it the direction of your scale. So the movement, direction, and how much slower or faster you want it to be. Then it’s just Post Processing from there. It uses our IK setup on this. We go into Wireframe like this. Basically, we have defined what we require in the Marketplace assets is IK bones. Basically, you have an IK foot root bone. Then we have left and right feet from there. These match exactly the IK position of the legs. That’s the setup that we use for Speed Warping. Now we’ll go back to the video. Essentially, here what you see in red is the original animation. What you see in blue is the resulting animation. Here we do Speed Warping 2X, so the Character moves twice as fast. It’s kind of a two-step process. In Green, you see where the IK should be ideally if you went twice as fast. We take the IK position of the feet, and we’ll just say you’ll travel twice that distance. Obviously in that case, it would stretch the legs horribly. You see this sphere in the middle is where the hips would end up if you were taking this literally. >>Alex: So it would be like constantly splitting. >>Laurent: Yes. 2X would be too much. >>Chance: Just like that nightmare fuel that you get from animation bugs. >>Laurent: But this is a very naïve goal. We just took the IK and you tell them, travel twice the distance. We then try to pull the hips a little bit towards these goals. But then we do the opposite where we clamp the feet and never stretch them. We have a hard rule that it’s okay to compress a leg but never overextend it. We don’t want to break the pose. That’s what we do here. These would basically be completely unreachable without breaking the pose, basically. What that means essentially is you can’t reach your ideal targets, and so your feet spend more time in the air. That’s convenient, because that’s what happens when you run faster and faster. Your feet spend less time on the ground. It works great in that case. It’s very simple stuff, but that turned out to be a huge timesaver. It helped quality quite a bit as well. We used to be scared of speed changes in games, and now we don’t worry about it anymore. >>Chance: Seems like a really viable solution for it. I kind of wish you had recorded the moving of the green IK scale. >>Laurent: There’s probably a video somewhere. Another case where it’s useful - the spin transition is a great example of where Speed Warping shines. Again, we have a video on the left that's without it. On the right, it’s with Speed Warping. What we do here is we play at about a third of our speed. We get this by not pressing all the way on the game pad. One third. You see on the left, the whole animation is slowed down because this is how we can get it to not foot slide. But the downside is that is slows down your turn as well. With Speed Warping, we’re basically taking smaller steps so we don’t slow down the turn. The transition plays for the same amount. We’re not slowing it down. We’re just taking smaller steps to not foot slide. >>Alex: It also eliminates the moonwalk effect and you get kind of a tiptoeing effect instead. Very natural. >>Ray: It looks like she’s coming up to a crosswalk jogging. >>Laurent: That helps us quite a bit. When you look at the transition like the start and stop and those kinds of transitions, it eliminates these transitions playing a little too fast or too slow. We’re able to play them on a regular speed. We just take smaller steps when needed to have what we recovered from the actor match what we have in the game, basically. It’s all dynamic, so designers can come in and tweak the physics or whatever top-speed acceleration. >>Chance: I’m sure it makes Ray’s life easier too. >>Ray: It definitely is easier. When Laurent first sort of started talking about this idea, I was a little bit skeptical, just stretching out the legs. But it’s really the best option. It’s so much better, as you saw, than just speeding it up or slowing it down. Because we’re doing all of these extra transitions and things like that for locomotion, if you only have one cycle jog and that’s it, then it’s not that bad to do a walk, a jog, a run, and a sprint and just have those on a continuum that kind of blend together. But since we have three-cycle jogs, four-cycle jogs, starts, stops, pivots - we can’t do that for walk, jog, run, sprint. The animation budget starts growing. Producers’ hair starts falling out, and Jay starts crying. >>Laurent: Gavin starts laughing. >>Ray: Yeah, Gavin starts laughing. >>Chance: I think Gavin is still in the chat. I think he’s laughing at the chat right now. >>Ray: This gives us that sort of spectrum to play in without having to author a spin transition when you’re running at half speed and a spin transition when you’re sprinting. We can sort of stretch these animations out, and it’s so much better than just scaling the Play Rate. Scaling the Play Rate is something that just drives animators crazy. On previous projects, you had worked on something, three or four or five or six months would go by, and then you would come around back to it to do a little bit of polish and you see a designer has sped all the animations up 400 percent or something like that. You’re just like, oh my goodness. Seeing something other than just adjusting the Play Rate of an animation is a very nice thing. >>Laurent: What we’re going to take a look at now is more of what we put into our main locomotion loop. In this case, it’s a jog, a jog forward. We have about three or four cycles in there. This is the Blend Space that we use for that. We added slopes in there, so we have uphill and downhill, and then we added the leans. In the past, leans is something that we used to do with an additive, but we found that mocapping you really get something that looks very different and adds a ton, so we try to mocap it. It looks better. One Blend Space for one direction. We use four of these. If we go back to our driving state, you see the four that we used. We have North, East, South, West. Very easy. Each one we just provide a lean angle, the slope, and then the Play Rate. We do Scale Rate a little bit. We do want some of it. We don’t want too much of it, but we want a little bit. We can control how much we want Speed Warping and how much we want Rate Scale. If you jog faster, we want the arms to swing a little bit faster. We control how much we want Speed Warping, so you take bigger steps, and how much Rate Scale we do so you run a little faster. Basically, each direction is done with this Blend Space, leaning slope, Play Rate. Then we do Aim Offset, so that’s procedural rotation. We will support 90 degrees total before transitioning to another direction. The Aim Offset actually supports 180 both ways, 360. Then we’ll physically rotate the animation by this 90-degree max before we transition from North. We’ll go to East and West and so on. We have the same for all our actions. The reason we did it that way instead of [inaudible], it would put all our actions into a single Blend Space. The problem with that is when you hit the diagonals, you have your feet at cross. By doing this, we avoided it. Here we’ll basically just rotate it. Then when you change direction, that’s where you’ll transition between your different states. >>Chance: Is there a building in the background? >>Ray: Yeah, that’s the default. >>Laurent: Epic Offices. >>Alex: Yeah, over to the left, that’s us. >>Laurent: I don't know if you can reach that game pad. It’s harder to show on a keyboard and a lot easier to show on a game pad. As I circle around, she will basically do this sort of body shift. That’s when we go from North to West and South and so on. But it helps us, eliminates the crossing we have in between. It sort of gives it a natural movement too. >>Ray: That looks really nice. So before, basically we would have say forward and left. Then as he would approach that 45 degree, we would just start blending those two, so you would get 50 percent forward and 50 percent left. The legs would start going through each other and it would just be sometimes okay, and sometimes not so good. But this he’s actually rotating forward right until he gets to 45 and just beyond it. Then he says, okay, left can take over. Then he rotates left back to that 45. We never have that 50 percent blend of a mess. I think it looks great. >>Laurent: The next point is leans. We showed sloping, so let’s show slopes in there. When we go up, it just plays the slope uphill, and when we go down, it plays downhill. When you go left and right, we play our mocap leans. The slope is one that’s difficult to get multiple cycles. We have only one cycle, otherwise our actor would be dead. [LAUGHTER] But we’ll see if we can get a better ramp, I guess, try to get - >>Ray: Yeah, we have a better ramp now. It’s not as much fun as it used to be. >>Laurent: It’s fairly straightforward. We do leans on the four directions and the slopes on the four directions. If we look at backwards, for example, we go up, and we lean and go down and so on. When you use your gamepad and you sort of circle strafe, you have this nice leaning motion that you get from having it on all directions. That’s it for stop animations. The next bit that we’ll talk about it Slope Warping. Slope Warping is basically our support of slopes through IK procedure. Switch to debugging so we can see what this looks like. What you see here in red again is the original pose. Blue is the resulting pose. I can also disable it so you see. That’s how our animation would be without it. Then when you enable it, this is what it looks like. It’s a big, big difference. I’m going to disable it for a bit so we can run around and see what it does. But we only have slope animations for our loops, so when I start my start transition, I don’t have it. As soon as I hit the loop, then I do have it. If I were to do pivot transition on a slope, you see I’m doing it on a flat surface. That’s basically the animation that we recorded. So when we enable Speed Warping, now we’re basically transforming in real-time through IK and you have this nice pose. Debug, this is what it looks like. The way it works is similar to Speed Warping. We use the same IK setup for the feet. We have two modes. We have one that’s super-fast. Basically, we use the information of the capsule to tell us where the floor is. We want the orientation and the distance. The capsule can give us that. It’s not perfect, but it’s good enough for speed. The high-quality mode does traces on each foot, and we use that to adjust the IK. What we do essentially - the little diamond that you see in there is the IK roots for the foot. We offset it to meet the floor. In yellow, the yellow ball is basically the floor location, and the yellow arrow is the orientation, is the normal one. We’ll basically use that to offset the IK. >>Chance: You calculate based on that normal? >>Laurent: Yeah, and rotate it. So we’ll basically say we move the feet to the floor location and we’ll rotate the IK feet to match exactly the orientation of that floor. Now, that’s going to create some stretching and overextension on the legs. So the next step is to pull the hips. Again, we don’t want to break the pose. We allow compression, which is what is happening on the left leg. The one that’s up the slope gets compressed a little bit, but the one that’s down the slope, we want to preserve it. We don’t want to break it. You see around the pelvis, the red is the original location. The blue green is the resulting one. We basically pull the hips a few times to try to stabilize it and not break the pose. This is again, a node that is done as a Post Processing. So where we have our 2-bone IK for the legs, we run it just before and we just have one of these in the entire graph. Then we do the IK for the legs right after. The thing that’s really neat about that system is it’s basically using the information it finds from the animation. If we look at our Blend Space that we had, this is our locomotion forward Blend Space. We’ll show the IK foot root. This is the IK foot root that we have in this. For our looping animation, it’s straight because it’s been authored on the ground. Then when you go uphill, you see it rotate up and then downhill rotate down. The Slope Warping now is basically doing the difference to meet the current slope of the game. If you have animations, it will use what it has and it will just make up the difference. >>Ray: That rotation on the foot root is in content. I basically rotate that in Maya as a way to say, this was the angle that we had her running on. Then when he gets in here, it’s flat on all anims except for these because these are the only ones that we authored on a slope. That basically just saves the slope that the person was on for this from a raw. >>Chance: So a design consideration there, you mocapped on the slopes that match the scale of the slopes that you would have in the game? >>Laurent: No, we got as much slope as we could safely without injuring anybody. >>Ray: Safe-ishly. >>Chance: Then did you go through and adjust those to match what the game was expecting? >>Laurent: No. It’s done with that node procedurally. >>Ray: You can see it’s on a continuum. It could be a less-steep hill, and it’s going to have a blend between the flat jog forward and the slope jog forward. >>Laurent: I think here we got about 25 percent. >>Ray: I think we’re 25 degrees. Which doesn’t sound like much, but when you’re sprinting backwards up on an eight-foot, it’s - >>Laurent: So the node will make up the difference. If in the game you have 30 degrees, then it will make up the 5 that’s missing from these animations. >>Alex: It’s very interesting. >>Laurent: For the transitions, we have [inaudible] only on the flats, so we’ll do the full 30 degrees in that case. >>Alex: You said it kind of detects the ground and helps you with foot placement, but what if you’re close to a ledge? Is that kind of calculated as well so you won’t have a foot hanging over an edge and that kind of weird floating? >>Laurent: No, you can have a foot hanging. The capsule is what tells you whether you are falling or not. So the animation will have one foot hanging. When we do the traces, if you choose the expensive option with the traces, there’s a limit on it. If the ground is near, you’ll take a step down. If it’s way too far, then you’ll just have your foot in the air. If you use a capsule, then it’s wherever the capsule tells us. The capsule tells us, you’re not falling; you’re still on the ground. >>Chance: Right. But even so, when you’re looking at some of these, that might be just a really minute detail that’s not necessarily noticeable in those fringe cases that you would be so close that the trace would be too far down, right? >>Ray: Those choices constantly have to be made everywhere. For performance, do we have the performance to do a trace for each foot? Maybe not. >>Laurent: We might be able to get it - >>Ray: You can probably get right on the edge of that. >>Laurent: A case here where we’re close enough. I don’t do it. That’s the cheaper version, though. This one is just the capsule, so you always have a foot hanging there. The downside of the capsule is when you’re at an edge like this, your foot does fly. Yeah, you do need to have the traces for this one. >>Alex: So there’s limitations to that technique versus the other, but there’s performance tradeoffs that you’re making. >>Laurent: Yes, absolutely. The cheap one with the capsule is not as precise, but it’s cheaper. The one that has the traces is way more. >>Alex: For each one, that’s going to be way more expensive, especially considering how many Characters are going to be running around. >>Laurent: Right. >>Ray: It’s a per Character, I think. It’s an issue that is a bigger problem for larger Characters with wider stances. She’s relatively a small Character and her feet are pretty close to where the capsule is or the root origin is anyway most of the time when she’s standing still. But say a Character with a really wide stance, that foot could be hanging way out in space. Just like almost everything else with this stuff, you sort of have to weigh four or five different things and then - >>Chance: Make the tradeoffs. >>Ray: - make the cheapest, fastest, best-looking tradeoff. >>Laurent: We’ll jump very briefly because we’re starting to run out of time. The jump was made a similar way using Distance Curve. We broke our jump in three parts. We had the takeoff, the in-air apex, and then the landing. So the Distance Curve tells us - we basically drop a marker when you jump on the ground, and then we measure the distance you are to this marker. We use it here to get a few extra frames of compression. Because animation runs after physics. When we know that you’re jumping, it’s already too late. You are already jumping. This allows us to compensate and have a few extra frames of the feet on the ground. >>Ray: You can see in content, I’m pushing her down through the ground. In Maya, she’s going below the origin at the beginning of that. >>Laurent: Exactly, so she starts above the ground and then she sinks into the ground. We compensate for that. In game, she will have her foot. >>Chance: Because the capsule is moving, right? >>Ray: Right. The capsule takes off instantly. I just lag her behind just a little bit. I try to do it as much as I can, and the designers were like, oh, the capsule and the shooting overhead is still hitting her. But I try to do that as much as possible so it feels as grounded as we can make it. >>Laurent: If we slow it down, we'll be able to see as we take a jump. >>Alex: Oh, cool. >>Laurent: We have a few more frames where the feet connect. It’s kind of hard to show that. If you look at the capsule - let’s see if it works. The capsules basically leaves right away and you see the feet stay on the ground a bit longer. >>Ray: You can imagine if the feet stayed level with the bottom of the capsule, how kind of weak that jump would feel. She would just be lifted off the ground instead of pushing off. >>Laurent: We also use Distance Curve for the landing. Landing is similar. We put a marker where you’re going to land, and then we use that to synchronize your feet getting close to the ground. The arc is synchronized with the apex. The Distance Curve is basically how far before it and then once you go past it. Just like our transitions, we look ahead and we look behind and we use that to synchronize what the Character is doing. Then we have an additive. I think the mouse is starting to die. >>Alex: Oh, wow. Yeah, that happens every now and then. >>Laurent: We have an additive animation that we play, and this plays on top of anything in the game. That’s why we picked additive. If we were to do a jump and then we land with pivot, it would play on top of the pivot transition we have there. >>Ray: It gives us a nice landing compression regardless of whether you’re running when you land, whether you’re standing still, if you’re in the middle of some transition like that. We still get a nice landing compression. >>Chance: Helps it blend better. >>Ray: Yeah, because if we didn’t make it additive, we would have to make a landing for jog forward, jog backward, left, right, all this other stuff. By making an additive, even though maybe the result isn’t what you would have animated exactly, you still get a nice feel to it without making tons and tons of content. >>Laurent: We’ve got it playing on top of pivot in this case, and standing still is [inaudible]. I think that covers the jump. Another useful feature - this is something that Ben Gallagher in the UK worked on, is blend profiles. That allows us to, when we do a blend between animations, have different speeds depending on which bones you’re blending. We’re using that to make the feet align really quickly and then the upper body really slowly. Typically, our feet will blend twice as fast, so we have very responsive foot placements. The upper body can lag and be smoother and have longer interpolation. I’m not going to spend too much time on this, but we also have a system to play upper body animations. The keyboard is not working here. Your E is not working. We won’t show this then. The last piece of tech is AnimDynamics. We have a simple physics simulation that runs. This Character doesn’t have any, so we can’t really show it. >>Chance: We’re actually going to have Ben on I think at some point in the future. >>Laurent: Yeah, that would be ideal. >>Chance: Following this. We wanted to talk here now and then move back into the more technical bits. >>Laurent: Yeah, it’s really cool stuff. We use it for a lot of flappy bits and cloth and hair, just a lot of physics things that you want moving on Characters. It’s cheap and it’s a node that you drop, same thing as a Post Process in your AnimGraph. >>Ray: Giving scale control. >>Laurent: Yeah. The last thing is we can just quickly give an overview of the AnimGraph, and then I think we’ll take questions after that. When we’re looking at this, we’re looking at it kind of backwards. This is the resulting pose. This is where you finish. When we take it from the very beginning, we basically have a locomotion state machine. That’s the starting point. We don’t have a whole lot of states. It’s fairly simple. Idle, it’s obviously an idle state. From there, we showed earlier the TurnInPlace in the recovery. We have a few states, your Stun and KnockedBack. Jumping is only one state. The recovery is one once you land and you play the additive. When we go into the locomotion bit, we have the start transition here, and that leads into the jog, and that’s our main loop. From here, we can go into a pivot, and it’s split into two. We have what happens before you reach the pivot point and then what happens after. We broke them apart so you can go back and forth if you wanted. It’s kind of an edge case, but we support it. Then the spin transition is in there. From your loop, you can go into the stop transition. That’s really all there is. It’s fairly simple. Each state is extremely simple inside. The pivot we just feed an animation in its position. Like the main locomotion loop, we put an Aim Offset to get supporting different angles and then we rotate the animation. We rotate it up to 90 degrees and then we have 4 directions. That’s about all there is in every state. It’s pretty much like that, except the looping one that has all four directions. When you come out of that, basically we have a place where we play the additive jump, so this plays on top of everything. Coming out of the locomotion state machine, we’ll play the additive jump on top of whatever comes out. After this, we have the setup for playing upper body animations. We didn’t show this. It’s basically split in half. We have one part where we play additive animations, and that’s on the full body. It’s basically that state, so it’s in MeshSpaceAdditive. Then we have a part that’s full body overrides, and that plays on the head and the arms. When she does something on the upper body, she’ll take out a knife and hold it. We’ll have the additive that will play on top of the full body, except the legs. We take out the legs right here. Then the head and the hands we’ll take over completely. This will play the idle or additive to make it seamless, so the same idle would play on top of when you’re standing still, when you’re taking a turn, when you’re stopping. All these sorts of stopped poses will play that seamless idle. Here we handle the main rotation. That’s what happens when we TurnInPlace and do the spin transitions. We’ll have the Aim Offset to cover the head and torso rotation, and then we have a simple rotate root bone to handle the angles, the rotation angle. After that, we have a few slots to play montages. This is mostly for our VTs. We have upper body. We have a breakdown if you’re moving or in place or in the air or on the ground, different things that you can do. We have a little override for the jets that she has on her back. It has its own state machine. It opens and closes. Nice details. Hit reactions are additive. They’re played here. The tentacles on the back also have their own animation. We have some correctives as well. Travel Mode we haven’t shown a whole lot, but we do share a bunch of the animations from her regular set and we have some additive to do some corrective poses on top of that. Then it’s a bunch of Skel Controls, so we use trails for the tentacles that she has. We have Slope Warping for the slopes, IK for the legs, and then that’s it. That’s the final pose. >>Alex: Wow, so it has to basically add together so much just to get to that. It’s amazing. >>Laurent: It’s so much, but it’s a lot less than what we had before. >>Ray: At any given moment, a lot of those nodes have a weight of zero. >>Alex: Okay, they are just ways you can interject correction into - >>Laurent: Yeah, exactly. >>Chance: It’s the little interfaces for you to say, nope, do this instead, or give it a little bit more squash or stretch, right? >>Laurent: Yeah. We took out the idle as an additive so you wouldn’t see hard jitters or transition issues when you went from the idle to a turn, so that’s separated and seamless. But once you go into your jog forward, you’re pretty much just playing that, this IK processing. But there’s no other layers or other animation playing on top of that. And because we don’t have the Blend Space for doing the directions, we do a lot less blending than traditionally. It’s simpler. I think we’ll take some questions now. >>Alex: If you scroll down on there, we’ve got a few of them. >>Chance: There’s a lot that came through that we had already answered, but feel free to grab from here. We’ve got some time. >>Laurent: Do all players share the same Skeleton, or do they have their own Skeleton? They don’t share. That’s a big difference from Fortnite where they all shared the same Skeleton and we could do a lot of retargeting. Here, everything is pretty much unique. >>Chance: Very different Characters, right? >>Laurent: Yeah. >>Chance: Retargeting I think would work, but I think you wouldn’t get the effects that you would want, right? >>Laurent: The Characters are just so, in what they do and how they look and their style - maybe down the road if we have many Characters, we’ll be able to share a bit. At the moment, there’s really no sharing going on, and not for a while. >>Chance: There are a number on facial animations, but I think we’d have to touch on that at another time. >>Laurent: Yeah, I think facial stuff, we’ll save it for another stream. There’s a lot to talk about there. >>Ray: We are using art, though. There’s a question there, are you using art to do the face Character rigging? We’re using art. Same art that ships in UE4. >>Alex: Yup, the art rigging tools. >>Ray: And the Distance Curves, all those things. There’s nothing custom in what we’re doing with any of this. >>Laurent: If we use any special techniques to solve intersections between rigid pieces of armor on moving Characters? So it would be Blend Shapes, in this case. >>Ray: Yeah, and probably AnimDynamics, limits, and stuff like that would probably - not sure when AnimDynamics go out to the world. >>Laurent: I don't know. You’ll have a stream about it soon. >>Chance: We’ll talk with Ben more about it. >>Laurent: How do we set priority animations when you’re getting hit, still attacking? How do you choose which one takes priority on the blend to be there all the time? It’s basically how the graph is set up. There’s an order to it, and you choose what overrides what. In the case of hit reactions, we show that. At the very end, it’s an additive. It will play on everything that’s before it. If we play an animation on that slot, for example, that will take over everything that’s before it. But hit reactions will still play on top. It’s just the way that you create your graph. You decide what takes over what. >>Ray: That’s kind of a design - That sort of has design implications, a question like that. It’s partly up to design. Part of it is probably also part of the Character. She’s a melee Character, so playing a small additive on her during an attack is probably not going to be that bad. But say a Character who needs to have both hands on a weapon or a Character that needs to do some really precise thing with a weapon, that may be a problem, applying some hit react additive on top in the middle of a complicated animation. >>Laurent: How are legs on slope animated? Is this IK? Yes, most of the time. The loop though, we showed, we have some author animations for that. But we don’t for everything else, basically, all the transitions. IK takes over. IK does what’s not there. If the animation provides some, we’ll use it. If it’s not there, then IK will take over. >>Chance: Then you’ll use IK for it. >>Laurent: Yeah. >>Ray: What is the bone limit? We still explore that every day. Every new Character, we test those boundaries. >>Laurent: From the test we made, the bones doesn’t seem to matter too much for performance, not as much as we thought, at least. It’s not our biggest concern and focus right now. I would say our Characters are probably from between 100 to 150 bones maybe. We try to stay within that range. >>Ray: Some go a little lower than that. But there are some that have some complicated mechanical stuff. >>Laurent: That’s for in-game, too. >>Chance: We’ve got time for maybe two or three more, I think. Then we'll kick off the game jam. >>Laurent: How many unique animations do you typically have for a single Character? >>Ray: Again, that’s really dependent on the Character and what design sort of requests that they do, how complicated some of their attacks or their abilities or something like that. Is it just one fire and forget thing, or does it require a whole set of performing this action and needing to be able to walk and fall and turn, and all that stuff? But say for Kallari, I think we’re - goodness. >>Laurent: I would say typically it’s over 100. >>Ray: Yeah, we’re definitely over 100. I think locomotion alone is like 75 or something like that. >>Alex: Is that just because you’re blending in so many different things? >>Ray: We just have tons of transitions. >>Laurent: Yeah, locomotion is more of a known thing. It’s the ability part that’s very variable, so it really depends there. >>Ray: I would say, if someone said the budget for a Character was going to be 125, 130, 115, that would seem reasonable for what we’re doing right now. Obviously it’s going to be different for different Characters. Some Characters that need to be 100 percent keyframe for one reason or another, that budget is just going to have to be cut, because it’s going to have to go to down some. >>Chance: Yeah, and how detailed different abilities are with the Characters is definitely going to make a difference. >>Ray: Yeah, exactly. >>Laurent: Does the warping allow to mix two animations done at different frames per second? Like one anim at 15 FPS and the other at 20? Yes, it doesn’t really matter what FPS they have. I assume you mean the Speed Warping. What matters there is the speed that the animation was authored for. If we have in our case, per state, we have only one speed. So we do Speed Warping all the time pretty much unless you’re exactly at that speed. If you had animations that would cover a range, you would only use Speed Warping outside of that range. But animations can be any frame rate. It doesn’t really matter. Any chance that the Speed Warping node and any other additional ones will be exposed to the generic 4.11 Engine? Speed Warping and Slope Warping, definitely no. The other features we talked about, I’m not sure. I would say everything will make it into the Engine at some point. We definitely want to give Speed Warping and Slope Warping. When, I don't know. The marker sync, the blend profiles, and the AnimDynamics have all been done in the Engine, so they will be available shortly. It’s not 4.11. It will be soon after. >>Chance: Right, 4.12 timeframe. >>Laurent: Slope Warping has not been moved into the Engine yet, so we’ll do that first. More delays there. And when getting the animation states, did you know exactly all the states you were going to have before creation or was the process sort of experimental until all the animations were covered? It was very much experimental. The Character we showed is the first one we did for this. It was a big R and D. We spent about two months working on that. When we did the mocap, we sort of had an idea of we wanted the start, the stop, pivots, and the leans, and the slopes. We kind of knew the scope of what we wanted to do. But we had none of the tech pretty much. >>Chance: I’m sure too as far as design goes, that might change, that number as well. >>Laurent: Yeah. >>Chance: And what you expect. You might have to experiment a little bit more. >>Laurent: I would say the spin transition is one that came late. We didn’t have it originally. When we started playing with turn transitions and adding more lag, we realized that it would be useful to have the spin transitions, so we mocapped that later. But yeah, it was very much experimental in R and D. >>Chance: Cool. We’re going to move over and kick off the Game Jam here in a sec, but thank you so much. >>Alex: Thank you guys. Really great stuff. >>Chance: Really appreciate it. >>Ray: No problem. >>Chance: It’s super valuable. I can’t wait to see more of these features hit the Engine and see what the great community ends up doing with them. >>Alex: Yeah, very powerful animation tools. It’s very cool. >>Chance: It’s been a while since we have had y'all on, so we are super glad to have you back as well. Thanks again. Let’s go ahead and kick off this Game Jam. Before you push the button and update there, I just want to remind everybody at home, the Game Jam kicks off now. You’ve got until the end of the day Sunday. You’ve got until midnight on Sunday to create something and package it up, something in Unreal Engine 4. Package it up around the theme and submit it to a submission thread that’s on there. We’re about to push the thread live. There’s a new submission thread there and you have to download all the rules there too. There’s Epic swag to be given away, t-shirts to win. >>Alex: And of course, Allor to be frustrated. So make sure that you tune into Awesome Allor when he plays through all of the Game Jam games, and you get to watch his great frustration and enjoyment of various games. >>Chance: It’s always a lot of fun. He starts streaming right at midnight afterwards, and usually by the time I get in the next day, he’s still going. Feel free to tune it. I usually make it until about 3:00 a.m. and then I pass out with my phone. We’re doing a new t-shirt design as well. Our design team has that right now. We may have mentioned it last week. But thanks again Phillip for helping us pioneer the Game Jams with the t-shirt contest winning that, the one we’ve got here. We’re just going to refresh it for 2016 and moving forward. All right, now you can do it. >>Alex: Oh, now I can. Okay, thanks. >>Chance: So we have it loaded over here. Let’s go ahead and click on that forum thread. Load it over to the other screen. Scroll down just a little bit. >>Alex: There we go. >>Chance: And we’ve got, Don’t Push the Button! >>Alex: Don’t Push the Button! I’m psyched about this one. >>Chance: We were talking about this earlier. There were so many ideas that came out between Jess, Alex and I. So make something awesome. Surprise us. I can’t wait. It’s going to be fun. Also, we wanted to remind everybody too, we’re going to be showing the winners two weeks from now as opposed to one week from now, so we can get good footage of everybody’s game for the highlight reel and spend a little bit of extra time in the judging cycle and everything so it’s not - >>Alex: Sometimes it feels a little rushed. >>Chance: Kind of a little bit of a madhouse around here for those first three days coming back. It’s the 28th livestream we’ll be announcing the winner. Tune in, everybody. With that, thank you, Shelly. Thanks guys, thanks Alex. Thanks Jess. Clint, you’re pretty cool too. All right everybody, we’ll see you next time. >>Alex: See you guys. >>Ray: Bye.
Info
Channel: Unreal Engine
Views: 106,859
Rating: undefined out of 5
Keywords: Unreal Engine, Epic Games, UE4, Unreal, Paragon, Game Development
Id: 1UOY-FMm-xo
Channel Id: undefined
Length: 97min 56sec (5876 seconds)
Published: Fri Jan 15 2016
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.