I just feel like I have to comment this video. Hi, I’m an indie developer for quite some years now. Me and my small team are working on a game for some time now but we just recently re-started the whole process just to bring some new fresh air to the game. This motion matching system should bring most of the “fresh air”, since it really brings the locomotion and quality of your character’s movement to a completely new level. So I implemented the databases, animations, trajectory and everything and at the beginning it looked fantastic. I felt like god, to see my character behave AAA-ish. But as more things I wanted to add, the more complicated it became. The best example are the footstep sounds. As you know, you must add notifies to all the spots where the feet touches the ground in an animation. Well.. if you just add the notifies in the “move forward” animation, it will not work at all. Because the choosers table (a table that selects the best animations out of hundreds in the current situation) selects another animation all the time. This meant, that we had to add the notifies to ALL the 100+ walk animations. Walk sidewards fwd right, walk sidewards fwd left etc etc. And doing that with more than 100 animations costs time. But we did it. Than, we implemented our weapon system. There comes the other problem. Somehow, left hand IK did not work for this kind of animation system so we just changed the left hand position within the animation for aiming. BUT, with motion matching, there are at least 50 different aiming animations. Also there, we had to adjust the hand for every single animation. Then next, we wanted to add an offset for aiming. It did not work properly because of the motion matching system. And since all of this is pretty new, documentation for fixes or issue-solving is pretty “slim”. We could not fix it yet. And at the beginning, if our character interacts with something and should play a simple animation with the node “play anim montage” or just “play anim” it did not work and the character flew around. Because somehow, the motion matching pose flow could not be interrupted (we managed to fix it somehow). We are planning to integrate a lot of other more complex things. And now, we saw that we focussed too much on that motion matching thing. Which is why we will start all over again to get a new “fresh wind” but this time without the motion matching. For me personally, I think this is not something small studios should put their focus on. We will keep the trajectory and chooser-table-system in the game, since we think it’s a pretty good alternative to the usual blendspace method. But we will just add 5-10 animations for every movement and be happy with that. And I think other indie devs should do the same. The game will be great, but not because of the animations. Sure, it’s important to focus on animation, but it’s more important to focus on a smooth end experience and a clean backend structure, which is not given with the motion matching system right now. But I’m sure it will be better one day.
Motion Matching seems good for midsize/large companies where you’ll have one person/team dedicated to animation, but on a solo end it would be a death sentence in terms of development time
Yeah - I'm not exactly sure how development is supposed to scale for different characters with different locomotion style, or if it's a more brute-force approach that AAA can afford to do
This is something I really want to address in future releases. Personally I love getting the most out of small sets, and I want to build tools that enable users to put effort toward anims that matter, rather than spend precious time filling in coverage gaps. In my mind we haven't succeeded until teams of all shapes and sizes can use our stuff! It may be a bit until we can really get there (lots in the works I can't talk about yet), but perhaps I can squeeze in an experimental setup in a future release that leverages both the control of state machines, and the convenience of motion matching.
@@LongmireLocomotion the man himself! Yeah I would love to see what’s possible with fewer poses. The convenience of just smacking some anims in to a data set and not having to tweak angle/speed data in a blend space is freeing, but getting those anims in the first place is the big hurdle for most people. Would be very interesting to see a tool to create all the transitions from an 8-direction loco set using control rig or ML or something. Would definitely make it more approachable!
@@PrismaticaDev Yep that's definitely one way to alleviate the issue, and thankfully there seem to be many teams outside of Epic working on animation generation tools! But I think the main issue with offline generation is that you still have all that data you need to manage in-engine....all the tagging, setup, and memory budgets...it can still be cumbersome. For me, I'm most excited about improving our suite of pose warping tools so that we need less coverage in the first place. I'm 100% certain we can achieve similar results with just 4 directions....heck I've even gotten natural relaxed strafe behavior complete with start transitions working VERY well with just forward and backwards animations. And if animators think that means they'd lose some control, I'd argue they'd be doing the same thing in a DCC anyway: taking an anim and warping it a bit to get a new direction...pretty much manual pose warping.
So one thing about motion matching is it doesn't need 500+ anims to work. You want to think of it as a framework you build upon vs producing a huge volume of anims. Basically you don't need 50 blend anims between run forward and both L and R directions etc. You can use traditional techniques to fill in the gaps. Epic had a stream where they had 7 base animation sequences in the system and it looked pretty decent. Another advantage is the states that power it can be easily replicated. Things like IK/FK are expensive to replicate because the IK drivers are traditionally based upon world position, so you have to lerp between server ticks the position of the drivers; with this system the baked animations are present on both clients and so you only need to replicate the state changes to reproduce the results on clients. So there is a huge advantage there. I agree with you on the Only Up ALSv4 comparison. We will see a multiplayer parkour racer in less then 6 months that is just all male characters in street cloths using 100% this anim library. I think overall though its a really powerful system that will benefit people going for a more Tomb Raider esq style movement system for the main character without needing massive anim scripting work or advanced knowledge of how to do it.
Yeah for sure - I think with a fairly sparse database with a few important anime swapped out (run/walk FLRB) to give characters some individual style it could be a nice workflow
As a solo dev I'm planning on scenes with a couple hundred characters on screen and had no idea about the performance issues, so thanks for highlighting that!
The sample project definitely does have a few performance issues, but I'd like to chime in here, because I believe it's mostly down to how they've set up the system, and not an inherent problem with motion matching itself. The key reason for the poor performance is the sample project DOESN'T use thread-safe animation updates. So when there are a tonne of characters in the scene, the AnimBP's update function clogs up the game thread. Pose search (motion matching) itself isn't too tough on performance from my tests. And there are optimisation settings (at the bottom left of the pose search database) that you can use for less important, AI characters. An example of all of these optimisations can be seen in my Replicated Locomotion System called 'LocoMotion Matching' on the UE marketplace. For reference, 20 moving NPCs in my project run at a constant frame rate of around 220 FPS, at roughly 3-4ms on the game thread. I do find it strange that Epic haven't used thread-safe updates in the sample, since that seemed to be one of the main things they were stressing throughout the Lyra Sample Project.
@@KelechiApakama its so funny seeing your comment here considering I was looking at the pack yesterday. Havent gotten a chance to test it yet for myself, but I am in the same boat as I will have potentially a hundred or more characters on screen at one time- very very interested to see some showcases in the meantime.
If you're planning on scenes with hundreds of characters performance should be one of your main concerns when evaluating anything new. Shiny new toys rarely improve performance.
If you are planning on having hundreds of characters on screen, you should look up Animation Sharing. It's like an animation pooling system. So instead of hundreds of separate animInstances, you have as many animation instances as separate states and permutations. (3 Idles + 3 Runs = 6 anim instances). And the system makes the characters use Leader Pose that uses the state they are in.
dense data sets are kinda the nature of the beast with motion matching. more often times, it's benefits (insane fidelity and workflow simplification) outweigh the shortcomings (learning curve, some inflexibility, performance with many characters, etc.). Additive layers are probably the solution for different "styles" (assuming one doesn't want to recapture all 500 anims) but you can get a ton of mileage out of additive animation these days. Overall I think bringing motion matching to the masses will only be a good thing moving forward (no pun intended)
Yeah I was thinking the same thing with additives, although they can only get you so far (adjusting pose, but not timing/pacing) For example, if I wanted a character to be able to limp with a left or right injured leg, it would pretty much require a re-do of all the key animations AND transitions
Agreed, looks quite a lot like machine learning AIs, give it a hell lot of data, throw in some numbers and be surprised with the results. They might not be perfect every time but so isn't the real life.
I mean, if you hadn't been following it, the guy that created ALS is working on this project. General updates will be with major releases, so don't expect a lot to change between now and 5.5
Yep yep - I’m looking forward to updates to see where it goes, and he’s alluded that they have some kind of secret sauce in the works which I’m very keen to see haha
das why i just hated this new system cause even so hes working with epic, the damn guy goes and creates his own mannyquin , AGAIN, and even some more idiotic, it has no FBX export to correct other characters.
Excellent information and opinion. I agree with you entirely. I think that we'll see a lot of newer indie devs, or people with specific single-player projects, who use and package with this. I think for those of us who are making multiplayer games/are already into our projects, probably not for us. The idea is nice! But I mean, I do all of my animations from scratch in Blender because of optimization for my game with multiplayer. Reason being, just like you've mentioned, for each of my weapons, or at least genres, I need new animations. So I have crouch, walk, jog and run/sprint. Doesn't sound like a lot until you take into count forward, backward, strafe left, strafe right, diagonal left fwd, diagonal right fwd, diagonal left bwd, diagonal right bwd. Then take into count my aim offsets for the head/torso to follow the mouse in those states (additive). Now take into fact the items I animate the player holding: one handed weapon, one handed weapon with offhand, one handed weapon blocking and blocking with offhand, then two handed weapons, two handed weapons blocking, then bows, then crossbows. So just for my one handed weapons I have forward, backward, strafe left, strafe right, diagonal left, diagonal right, and those all in crouch, walk, jog, run/sprint. So 8x4=32. 32 animations for my one handed weapon. Hmmm, what about unarmed, with offhand, blocking, two handed, blocking, bow, crossbow...? I have 224 animations, roughly. Finally you add other states like jumping and swimming, as well as emotes, like sitting, waving, sleeping... You can get all of your animations for a humanoid rig up to 500 sure, but they will be more optimized and run better in a multiplayer game. If you were to take these 500 animations and then add weapons, etc. you're talking about thousands of animations. Crazy. I can't imagine using this. Does look beautiful though. Good luck with an open world map with structures, foliage, water, niagara effects, npc's and their pathing, weather, music, and keeping a good frame rate. Yikes! Sorry for the rant. Don't even get me started on AI assets.
A natural downside is, you need a tons of animations. If you are a solodev like me, I cant provide 100 animations for all states maybe...5. So I either take these and dont change any of them or I dont use the system at all.
The thing I'm wondering is like, does this REQUIRE that many animations to look good and make work? Could this not still be functional with a smaller database of animations and just be utilized to better blend them together? I get that more animations will obviously make it look better, but what I more mean is like... what is the lower limit of animations where this falls apart and doesn't provide a benefit?
@@riaayo5321 an experiment to test this should be fairly easy. Take the sample project, go into the sparse data set and remove every animation from the database that you would not author for your project and see how it looks without those.
@@PrismaticaDev There are some stuff laying around UA-cam creating Motion Matching data using Motorica AI which is great for creating animations for different velocity and directions. Yet, I couldn't get a decent result with it. Also, keep in mind that it cannot be used commercially.
Maybe use motion matching only for the player character and the rest of the NPC use blend space. Since it's the player character that switches motion a lot and the main focus of the camera.
As impressive as motion matching is, I don't see it being too useful unless you're heavily utilizing mocap (which Epic did). I researched motion matching a bit ago and used Lyra's locomotion animations (about 20) to test it out, the character had obvious stuttering because there was simply not enough data. If using traditional workflows, I think that creating enough animations to have the movement look natural with motion matching is not worth the time sink.
You are right. If you have a mocap studio, you can theoretically create like a 5 minute long animation will all possible movement bits and put it into the database and you should be already there %75 percent. This approach Epic provided us is a very modular type of motion matching, which comes with the exaggerated complexity.
And with mocap you can get very stylized animation (say, character mannerisms) for very cheap, since you don't need to map them out in a controller or anything
Implementing custom animations and states into a setup like this would be like jamming your fingers into active industrial machinery to add extra pieces.
It just feels like another tool epic is creating to make larger teams more likely to move over while also increasing the outside appearance of asset flips which will help the image of unreal engine long term, but I feel like it's just going to turn into another buggy experimental plug-in that never gets updated and is ultimately forgotten about by epic.
Were you running the dense or sparse databases when testing this, the sample supports both. One is a significantly cut down version with less animations in the pose choosers.
It was likely the dense database, as I left everything default. It definitely can be more performant with sparse DB's but I think because of the search/evaluate/select going on, I don't think it will ever be as performant as deterministic animation methods (blendspaces etc)
I think the performance isseus are not from the motion matching technology itself. In one dev-talk the developers talked about how they had to optimize the whole system to be possible to get it into fortnite without to much performance impacts. Also they talked about the challenge how they where able to integrate it into existing characters with defined motion. It was a really prioritised goal and I think they developed a good work around. Also I think in future there will be a more cooperation with "motorica". So maybe in future you only have to define movement styles and get all the needed animation for motion matching out of a motorica plug-in. I think there is big potential in future also and especially for solo devs.
To be honest, I'm not a fan of the side running 3:06 to left or right ... it looks so unnatural, it only fits in a tennis game. :) Many games use the 8way run (not sure what's the correct term of the movement that was invented for Crash Bandicoot), that makes the motion matching almost useless.
wonder how this would play out for only playable characters, and not NPCs. Ofcourse the work load is doubled at that literal thought, but the polish the game would feel would be really nice
I've been working with motion matching since it came out and i use vary few animation in conjunction with orientation & speed warping & foot locking and I get better results than ive ever gotten with any other method and my anim bp's are extremely small in memory.. this "example" is not a good example in my opinion but I understand why they do things like this.. Idk it takes a lot of playing around with it to understand what you NEED, and like i said I've been playing with it for a long time now so I just wanna say, dont look at this example and just write it off.
Yeah some others have echoes the same sentiment - the example project is extremely high-fidelity but also high-complexity which makes it seem like a lot more work than necessary. Would love to see some comparisons with a smaller library, especially when it comes to performance as well. I’ve also been thinking MM could be really great for quadrupeds as well
I feel like you probably wouldn't want motion matching on NPC's and you'd still get all the benefits of the motion matching on the character the player is looking at the most without too much of a performance hit.
Yeah this was one of my thoughts as well. It certainly feels and looks great when you’re in control of the character but further away the small details are less noticeable. You could likely use a much smaller sample library for NPCs so it’s finds the best match quicker, and that way you wouldn’t need to use two completely different animation methods/sets for humanoid characters and stuff. But a blend space will always be cheaper to process because it’s entirely predetermined
@@PrismaticaDev You can have fallbacks to the usual state machines but you're doubling your work. And i didn't try the full version yet , only dabbled with the betas last year but there was a lod type system. You can basically have lightweight simplified sets to switch out which is how Ubi does it. As soon as you add a ton o different sets however if you can't for some reason use additive animations or control rig (which I find works better) to change the posture, then it becomes almost impossible to manage. The amount of work at that point might be just better to make traditional animations. Since I'm commenting here, I wish you talked about the latency as well. A lot of devs use MM in games incorrectly. I had some discussions on why its wrong to use it in stealth games that require pinpoint precision, unless its cover based like TLoU (even in that they used a hybrid pipeline, when it needs precision its root motion) and I think its important to make it clear that it does have latency, its unusable for some type of games, has limitations and it's always a battle between latency/responsiveness and quality. Most people seem to think MM is the answer to all things, just drop a ton of mocap and you have great animations, that's not the case from a gameplay standpoint, it may look great but play like crap for your type of game. The best example is the old FIFA vs PES discussion, many players loved the responsiveness of PES for competitive play, where FIFA had MM and looked great, but it always played like the characters where chasing your controls, some people were okay with it and loved the animations, some hated it cause it wasn't responsive. 2 types of approaches in the same type of game with very different results gameplay wise.
Motion matching is best for realistic, hi-fidelity art styles and makes authoring animations sooooo much easier for those situations. The performance can be improved substantially with less dense data sets, using tagging systems and potentially down the line using machine learning models to pare down the datasets further, and as you mentioned, shifting the searches onto a thread or even the GPU in the case of the ML approach. The bigger issues with motion matching in indie studios is the relative lack of control over the chosen animation, which can make a designer's life difficult at times but I think this can be offset through more extensive usage of all the new rigging tools and layered control rigs that dropped with UE5.4.
I wanted to try motion matching but 5.4 runs insanely poorly on my very good rig. Takes 1-3 seconds every time I try to PIE. Also constant hangups on basic things like clicking on blueprints or moving around the graph.
Motion matching is a good tool for a very specific niche. (and obsolete with the animations through AI that are already present although they are not yet refined.) I still prefer to combine mine with additive and semi-procedural animations. achieving practically the same results but with 12 animations instead of 500. And the best thing is that since it is procedural it reacts to any surface, while with motion matching I would need another 500 more. But, it's free! There really can't be much to complain about.
as someone who really dont care about visual side of game that much ill be using this for sure. Its free realestates . Sure, the animations look generic and they have no personality, but they look great, way way WAY better than anything i would bother making/setting for the game anyway i watched the UE showcase they had about it, and im looking forward to the future of this, what we see is, from what i understood, BETA of what the system is supposed to be since they didnt had much time
Yeah - I'll definitely be keeping an eye on it as well so see how it goes. I think once there's an easy way to generate the transition anims from a set of base locomotion (some people have been mentioning machine learning etc) then it might even be easier
Thanks! This was helpful. I didn't have the time to dig into this project but wanted to know what you revealed here. I had my suspicions so I just shelved the testing. I knew it was immature tech that would need time to be made more optimal, but this answered most of the rest of my decisions on when/where to use it. For me, at least for now, this is at least a year away from being of use to my purposes. It's nice flash, but as you said most solo devs won't find it useful outside of very specific game types.
Yeah I'm not a fan of motion matching, using blendspaces is easier and you can still get really good results. Also I exported the walk and run animations into another project and using the basic Foot IK makes the legs do weird shit while walking up slopes I tried to edit the offsets and it did not really help. My quick fix was to turn off foot IK while moving but in the end I will probably just use different animations. If anyone has an idea on how to fix please let me know.
i wonder where the perf drop is coming from, if its from skel mesh nanite is coming for that soon too. if its from char bp ppl should limit the number of motion matched chars in their games for now
If we could use the paths of all these animations, and combine it with something like motorica, we might be about to get a ton of variations out of this.
Hi, agreed on the 500 animations remark, am having the same exact thought. The AnimBP values aren't ThreadSafe, possibly one reason why your FPS hit below 30? Also, someone did a comparison between 50 ALS and 50 GASP (Game Animation Sample Project) characters and concluded that GASP, in terms of performance wise, is better than ALS. So I'm guessing the second reason is PC specs? On my end, I have RTX 3800ti and only in GASP I keep getting the "streaming pool size" error. Eitherway, GASP isn't complete (as decribed in the Read Me found on the map), so yeah. ✌
Hey hey! I think the comparison between ALS and the MM example is a bit flawed, since ALS itself runs a lot of extra BP code on the character compared to the MM example character and is usually regarded as quite unoptimized when used at scale. The reason I did my quick test the way I did is that both Characters were the exact same, so they had the same BP and SK mesh overhead and so only the AnimBP was changed. Also keep in mind I was streaming to UA-cam and Twitch and also recording at 2k resolution during the tests haha but that shouldn't have made much difference as it was the same in both scenarios.
With sprinting don't you just speed up the animating and its been tested, animbps chug more motion matching is very performant unless you have a custom way to calculate animations
Awesome tut/discussion Charlie....my question to you is....can you motion match quadrupeds using your own animations?Basically custom animations using the motion matching framework or would you just have to use the traditional blend spaces workflow?
I wish you would make more vids. Anyways I'm on the fence with regard to motion matching. I wish there wasn't all that "complex" data to learn, sift through, and / or understand related to channels, velocities, trajectories, and so on. On a semi related note, am I the only one that can't stand the emphasis AAA game companies place on SUPPOSEDLY realistic / immersive animations? I think the constant start stop and pivot animations in games actually look ridiculous a lot of the time. When I replay older games without the weighty "immersive" acceleration based movement, I find the movement and controls so much more enjoyable.
Great point - I think the trouble with some AAA games is that the realism can get in the way of actual movement. GTA/Red Dead are perfect examples of movement becoming clunky for the sake of looking good. I think Motion Matching is actually one of the best combinations of feeling great and looking great simultaneously, since it uses Capsule motion like regular movement does. So I definitely prefer it over root-motion movement with those annoying turn-in-place animations that you get locked in to
In Half-Life Alyx all enemies like the Combine use Motion Matching, But in that game your only really fighting a max of 5 at most So i could totally see it being reasonable if your game has smaller arena fights with 5-10 NPCs max but defo not for hordes of people
7:15 Hey PrismaticaDev, I noticed some other video's showing that Motion Matching was more efficient than the traditional animation state graph. I wonder, what the difference between your test and his was. I wonder how the number of animations within the motion matching and within the traditional animation state graph influence the results. If u were to add the same amount of animations to the traditional animation state graph would the results be different?
I believe in other tests I've seen, they were using ALS V4 as the basis of a "normal animation graph" which I think is a bit misleading. ALS V4 is, in the words of its creator, an overly complex system meant as a "here's what's possible" sort of system. It also includes a boat-load of Blueprint logic related to movement on the character-code side of things as well as in the AnimBP which isn't completely necessary. I've also seen other people using different SK meshes which also skews comparisons due to skinning cost scaling with vert/bone count. My test was a "best case scenario" which uses the exact same Character BP between both examples, so the only difference is the AnimBP. In a "best case scenario" you'd just be using a very basic 8-way blendspace which is just reading the Direction and Speed variables. Obviously it doesn't look great in most cases without some additives and there is foot sliding, but it shows that there IS a noticeable cost to Motion Matching itself. TLDR: My test was between Motion Matching and Blendspaces, not between Gameplay Animation Sample Project and ALS V4.
I'm using motion matchint since Unreal 5.1, the diference is that this one is the complete version of what i was using The real problem is the performance, they should make something about the Game thread, an easy plugin to solve all the problems of game thread, unfortunately i have to use at max 15 A.i(NPC) on scenario or the fps will drop below 60 fps
Yeah I wonder if it’s because they use a smaller sample library or they have it thread-safe. Someone told me in Fortnite it IS more expensive than before but not as much as this sample project
Pretty sure much of it is simply the Blueprint overhead....For our internal projects, all event graph logic (even functions) have to get nativised for anything to ship. Nobody likes it but that's just how BP is. Obviously we can't do that here, as that would prevent BP users from dissecting the system... ...but in the future things should get better.
I’m curious when you tested this were the cameras on the Motion Matching NPCs turned off? I see they all have cameras and if your rendering the game from 51 perspectives that’s defo whats chugging everything down I assume you turned them off because otherwise the game would probably crash lol
I have been (and still am) blown away by motionmatcning ever since experiencing it in the last of us 2. I reckon if you’re making something that style (no large crowds, etc etc) you could make a great looking game with a great story… with terrible AI voice acting lol. But seriously, I love this stuff and I can’t wait for it to continue fleshing out and becoming more user friendly
100%, it seems great for a few incredibly animated characters and could definitely be used alongside other systems (mobs could just use simple animations but hero characters use MM)
I would have rather seen a more comprehensive blendspace, where instead of now needing 500+ animations to make a comprehensive motion blueprint, instead we could use the same 8 or 16 or 32 animations, but the blend space does more comprehensive 'tweening, to programmatically create the seamless motion that looks like we're seeing here. Personally I'd rather create a _set_ of characters with _unique_ motion, rather than one character with really blended motion (if I were putting that much effort into creating animations). It looks like the predictive algorithm is very good, but I feel (based on your analysis) that the animation could have been done in a better/more efficient way, that would suit more [smaller] studios. Thanks for taking a dive into this one, I've been wanting more information since it came out (but haven't had a chance to dig into it myself), and I can now see it's only partially what I thought it was.
I agree completely - I think there’s definitely potential for a good balance to be found within this system, I’d love to see a simplified version of it
@@PrismaticaDev I’m having lots of thoughts on this; I’ll be playing around with it at some point. I think it could make a nice base for a parkour system (or similar), though there are some missing elements. I think blended with some programmatic ik+fk an interesting system might be developed. I’ll let you know if I come up with anything useful.
I haven't watched the video yet, this is really just me attempting to organize my thoughts before taking your input into consideration. I have a feeling my thoughts may change after the video. As a solo dev working on a third person game with melee combat, I'm thinking I'll switch to motion matching for player combat and maybe copy the demo for movement, but stick to the classic system for NPCs. The new system seems like a ton of work to set up, but I think my game's combat in particular would benefit a lot from the way pose search databases work. There are a lot of variables that affect the way an attack or block should play out, so filtering through an animation database with enums seems like a great way to handle that.
I was thinking the same thing but then how will the quality of the motion look side by side. Your character swinging that bastard sword so smoothly while your NPC's stutter there way to attack you ? Probably not very noticeable but you get my point.
Yeah it looks great, but I have the feeling that it's supposed to be the most complex (and best) result you can get with motion matching. I've seen videos about it before this sample project, as they released the motion matching functionality with 5.4 a few months ago, and it was much much less complex to work with it. It was literally just taking some animations (like the Lyra example animations) and throwing them into a database. It looked decent, but you still do get some foot sliding, which is why I suppose they added stuff like the animation curves for the speed, foot speed, position etc ... I'm really curious how the performance of the basic motion matching setup is.
Yeah it would be nice to see the simplest, bare-bones example of how it can be used. I think the example project looks great but maybe comes off as too daunting to recreate/build from
Commenting for the algorithm. I love your tutorials, you helped me learn tons about physical animation! Also thank you for this vid, I am still using 5.3 and do not want to update to 5.4 so I haven't been able to check motion matching out lol. I was curious if there were any animations I may want to "borrow" from it, but it doesn't seem like it is actually 500 unique different animations, like interact animations etc.
For people like me, I don't recommend neither the animations or the system itself for FPS games. I am no expert by any means but let's be honest, those animations weren't made for FPS and you just better off with a blendspace both in performance and simplicity matters, as in FPS games the hands movement is more important than legs or body, so in my opinion, if you really want to create something with lit you can use it but if you want to ship your game, just use blendspaces. Charlie didn't mention this but i wanted to mention in case anyone needs this
You mentioned something in the start I found curious. You think Nanite is expensive? How come, good man? I'm asking as a scene builder, and I use Nanite often and I see performance increase usually. There are exceptions of course, and I was just wondering what your experience was :)
@@PrismaticaDev Looking foward to see your analysis on the Mutable Character System. Does it save on drawcalls(by merging the skeleton or something like this) or it's just a side grade for something you could develop with a little elbow grease?
@@Vondora yeah it can solve a bunch of issues and allow for more creativity/less rigid customization, which is great. There's already SK merging functionality since 5.0 but this adds on a bunch more stuff as well
That being said, you could technically do it with some elbow grease and Geometry Script/C++ knowledge, but you'd arrive at the same conclusions/implementations as the plugin. So it seems like a good time-saver :)
It's a great system for singleplayer games. But the issue i have with this is that you need to use root motion for motion matching and thats just a nightmare to work with in multiplayer projects. State machines will not work properly with it so you would have to handle it all with montages which seems insane to me. (Atleast that's what everyone said so far) This might work for short fire and forget montages but for the consistently triggered movement stuff it's hell and also fills up the network bandwidth because you have to replicate it all.
I don't think this is entirely correct. The animations need to have root motion so the matching system can extract trajectory data, but the movement is still capsule driven. So what you're replicating is not root motion driven locomotion. The root motion is only in the anims for data. I hope that makes sense.
@@fray989 This is correct it uses the Root Motion data for the MM calculations but not for the actual movement itself so doesn't have any of the issues with Multiplayer... though the current sample doesn't replicate the Trajectory (there is a now free plugin to do this) which means OOTB it doesn't look good in MP.
@@shannenmrI keep saying this. You don’t need to replicate the trajectory only the acceleration. For traversal you would benefit from doing all of your traces in a safe movement state using flags in the CMC. Lyra has an example of the replicated acceleration part.
Why do I have the feeling, in this second hundreds of LLMs are feed witht hese 500 animations, so companies will just generate them instead of actually letting their last animator making them?
Yep I know at least 1 company doing it at motorica, they have some pretty impressive beta right now. And it's pretty easy to mix together a ton of different styles and animation sets. Give it another 6-12 months and there will be a ton of stuff out there. 500 will be nothing to generate in various styles.
Can you elaborate why you have mixed feelings about Nanite? Like a full blown video? From my tiny amount of experience [and a lot of reading] it seems like just almost always the best choice [apart from translucent stuff].
That's a great question! There are a couple of reasons, one being backwards compatibility and over-reliance on the tech, but the other reason is that it currently doesn't do -everything- (such as translucency, drawing to RVTs and using Vertex Paint) which would mean I'd be using both systems at the same time, and both systems would be running their overhead. Nanite seems to have a higher initial cost but scales much better compared to traditional geometry, so just using a little bit of Nanite is kinda a bit of a chugger
Thanks you so much for this video, you saved me hours of investigation testing this, motion matching is completely useless for VR as it is now, that performance cost is unacceptable and I could only see this being used for the NPCs and stuff which is precisely not a great scenario for this system.
I think some indie developers will use it, even some will use all the 500 free animations. Big studios will use the system (I'm sure they already do), but they will not use the 500 free animations because they looks too generic.
Something I don't necessarily like about this is that smaller developers are "forced" to use this, which will cause a lot of games to feel the same. Obviously developers aren't actually forced to use this, don't get me wrong - but now, devs looking to create their own locomotion solution will be at a time disadvantage. Sometimes it's nice not to have an existing solution for something so important such as player animation, because that's how you get games with varying identities
The sample pack is pretty awesome, heavy on performance but still awesome. An impressivce showcase. But what really stands out fo rme is the amount of the free anims they gave. I've gone through them and damn, what a beautiful set of anims. From turn in place, to start and stop, to pivots and jump lands and starts. This pack is even better than kubolds movement pack and it's free. I exported the anims and I'm using them now in 4.27 with AGRPRO and 100%, they replace kubold for me. Can't wait for them to add the weapon anims and hopefully they keep the quality. As for the performance of the sample pack, its ue5, what did you expect hahaha. Thats why I still use ue4. I want to make games for everyone to play, not just those that can afford to run it, but that being said, the tools being used are pretty new and experimental, so I expect major improvements in future updates. Performance in ue5 has improved a lot with updates. 5.1 runs at 30-40 fps without any changes on my pc. 5.4 runs at 60-70 so they definitely working on improving performance.
That performance test is not really a fair shake. I’m sure you didn’t use more than 10 animations in the blend space setup. If you were to disable majority of the anim in the database those numbers would be pretty much identical. You basically just compared 2 people walking the same distance but one of them was wearing weighted clothes. Of course the guy without extra weight will get to the end faster
As usual with unreal another "great looking and easy to works with thing watch this tips tutorial and you learn to use it no time" will turn out that will not work outside suggested use much. If you want to make something different, because that how creativity works, you will struggle.
Firstly, anim blueprint performance analysis is totally made up. You can't just look at the FPS and say "well this thing is slower then this thing, so this is bad". And then you're comparing one of the hardest anim blueprints and literally two node blueprint. Of course it is going to run faster, what did you expect. Secondly, you're not animation bound, you're skeletal mesh bound and movement bound in this case, because their update are MUCH SLOWER IN general, then animation update. Please learn unreal insights (little recording button on the right-bottom) so you can actually understand where performance issue is.
The Character class is the exact same in both scenarios, using the same SK mesh, only the AnimBP has been changed, so there isn't any difference in the movement code/time and the SK mesh skinning time, the only difference is the time to evaluate the pose. We looked at the profiling tools on stream but a tonne of small text doesn't make for a great video, so just the end result was shown in the video. Blendspaces (pre-determined anims for a given value) is always going to be faster than MM (searching for an anim in a library based on the trajectory and also the current pose for blending)
@@PrismaticaDev overall misinformation here and there. You don't have to use as much animations as shown in this sample to get stunning results. And all of these animations can also be used in blendspaces if one wish.
I don't think I've provided any misinformation - the video is titled "my thoughts" and I've never once claimed to be an expert in Unreal Engine, as I've only done Game Dev for 3 years. I wouldn't call it "stunning" results with less animations, from what I've seen it just seems to be on par with Blendspaces but with all the additional setup and data. Some of them can be used in Blendspaces, which is great, and the vaulting animations can make for great montages, but the vast majority are very niche (all the transition anims) which is fine, since it's a MM example project, but I think people had the idea that it would be more of a general locomotion library
It always depends on their projects, not every indie dev thinks the same. Some like 2d, others 3d, some 16bit, other extreme detailed 2d graphics. If Unreal is not a good engine for indie developers, which engine would you suggest me if I plan to make games that got graphics similar like Stellar Blade or Wuthering Waves ?
@@paluxyl.8682 I might have been wrong. I mean, after several years of being intimidated by learning UE blueprinting ( outside of shaders ), I found a good explanation of most important blueprints, as well as looked in to c++ structure, and I came to realisation, that yes, I know what to do with it and I will be developing something in UE. But, it's going to be very specific type of game. For 2d games, I recommend either construct3 or raylib. Also, I was very agitated yesterday by something development related, and flip-flopped today towards Yes let''s do it in UE.
![My plugin is OUT NOW! [UE5] - Prismatiscape Interaction Plugin Feature Overview](http://i.ytimg.com/vi/OgXrpMdpkHA/mqdefault.jpg)
![Intro to Flow Maps [UE5]](/img/n.gif)
I just feel like I have to comment this video.
Hi, I’m an indie developer for quite some years now. Me and my small team are working on a game for some time now but we just recently re-started the whole process just to bring some new fresh air to the game.
This motion matching system should bring most of the “fresh air”, since it really brings the locomotion and quality of your character’s movement to a completely new level.
So I implemented the databases, animations, trajectory and everything and at the beginning it looked fantastic. I felt like god, to see my character behave AAA-ish.
But as more things I wanted to add, the more complicated it became.
The best example are the footstep sounds.
As you know, you must add notifies to all the spots where the feet touches the ground in an animation. Well.. if you just add the notifies in the “move forward” animation, it will not work at all. Because the choosers table (a table that selects the best animations out of hundreds in the current situation) selects another animation all the time. This meant, that we had to add the notifies to ALL the 100+ walk animations. Walk sidewards fwd right, walk sidewards fwd left etc etc. And doing that with more than 100 animations costs time. But we did it.
Than, we implemented our weapon system. There comes the other problem. Somehow, left hand IK did not work for this kind of animation system so we just changed the left hand position within the animation for aiming. BUT, with motion matching, there are at least 50 different aiming animations. Also there, we had to adjust the hand for every single animation.
Then next, we wanted to add an offset for aiming. It did not work properly because of the motion matching system. And since all of this is pretty new, documentation for fixes or issue-solving is pretty “slim”. We could not fix it yet.
And at the beginning, if our character interacts with something and should play a simple animation with the node “play anim montage” or just “play anim” it did not work and the character flew around. Because somehow, the motion matching pose flow could not be interrupted (we managed to fix it somehow).
We are planning to integrate a lot of other more complex things.
And now, we saw that we focussed too much on that motion matching thing. Which is why we will start all over again to get a new “fresh wind” but this time without the motion matching.
For me personally, I think this is not something small studios should put their focus on.
We will keep the trajectory and chooser-table-system in the game, since we think it’s a pretty good alternative to the usual blendspace method. But we will just add 5-10 animations for every movement and be happy with that.
And I think other indie devs should do the same. The game will be great, but not because of the animations. Sure, it’s important to focus on animation, but it’s more important to focus on a smooth end experience and a clean backend structure, which is not given with the motion matching system right now.
But I’m sure it will be better one day.
Motion Matching seems good for midsize/large companies where you’ll have one person/team dedicated to animation, but on a solo end it would be a death sentence in terms of development time
Yeah - I'm not exactly sure how development is supposed to scale for different characters with different locomotion style, or if it's a more brute-force approach that AAA can afford to do
This is something I really want to address in future releases. Personally I love getting the most out of small sets, and I want to build tools that enable users to put effort toward anims that matter, rather than spend precious time filling in coverage gaps. In my mind we haven't succeeded until teams of all shapes and sizes can use our stuff!
It may be a bit until we can really get there (lots in the works I can't talk about yet), but perhaps I can squeeze in an experimental setup in a future release that leverages both the control of state machines, and the convenience of motion matching.
@@LongmireLocomotion the man himself! Yeah I would love to see what’s possible with fewer poses. The convenience of just smacking some anims in to a data set and not having to tweak angle/speed data in a blend space is freeing, but getting those anims in the first place is the big hurdle for most people. Would be very interesting to see a tool to create all the transitions from an 8-direction loco set using control rig or ML or something. Would definitely make it more approachable!
@@PrismaticaDev Yep that's definitely one way to alleviate the issue, and thankfully there seem to be many teams outside of Epic working on animation generation tools!
But I think the main issue with offline generation is that you still have all that data you need to manage in-engine....all the tagging, setup, and memory budgets...it can still be cumbersome.
For me, I'm most excited about improving our suite of pose warping tools so that we need less coverage in the first place. I'm 100% certain we can achieve similar results with just 4 directions....heck I've even gotten natural relaxed strafe behavior complete with start transitions working VERY well with just forward and backwards animations.
And if animators think that means they'd lose some control, I'd argue they'd be doing the same thing in a DCC anyway: taking an anim and warping it a bit to get a new direction...pretty much manual pose warping.
Need a whole ass Mocap team.
They are adding nanite for skeletal meshes in 5.5 so I'm curious to see how it will work in terms of performance.
So one thing about motion matching is it doesn't need 500+ anims to work. You want to think of it as a framework you build upon vs producing a huge volume of anims. Basically you don't need 50 blend anims between run forward and both L and R directions etc. You can use traditional techniques to fill in the gaps. Epic had a stream where they had 7 base animation sequences in the system and it looked pretty decent.
Another advantage is the states that power it can be easily replicated. Things like IK/FK are expensive to replicate because the IK drivers are traditionally based upon world position, so you have to lerp between server ticks the position of the drivers; with this system the baked animations are present on both clients and so you only need to replicate the state changes to reproduce the results on clients.
So there is a huge advantage there.
I agree with you on the Only Up ALSv4 comparison. We will see a multiplayer parkour racer in less then 6 months that is just all male characters in street cloths using 100% this anim library. I think overall though its a really powerful system that will benefit people going for a more Tomb Raider esq style movement system for the main character without needing massive anim scripting work or advanced knowledge of how to do it.
Yeah for sure - I think with a fairly sparse database with a few important anime swapped out (run/walk FLRB) to give characters some individual style it could be a nice workflow
yes but at that point, why use motion matching over State machines when it eats up at data and has a way more overcomplicated file storage system
As a solo dev I'm planning on scenes with a couple hundred characters on screen and had no idea about the performance issues, so thanks for highlighting that!
The sample project definitely does have a few performance issues, but I'd like to chime in here, because I believe it's mostly down to how they've set up the system, and not an inherent problem with motion matching itself.
The key reason for the poor performance is the sample project DOESN'T use thread-safe animation updates. So when there are a tonne of characters in the scene, the AnimBP's update function clogs up the game thread. Pose search (motion matching) itself isn't too tough on performance from my tests. And there are optimisation settings (at the bottom left of the pose search database) that you can use for less important, AI characters.
An example of all of these optimisations can be seen in my Replicated Locomotion System called 'LocoMotion Matching' on the UE marketplace.
For reference, 20 moving NPCs in my project run at a constant frame rate of around 220 FPS, at roughly 3-4ms on the game thread.
I do find it strange that Epic haven't used thread-safe updates in the sample, since that seemed to be one of the main things they were stressing throughout the Lyra Sample Project.
@@KelechiApakama its so funny seeing your comment here considering I was looking at the pack yesterday. Havent gotten a chance to test it yet for myself, but I am in the same boat as I will have potentially a hundred or more characters on screen at one time- very very interested to see some showcases in the meantime.
If you're planning on scenes with hundreds of characters performance should be one of your main concerns when evaluating anything new. Shiny new toys rarely improve performance.
If you are planning on having hundreds of characters on screen, you should look up Animation Sharing. It's like an animation pooling system.
So instead of hundreds of separate animInstances, you have as many animation instances as separate states and permutations. (3 Idles + 3 Runs = 6 anim instances).
And the system makes the characters use Leader Pose that uses the state they are in.
@@KelechiApakama Which nodes exactly are thread-safe updates?
My thought exactly was that. “Imma just take the animations thank you”.
dense data sets are kinda the nature of the beast with motion matching. more often times, it's benefits (insane fidelity and workflow simplification) outweigh the shortcomings (learning curve, some inflexibility, performance with many characters, etc.). Additive layers are probably the solution for different "styles" (assuming one doesn't want to recapture all 500 anims) but you can get a ton of mileage out of additive animation these days. Overall I think bringing motion matching to the masses will only be a good thing moving forward (no pun intended)
Yeah I was thinking the same thing with additives, although they can only get you so far (adjusting pose, but not timing/pacing)
For example, if I wanted a character to be able to limp with a left or right injured leg, it would pretty much require a re-do of all the key animations AND transitions
Agreed, looks quite a lot like machine learning AIs, give it a hell lot of data, throw in some numbers and be surprised with the results. They might not be perfect every time but so isn't the real life.
I mean, if you hadn't been following it, the guy that created ALS is working on this project. General updates will be with major releases, so don't expect a lot to change between now and 5.5
Yep yep - I’m looking forward to updates to see where it goes, and he’s alluded that they have some kind of secret sauce in the works which I’m very keen to see haha
das why i just hated this new system cause even so hes working with epic, the damn guy goes and creates his own mannyquin , AGAIN, and even some more idiotic, it has no FBX export to correct other characters.
Excellent information and opinion. I agree with you entirely. I think that we'll see a lot of newer indie devs, or people with specific single-player projects, who use and package with this. I think for those of us who are making multiplayer games/are already into our projects, probably not for us. The idea is nice! But I mean, I do all of my animations from scratch in Blender because of optimization for my game with multiplayer.
Reason being, just like you've mentioned, for each of my weapons, or at least genres, I need new animations. So I have crouch, walk, jog and run/sprint. Doesn't sound like a lot until you take into count forward, backward, strafe left, strafe right, diagonal left fwd, diagonal right fwd, diagonal left bwd, diagonal right bwd. Then take into count my aim offsets for the head/torso to follow the mouse in those states (additive). Now take into fact the items I animate the player holding: one handed weapon, one handed weapon with offhand, one handed weapon blocking and blocking with offhand, then two handed weapons, two handed weapons blocking, then bows, then crossbows.
So just for my one handed weapons I have forward, backward, strafe left, strafe right, diagonal left, diagonal right, and those all in crouch, walk, jog, run/sprint. So 8x4=32. 32 animations for my one handed weapon. Hmmm, what about unarmed, with offhand, blocking, two handed, blocking, bow, crossbow...? I have 224 animations, roughly.
Finally you add other states like jumping and swimming, as well as emotes, like sitting, waving, sleeping... You can get all of your animations for a humanoid rig up to 500 sure, but they will be more optimized and run better in a multiplayer game.
If you were to take these 500 animations and then add weapons, etc. you're talking about thousands of animations.
Crazy. I can't imagine using this. Does look beautiful though.
Good luck with an open world map with structures, foliage, water, niagara effects, npc's and their pathing, weather, music, and keeping a good frame rate. Yikes!
Sorry for the rant. Don't even get me started on AI assets.
A natural downside is, you need a tons of animations. If you are a solodev like me, I cant provide 100 animations for all states maybe...5. So I either take these and dont change any of them or I dont use the system at all.
The thing I'm wondering is like, does this REQUIRE that many animations to look good and make work? Could this not still be functional with a smaller database of animations and just be utilized to better blend them together?
I get that more animations will obviously make it look better, but what I more mean is like... what is the lower limit of animations where this falls apart and doesn't provide a benefit?
@@riaayo5321 an experiment to test this should be fairly easy. Take the sample project, go into the sparse data set and remove every animation from the database that you would not author for your project and see how it looks without those.
Yeah I’d love to see an example with way less animations to see how it handles it
@@PrismaticaDev There are some stuff laying around UA-cam creating Motion Matching data using Motorica AI which is great for creating animations for different velocity and directions. Yet, I couldn't get a decent result with it. Also, keep in mind that it cannot be used commercially.
Maybe use motion matching only for the player character and the rest of the NPC use blend space. Since it's the player character that switches motion a lot and the main focus of the camera.
As impressive as motion matching is, I don't see it being too useful unless you're heavily utilizing mocap (which Epic did). I researched motion matching a bit ago and used Lyra's locomotion animations (about 20) to test it out, the character had obvious stuttering because there was simply not enough data. If using traditional workflows, I think that creating enough animations to have the movement look natural with motion matching is not worth the time sink.
You are right. If you have a mocap studio, you can theoretically create like a 5 minute long animation will all possible movement bits and put it into the database and you should be already there %75 percent. This approach Epic provided us is a very modular type of motion matching, which comes with the exaggerated complexity.
And with mocap you can get very stylized animation (say, character mannerisms) for very cheap, since you don't need to map them out in a controller or anything
Implementing custom animations and states into a setup like this would be like jamming your fingers into active industrial machinery to add extra pieces.
It just feels like another tool epic is creating to make larger teams more likely to move over while also increasing the outside appearance of asset flips which will help the image of unreal engine long term, but I feel like it's just going to turn into another buggy experimental plug-in that never gets updated and is ultimately forgotten about by epic.
Were you running the dense or sparse databases when testing this, the sample supports both. One is a significantly cut down version with less animations in the pose choosers.
It was likely the dense database, as I left everything default. It definitely can be more performant with sparse DB's but I think because of the search/evaluate/select going on, I don't think it will ever be as performant as deterministic animation methods (blendspaces etc)
I think the performance isseus are not from the motion matching technology itself. In one dev-talk the developers talked about how they had to optimize the whole system to be possible to get it into fortnite without to much performance impacts. Also they talked about the challenge how they where able to integrate it into existing characters with defined motion. It was a really prioritised goal and I think they developed a good work around.
Also I think in future there will be a more cooperation with "motorica". So maybe in future you only have to define movement styles and get all the needed animation for motion matching out of a motorica plug-in. I think there is big potential in future also and especially for solo devs.
To be honest, I'm not a fan of the side running 3:06 to left or right ... it looks so unnatural, it only fits in a tennis game. :)
Many games use the 8way run (not sure what's the correct term of the movement that was invented for Crash Bandicoot), that makes the motion matching almost useless.
wonder how this would play out for only playable characters, and not NPCs.
Ofcourse the work load is doubled at that literal thought, but the polish the game would feel would be really nice
I've been working with motion matching since it came out and i use vary few animation in conjunction with orientation & speed warping & foot locking and I get better results than ive ever gotten with any other method and my anim bp's are extremely small in memory.. this "example" is not a good example in my opinion but I understand why they do things like this.. Idk it takes a lot of playing around with it to understand what you NEED, and like i said I've been playing with it for a long time now so I just wanna say, dont look at this example and just write it off.
Yeah some others have echoes the same sentiment - the example project is extremely high-fidelity but also high-complexity which makes it seem like a lot more work than necessary. Would love to see some comparisons with a smaller library, especially when it comes to performance as well. I’ve also been thinking MM could be really great for quadrupeds as well
I feel like you probably wouldn't want motion matching on NPC's and you'd still get all the benefits of the motion matching on the character the player is looking at the most without too much of a performance hit.
Yeah this was one of my thoughts as well. It certainly feels and looks great when you’re in control of the character but further away the small details are less noticeable. You could likely use a much smaller sample library for NPCs so it’s finds the best match quicker, and that way you wouldn’t need to use two completely different animation methods/sets for humanoid characters and stuff. But a blend space will always be cheaper to process because it’s entirely predetermined
@@PrismaticaDev You can have fallbacks to the usual state machines but you're doubling your work. And i didn't try the full version yet , only dabbled with the betas last year but there was a lod type system. You can basically have lightweight simplified sets to switch out which is how Ubi does it. As soon as you add a ton o different sets however if you can't for some reason use additive animations or control rig (which I find works better) to change the posture, then it becomes almost impossible to manage. The amount of work at that point might be just better to make traditional animations.
Since I'm commenting here, I wish you talked about the latency as well. A lot of devs use MM in games incorrectly. I had some discussions on why its wrong to use it in stealth games that require pinpoint precision, unless its cover based like TLoU (even in that they used a hybrid pipeline, when it needs precision its root motion) and I think its important to make it clear that it does have latency, its unusable for some type of games, has limitations and it's always a battle between latency/responsiveness and quality. Most people seem to think MM is the answer to all things, just drop a ton of mocap and you have great animations, that's not the case from a gameplay standpoint, it may look great but play like crap for your type of game. The best example is the old FIFA vs PES discussion, many players loved the responsiveness of PES for competitive play, where FIFA had MM and looked great, but it always played like the characters where chasing your controls, some people were okay with it and loved the animations, some hated it cause it wasn't responsive. 2 types of approaches in the same type of game with very different results gameplay wise.
Motion matching is best for realistic, hi-fidelity art styles and makes authoring animations sooooo much easier for those situations. The performance can be improved substantially with less dense data sets, using tagging systems and potentially down the line using machine learning models to pare down the datasets further, and as you mentioned, shifting the searches onto a thread or even the GPU in the case of the ML approach. The bigger issues with motion matching in indie studios is the relative lack of control over the chosen animation, which can make a designer's life difficult at times but I think this can be offset through more extensive usage of all the new rigging tools and layered control rigs that dropped with UE5.4.
I wanted to try motion matching but 5.4 runs insanely poorly on my very good rig. Takes 1-3 seconds every time I try to PIE. Also constant hangups on basic things like clicking on blueprints or moving around the graph.
Yeah I’ve been waiting for it to be a bit more stable. Would looooove to try out the new physical character movement and character mover 2.0
Motion matching is a good tool for a very specific niche.
(and obsolete with the animations through AI that are already present although they are not yet refined.)
I still prefer to combine mine with additive and semi-procedural animations.
achieving practically the same results but with 12 animations instead of 500.
And the best thing is that since it is procedural it reacts to any surface, while with motion matching I would need another 500 more.
But, it's free! There really can't be much to complain about.
as someone who really dont care about visual side of game that much ill be using this for sure. Its free realestates . Sure, the animations look generic and they have no personality, but they look great, way way WAY better than anything i would bother making/setting for the game anyway
i watched the UE showcase they had about it, and im looking forward to the future of this, what we see is, from what i understood, BETA of what the system is supposed to be since they didnt had much time
Yeah - I'll definitely be keeping an eye on it as well so see how it goes. I think once there's an easy way to generate the transition anims from a set of base locomotion (some people have been mentioning machine learning etc) then it might even be easier
Thanks! This was helpful. I didn't have the time to dig into this project but wanted to know what you revealed here. I had my suspicions so I just shelved the testing. I knew it was immature tech that would need time to be made more optimal, but this answered most of the rest of my decisions on when/where to use it. For me, at least for now, this is at least a year away from being of use to my purposes.
It's nice flash, but as you said most solo devs won't find it useful outside of very specific game types.
Yeah I'm not a fan of motion matching, using blendspaces is easier and you can still get really good results. Also I exported the walk and run animations into another project and using the basic Foot IK makes the legs do weird shit while walking up slopes I tried to edit the offsets and it did not really help. My quick fix was to turn off foot IK while moving but in the end I will probably just use different animations. If anyone has an idea on how to fix please let me know.
i wonder where the perf drop is coming from, if its from skel mesh nanite is coming for that soon too. if its from char bp ppl should limit the number of motion matched chars in their games for now
He used same amount of skeletal meshes with a normal blend spaced bp which gave almost double the performance.
heh wow! my thoughts almost exactly! shout out from the gold coast. liked and subscribed brother
If we could use the paths of all these animations, and combine it with something like motorica, we might be about to get a ton of variations out of this.
Hi, agreed on the 500 animations remark, am having the same exact thought.
The AnimBP values aren't ThreadSafe, possibly one reason why your FPS hit below 30? Also, someone did a comparison between 50 ALS and 50 GASP (Game Animation Sample Project) characters and concluded that GASP, in terms of performance wise, is better than ALS. So I'm guessing the second reason is PC specs? On my end, I have RTX 3800ti and only in GASP I keep getting the "streaming pool size" error. Eitherway, GASP isn't complete (as decribed in the Read Me found on the map), so yeah. ✌
Hey hey! I think the comparison between ALS and the MM example is a bit flawed, since ALS itself runs a lot of extra BP code on the character compared to the MM example character and is usually regarded as quite unoptimized when used at scale.
The reason I did my quick test the way I did is that both Characters were the exact same, so they had the same BP and SK mesh overhead and so only the AnimBP was changed. Also keep in mind I was streaming to UA-cam and Twitch and also recording at 2k resolution during the tests haha but that shouldn't have made much difference as it was the same in both scenarios.
@@PrismaticaDev Ah ok. Yeah, I completely forgotten about the streaming part. 😅
With sprinting don't you just speed up the animating and its been tested, animbps chug more motion matching is very performant unless you have a custom way to calculate animations
Awesome tut/discussion Charlie....my question to you is....can you motion match quadrupeds using your own animations?Basically custom animations using the motion matching framework or would you just have to use the traditional blend spaces workflow?
I wish you would make more vids. Anyways I'm on the fence with regard to motion matching. I wish there wasn't all that "complex" data to learn, sift through, and / or understand related to channels, velocities, trajectories, and so on.
On a semi related note, am I the only one that can't stand the emphasis AAA game companies place on SUPPOSEDLY realistic / immersive animations? I think the constant start stop and pivot animations in games actually look ridiculous a lot of the time. When I replay older games without the weighty "immersive" acceleration based movement, I find the movement and controls so much more enjoyable.
Great point - I think the trouble with some AAA games is that the realism can get in the way of actual movement. GTA/Red Dead are perfect examples of movement becoming clunky for the sake of looking good. I think Motion Matching is actually one of the best combinations of feeling great and looking great simultaneously, since it uses Capsule motion like regular movement does. So I definitely prefer it over root-motion movement with those annoying turn-in-place animations that you get locked in to
waiting for unreal 5.5 so we can finally have that sweet sweet nanite on skeletal meshes
In Half-Life Alyx all enemies like the Combine use Motion Matching, But in that game your only really fighting a max of 5 at most
So i could totally see it being reasonable if your game has smaller arena fights with 5-10 NPCs max but defo not for hordes of people
They can do it on GPU with compute shaders and it will be much performed i think
7:15 Hey PrismaticaDev, I noticed some other video's showing that Motion Matching was more efficient than the traditional animation state graph. I wonder, what the difference between your test and his was. I wonder how the number of animations within the motion matching and within the traditional animation state graph influence the results. If u were to add the same amount of animations to the traditional animation state graph would the results be different?
I believe in other tests I've seen, they were using ALS V4 as the basis of a "normal animation graph" which I think is a bit misleading. ALS V4 is, in the words of its creator, an overly complex system meant as a "here's what's possible" sort of system. It also includes a boat-load of Blueprint logic related to movement on the character-code side of things as well as in the AnimBP which isn't completely necessary. I've also seen other people using different SK meshes which also skews comparisons due to skinning cost scaling with vert/bone count.
My test was a "best case scenario" which uses the exact same Character BP between both examples, so the only difference is the AnimBP. In a "best case scenario" you'd just be using a very basic 8-way blendspace which is just reading the Direction and Speed variables. Obviously it doesn't look great in most cases without some additives and there is foot sliding, but it shows that there IS a noticeable cost to Motion Matching itself.
TLDR: My test was between Motion Matching and Blendspaces, not between Gameplay Animation Sample Project and ALS V4.
@@PrismaticaDev Good point, I had not noticed they were using a market place asset: ALSv4
I'm using motion matchint since Unreal 5.1, the diference is that this one is the complete version of what i was using
The real problem is the performance, they should make something about the Game thread, an easy plugin to solve all the problems of game thread, unfortunately i have to use at max 15 A.i(NPC) on scenario or the fps will drop below 60 fps
They've been using this in fortnite for at least a few months now (maybe 2023?). I'm not sure the performance hit hypothesis is valid.
Yeah I wonder if it’s because they use a smaller sample library or they have it thread-safe. Someone told me in Fortnite it IS more expensive than before but not as much as this sample project
Pretty sure much of it is simply the Blueprint overhead....For our internal projects, all event graph logic (even functions) have to get nativised for anything to ship. Nobody likes it but that's just how BP is. Obviously we can't do that here, as that would prevent BP users from dissecting the system...
...but in the future things should get better.
@@LongmireLocomotion Did you get threadsafe anims working on FN with motion matching?
I’m curious when you tested this were the cameras on the Motion Matching NPCs turned off? I see they all have cameras and if your rendering the game from 51 perspectives that’s defo whats chugging everything down
I assume you turned them off because otherwise the game would probably crash lol
@@magma5267 in both cases the cameras and all player-centric components were disabled for the NPC’s :)
I have been (and still am) blown away by motionmatcning ever since experiencing it in the last of us 2. I reckon if you’re making something that style (no large crowds, etc etc) you could make a great looking game with a great story… with terrible AI voice acting lol. But seriously, I love this stuff and I can’t wait for it to continue fleshing out and becoming more user friendly
100%, it seems great for a few incredibly animated characters and could definitely be used alongside other systems (mobs could just use simple animations but hero characters use MM)
I would have rather seen a more comprehensive blendspace, where instead of now needing 500+ animations to make a comprehensive motion blueprint, instead we could use the same 8 or 16 or 32 animations, but the blend space does more comprehensive 'tweening, to programmatically create the seamless motion that looks like we're seeing here.
Personally I'd rather create a _set_ of characters with _unique_ motion, rather than one character with really blended motion (if I were putting that much effort into creating animations). It looks like the predictive algorithm is very good, but I feel (based on your analysis) that the animation could have been done in a better/more efficient way, that would suit more [smaller] studios. Thanks for taking a dive into this one, I've been wanting more information since it came out (but haven't had a chance to dig into it myself), and I can now see it's only partially what I thought it was.
I agree completely - I think there’s definitely potential for a good balance to be found within this system, I’d love to see a simplified version of it
@@PrismaticaDev I’m having lots of thoughts on this; I’ll be playing around with it at some point. I think it could make a nice base for a parkour system (or similar), though there are some missing elements. I think blended with some programmatic ik+fk an interesting system might be developed. I’ll let you know if I come up with anything useful.
i am switching back to state machines... I am done with this motion matching headache
I haven't watched the video yet, this is really just me attempting to organize my thoughts before taking your input into consideration. I have a feeling my thoughts may change after the video.
As a solo dev working on a third person game with melee combat, I'm thinking I'll switch to motion matching for player combat and maybe copy the demo for movement, but stick to the classic system for NPCs. The new system seems like a ton of work to set up, but I think my game's combat in particular would benefit a lot from the way pose search databases work. There are a lot of variables that affect the way an attack or block should play out, so filtering through an animation database with enums seems like a great way to handle that.
I was thinking the same thing but then how will the quality of the motion look side by side. Your character swinging that bastard sword so smoothly while your NPC's stutter there way to attack you ? Probably not very noticeable but you get my point.
I use ALSv4 and I'm happy😂
Based and ALS-pilled haha
@@PrismaticaDev 🤣
Yeah it looks great, but I have the feeling that it's supposed to be the most complex (and best) result you can get with motion matching.
I've seen videos about it before this sample project, as they released the motion matching functionality with 5.4 a few months ago, and it was much much less complex to work with it.
It was literally just taking some animations (like the Lyra example animations) and throwing them into a database. It looked decent, but you still do get some foot sliding, which is why I suppose they added stuff like the animation curves for the speed, foot speed, position etc ... I'm really curious how the performance of the basic motion matching setup is.
Yeah it would be nice to see the simplest, bare-bones example of how it can be used. I think the example project looks great but maybe comes off as too daunting to recreate/build from
I know that animation naming convention! it's nice to see Caleb (ALS creator) continuing ALS through epic, 👏🏻
But can it walk down stairs or a slope or stand on a sphere without breaking its ankles.
Nope the neck will break as well
Commenting for the algorithm. I love your tutorials, you helped me learn tons about physical animation! Also thank you for this vid, I am still using 5.3 and do not want to update to 5.4 so I haven't been able to check motion matching out lol. I was curious if there were any animations I may want to "borrow" from it, but it doesn't seem like it is actually 500 unique different animations, like interact animations etc.
Motion Matching was used in The Last of US
Wow, I didn't know that. Makes sense though, I found movement in that game exceedingly fluid.
in Part 2 and then the remake called "Part 1"
i hope they add it to Fortnite 😅
For people like me, I don't recommend neither the animations or the system itself for FPS games. I am no expert by any means but let's be honest, those animations weren't made for FPS and you just better off with a blendspace both in performance and simplicity matters, as in FPS games the hands movement is more important than legs or body, so in my opinion, if you really want to create something with lit you can use it but if you want to ship your game, just use blendspaces.
Charlie didn't mention this but i wanted to mention in case anyone needs this
I’m sticking with learning ALS at the moment. MM is also too incomplete. Maybe in another year.
You mentioned something in the start I found curious. You think Nanite is expensive? How come, good man?
I'm asking as a scene builder, and I use Nanite often and I see performance increase usually. There are exceptions of course, and I was just wondering what your experience was :)
True and Real Charlie... some of these new UE5 systems... while cool and all, look a little too complex to implement for a small team or a solo dev.
Just from a visual standpoint, there's something about the movement that I don't like. Definitely sticking to Advanced Locomotion System
How much space is it going to take?
Always awesome when my favourite Unreal Chad user posts !!
new vid on 5.5 changes? found this video super interesting
You mean general changes? Or animation-specific. Definitely doing a deep-dive in to the Mutable Character system :)
@@PrismaticaDev Looking foward to see your analysis on the Mutable Character System. Does it save on drawcalls(by merging the skeleton or something like this) or it's just a side grade for something you could develop with a little elbow grease?
@@Vondora yeah it can solve a bunch of issues and allow for more creativity/less rigid customization, which is great. There's already SK merging functionality since 5.0 but this adds on a bunch more stuff as well
That being said, you could technically do it with some elbow grease and Geometry Script/C++ knowledge, but you'd arrive at the same conclusions/implementations as the plugin. So it seems like a good time-saver :)
It's a great system for singleplayer games. But the issue i have with this is that you need to use root motion for motion matching and thats just a nightmare to work with in multiplayer projects.
State machines will not work properly with it so you would have to handle it all with montages which seems insane to me. (Atleast that's what everyone said so far)
This might work for short fire and forget montages but for the consistently triggered movement stuff it's hell and also fills up the network bandwidth because you have to replicate it all.
I don't think this is entirely correct. The animations need to have root motion so the matching system can extract trajectory data, but the movement is still capsule driven. So what you're replicating is not root motion driven locomotion. The root motion is only in the anims for data. I hope that makes sense.
@@fray989 hmm you have a point there.. i have to look into it again.
@@fray989 This is correct it uses the Root Motion data for the MM calculations but not for the actual movement itself so doesn't have any of the issues with Multiplayer... though the current sample doesn't replicate the Trajectory (there is a now free plugin to do this) which means OOTB it doesn't look good in MP.
@@shannenmrI keep saying this. You don’t need to replicate the trajectory only the acceleration. For traversal you would benefit from doing all of your traces in a safe movement state using flags in the CMC. Lyra has an example of the replicated acceleration part.
Why do I have the feeling, in this second hundreds of LLMs are feed witht hese 500 animations, so companies will just generate them instead of actually letting their last animator making them?
Yep I know at least 1 company doing it at motorica, they have some pretty impressive beta right now. And it's pretty easy to mix together a ton of different styles and animation sets. Give it another 6-12 months and there will be a ton of stuff out there. 500 will be nothing to generate in various styles.
Can you elaborate why you have mixed feelings about Nanite? Like a full blown video? From my tiny amount of experience [and a lot of reading] it seems like just almost always the best choice [apart from translucent stuff].
That's a great question! There are a couple of reasons, one being backwards compatibility and over-reliance on the tech, but the other reason is that it currently doesn't do -everything- (such as translucency, drawing to RVTs and using Vertex Paint) which would mean I'd be using both systems at the same time, and both systems would be running their overhead. Nanite seems to have a higher initial cost but scales much better compared to traditional geometry, so just using a little bit of Nanite is kinda a bit of a chugger
Really loved your thoughts on this. Feels like the only real sober take on this system tbh.
Watchu know bout 6D blend spaces???
oh you decided to show up
thanks
Thanks you so much for this video, you saved me hours of investigation testing this, motion matching is completely useless for VR as it is now, that performance cost is unacceptable and I could only see this being used for the NPCs and stuff which is precisely not a great scenario for this system.
It's cool, but no indie developer will use this. They added it for big studios.
I think some indie developers will use it, even some will use all the 500 free animations. Big studios will use the system (I'm sure they already do), but they will not use the 500 free animations because they looks too generic.
Damagemask tutorial when?
thank you for commenting on this daddy
Can't wait for twitch streamer slop games that use this 🙃
Blendspaceded base Based anim bp
well ... this is basically the ALCS5 ... its from the same guy (hes working with epic) ... XD
Something I don't necessarily like about this is that smaller developers are "forced" to use this, which will cause a lot of games to feel the same. Obviously developers aren't actually forced to use this, don't get me wrong - but now, devs looking to create their own locomotion solution will be at a time disadvantage. Sometimes it's nice not to have an existing solution for something so important such as player animation, because that's how you get games with varying identities
The sample pack is pretty awesome, heavy on performance but still awesome. An impressivce showcase.
But what really stands out fo rme is the amount of the free anims they gave.
I've gone through them and damn, what a beautiful set of anims. From turn in place, to start and stop, to pivots and jump lands and starts.
This pack is even better than kubolds movement pack and it's free.
I exported the anims and I'm using them now in 4.27 with AGRPRO and 100%, they replace kubold for me. Can't wait for them to add the weapon anims and hopefully they keep the quality.
As for the performance of the sample pack, its ue5, what did you expect hahaha. Thats why I still use ue4. I want to make games for everyone to play, not just those that can afford to run it, but that being said, the tools being used are pretty new and experimental, so I expect major improvements in future updates. Performance in ue5 has improved a lot with updates. 5.1 runs at 30-40 fps without any changes on my pc. 5.4 runs at 60-70 so they definitely working on improving performance.
As an indie you need to pick your battles. Motion matching looks like a losing one.
That performance test is not really a fair shake. I’m sure you didn’t use more than 10 animations in the blend space setup. If you were to disable majority of the anim in the database those numbers would be pretty much identical. You basically just compared 2 people walking the same distance but one of them was wearing weighted clothes. Of course the guy without extra weight will get to the end faster
activate windows lol
As usual with unreal another "great looking and easy to works with thing watch this tips tutorial and you learn to use it no time" will turn out that will not work outside suggested use much. If you want to make something different, because that how creativity works, you will struggle.
Firstly, anim blueprint performance analysis is totally made up. You can't just look at the FPS and say "well this thing is slower then this thing, so this is bad". And then you're comparing one of the hardest anim blueprints and literally two node blueprint. Of course it is going to run faster, what did you expect.
Secondly, you're not animation bound, you're skeletal mesh bound and movement bound in this case, because their update are MUCH SLOWER IN general, then animation update. Please learn unreal insights (little recording button on the right-bottom) so you can actually understand where performance issue is.
The Character class is the exact same in both scenarios, using the same SK mesh, only the AnimBP has been changed, so there isn't any difference in the movement code/time and the SK mesh skinning time, the only difference is the time to evaluate the pose. We looked at the profiling tools on stream but a tonne of small text doesn't make for a great video, so just the end result was shown in the video.
Blendspaces (pre-determined anims for a given value) is always going to be faster than MM (searching for an anim in a library based on the trajectory and also the current pose for blending)
activate window
"These animations are only useful for the thing they're meant to be used for" seems like an odd criticism.
oh no no, i love all your videos but this one should be removed HAHAH
Why??? Hahah
@@PrismaticaDev overall misinformation here and there.
You don't have to use as much animations as shown in this sample to get stunning results.
And all of these animations can also be used in blendspaces if one wish.
I don't think I've provided any misinformation - the video is titled "my thoughts" and I've never once claimed to be an expert in Unreal Engine, as I've only done Game Dev for 3 years.
I wouldn't call it "stunning" results with less animations, from what I've seen it just seems to be on par with Blendspaces but with all the additional setup and data.
Some of them can be used in Blendspaces, which is great, and the vaulting animations can make for great montages, but the vast majority are very niche (all the transition anims) which is fine, since it's a MM example project, but I think people had the idea that it would be more of a general locomotion library
I don't see ue5 being a good tool for indie devs at all. There's just too much kafaffling in it.
It always depends on their projects, not every indie dev thinks the same. Some like 2d, others 3d, some 16bit, other extreme detailed 2d graphics.
If Unreal is not a good engine for indie developers, which engine would you suggest me if I plan to make games that got graphics similar like Stellar Blade or Wuthering Waves ?
@@paluxyl.8682 I might have been wrong. I mean, after several years of being intimidated by learning UE blueprinting ( outside of shaders ), I found a good explanation of most important blueprints, as well as looked in to c++ structure, and I came to realisation, that yes, I know what to do with it and I will be developing something in UE. But, it's going to be very specific type of game.
For 2d games, I recommend either construct3 or raylib.
Also, I was very agitated yesterday by something development related, and flip-flopped today towards Yes let''s do it in UE.
I think it be really cool to see this used in a game like Skate
BRING BACK HALL OF MEAT 🍖 🩸 🦴