Can you define poses/state-machines, porgramatically, inside the animation-BP (or elsewhere at all)?

Development Character & Animation
21

Updated, with whatever gains I can get:

image
image1100×578 122 KB

"Yes, but you want to make sure to actually make the final result before optimizing "

Understood. I have a mission-plan and PoC’s on what I am working towards. Functionally, I’ve been able to get what I want in a few ways; I like pecking at it. :smiley: For this thread it was a question of performance before I started implementing anything/everything writ-large. Since I’ll have a few redundancies in terms of pose-duplication’s on the enums (walk/run/sprint/etc) some poses/blends based on what a given kit has, I can at least make them faster and claw back performance across most/all of my anim bp.

Input appreciated, everyone; thanks.

1 Like
22

You can expose to variable o bind the animations

image
image1989×461 90.3 KB

So you can change the weapon idle with a simple direct event from the weapon or the character, y put the animation in the weapon.

BTW
and you don´t neet duplicate code like you do in the post, check “cached poses”

23

You aren’t making much sense on this one…

For one, the image you shared is literally just any animation you drop in the abp without any changes.

And secondly, cached poses come with their own cost.
While I would suggest splitting standing and crouched into different caches if it serves a specific purpose, the less amount of overall cached poses you have the better off character performance is.

Particularly when you start to have a significant amount of characters that use the ABP. Think a Mount n Blade situation with an army of 400plus.

24

I only point out to him where he can do what he wants

Repeating the same piece of code is ridiculous, plus with cached posed you keep the frame in the same place.

image
image1112×599 139 KB

I suggest that he look at how they did it in paragon character because you save a lot of transitions

25

Instead, I suggest you and everyone else here break down the Laurent videos because what ended up in the paragon characters you download is absolutely nothing compared.

Personally, I don’t even think that whole code should exist.
I’d have just 1 idle state returning 1 idle, and play a montage on top of it to handle holding a weapon.
If the leg positions have to change - then it just gets a whole new state machine (ideal for spears).

26

“Personally, I don’t even think that whole code should exist.
I’d have just 1 idle state returning 1 idle, and play a montage on top of it to handle holding a weapon.”

Ideally, yes! I don’t know how tho? From the char-bp, I’m not seeing how I can do anything but play a montage or run a query against a montage currently playing, it’s position, etc. I don’t see how I could call/blend a montage from the char-bp with what’s going on in the anim-bp. Do I run my idle-state in the char-bp and eschew the anim-bp alltogether?

The reason I have the multiple checks on crouching was the blend-by-enum requires a default pose but I am also blending by bone to basically take the spine_1 (and up) of the weapon and plop it on top of the locomotion, so one can crouch, run, walk, etc with whatever weapon. In practice it works well enough, but I couldn’t seem to sample the crouch-check twice; a pose-output can seemingly only go to one input. Given there would be overhead for making and checking a cached pose and it was only between two animations I already had loaded & sampled, I assumed (hoped!) Unreal wasn’t so inefficient as to double-up on things… Anyways, look at the whole thing like a giant lerp where you blend a and b by a, back onto itself for a smoother blend. If there is a better/more-performant way, I’m open for input 'cause I can’t seem to see it… (sheepish-grin/shrug)

For context, I’ve noodled around with the animation logic before and had previously cobbled together several iterations of what I am working on here. However, I found in my travels, since I had to consume animations vs creating them, no one set seemed to have a cohesive group of idle, walk, run, sprint, crouch, etc… One would have to aggregate multiple animation-sets to solve the problem of “I need a fleshy critter to walk, crawl, run around a space & open doors, pull levers, etc”. I did make this mostly work but the disparate sources for the animations just made it look too awful for even my compromising-standards…

I simply do not have the skills/time to really animate things; I’m just no good at what I’ve tried either. So! I am working with the Amplify Animation Pack (Amplify Animation Pack in Animations - UE Marketplace). It has all the animations I want via done via a single-source so they are all cohesive and as well all the trace-logic for wall-checks, cover-checks, swim, climb, etc. I’m comfortable coding and have had no problems taking state-machines from the anim-bp and getting it to work as logic in the char-bp, moving code around, etc. Even just for the animations themselves, it’s a good collection.

Here, I need to marry several animation products (mainly weapon-stuff) onto the locomotion portion of this code-set. Assume I can do anything in this regard in making what run where, I would like to know a performant way to run this. Fastpath was a perfect response given I can retool the code-set, that’s more a housekeeping thing. Otherwise, I am not looking for a perfect solution, I get that my case is my case, but obvious dumbass things to NOT do, or correct what I explain I am trying to do is appreciated. :smiley:

Ideally, here is what I need to get working, functionally:

  • the legs, left-arm, right-arm, and spine-torso-head would be things holding distinct motions/animations I would want to blend together (4, maybe 5 sections of the critter). Think Dark Souls as a functional-metric. (eg: arms hold weapons/items, legs crouch, run, etc; and the torso just kinda is, to be blended as required for hits, locomotion and the like).
  • I’ve already got the top/bottom halves working ala the blend by bone in the picture above and the thought was once I got the ‘best/better’ way to implement that working, I could flesh out the rest of the tree; I’ve already cut the guy in half to get what I want, so making more sub-sections is more of the the same… I already have animations ready to go, just before plopping everything in asking on what don’t I want to waste my time against.

Is it worth creating a state machine for each ‘section’ of my guy (left-arm, right-arm, legs, torso, etc) and just blending them? In each, I assume I’d still have to blend by enum based on what part holds what, but I know that logic (or whatever I need) can be made to run ala Fastpath, and the set of things per state-machine is somewhat limited. For now I am going by weapon-type so all greatswords will share the same path in the animation-logic and I will only have several classes of weapons. I have other ways/logic to make the game combo-interesting, etc, etc. This line of inquiry is strictly for locomotion to get the character to move around an reflect what they are holding.

Just to say, I have a lot of good feedback on this, so I could certainly put together a cheat-sheet for other n00bs. Everything is appreciated.

EDIT: As for the video thanks. The structure of the product is very very similar to what you see in the video. As it’s a marketplace thing, I don’t feel too comfortable posting their code into the thread, but sufficed to say, the breakdown of state-machines around idle, motion, turning in place, and other actions is along the lines for what Laurent breaks-down. Multiple state-machines for different locomotion states blended by enum/bool, all on fastpath. Seems I broke it when I migrated logic to the char-bp and went with refs inside the anim-bp (when I thought to try swapping anim-bps)… I fixed that… :stuck_out_tongue:

27

I would day that splitting up the body and having multiple blend by whatever on a non main character is a waste of processing power…

I get it you are trying to have this thing modular and all, but I want you again to consider a scenario where 400+ of these things are on screen at the same time.

Would all of them running the same ABP vs all of them running a specific ABP tailored to what they are carrying - without animation sharing - change performance?

Probably yes. If there’s no logic to evaluate and little to nothing to cache, the dedicated ABP should run faster (You have to test this ofc).

Aside from that, if you got what you need to work on fastpath and you throw 400 in a scene without much of a performance hit (should be around 30fps with no animation sharing - but depends on cpu at that point) you are probably good to go with your setup.

As far as making montages shift with underlying animations, they usually just play completely separate. The play node has settings to blend but it’s not the type of blend you want really.

If you want to get creative you can add animation curves to the underlying animation for the locomotion like its done for IK, and you use those curves to control the mintage play rate or even what section is to be played - this is not on fast path and obviously prone to errors in computing.
However, in some cases it’s great - stop the tip of the Speer at a precise time with the step is an ideal candidate for this - but then again I went and done it with IK…

1 Like
28

Ideally, my critter-count MIGHT get up to 50’s or so? Think DarkSouls, the latest Zelda, and other openworld(ish) RPGs the like. There might be packs of critters, and some that can then be summoned, etc, but critter-counts will be lower than 100 at the very least. Some critters are very…creative in the way I made them and don’t even have an anim-bp, maybe a material, collision and few other things to interact with the player. Something like a Wisp or a flying-skull is fairly simple and w/o anim-bp. I am angling for an area/battle mode but that might have 50-100 at best, and it will be majority the same core anim-bp for each player, plus whatever is native to the map or can be summoned.

So, for the most part, yes, the core anim-bp I am working on will be shared. At least across all player-characters. The duplication-of-animation/effort is really only around a core set of locomotion, and only so it matches the players current equip/weapon; what I call ‘fudge-work’ . Anything outside moving around, so attacks and anything special like a spell/item are called via montage (and work well) per weapon/item.

Many of the humanoid critters will also share this core anim-bp but there will indeed also be others (quadrupeds/fliers) that will have their own unique anim-bp’s.

I early decided I’d need to use external assets so I get I won’t get THE most optimal ‘machine’, but at least I can set my course towards a better heading. All this input is appreciated, thank you. Once I get this all sorted along fastpath, and working with a few weapons I plan to share a video on what hopefully is a dev-log, I’ll be sure to update the thread.

1 Like
29

F_ckin’ A!!!

This solves the problem of blending between distinct anim-bp’s: Guide: How to create a smooth blend between two different animation blueprints (4.24)

No vid but I can say there is no stutter between switching weapons-anim-bps. It’s even robust enough that if you advance through multiple items fast enough (before the next bp starts) it can shift seamlessly through the bp’s (until you stop).

I DO have to stick the unequip/equip animations in the middle, but now w/distinct anim-bps, I can eschew the above overhead and ultimately, this opens up more customization possibilities, as well as weapon-specific bp’s for stances, etc… w00t!

Thanks for the input everyone. I know I didn’t get this answer straight away but w/all the discussion and research resulting-from, I found what I was looking for.

FYI - this is what I was working off before I found the forum post, relevant & has a good vid: Animation Pose Snapshot | Unreal Engine Documentation

EDIT: Running and switching is kinda fugly, but I might have an idea…to be posted.

EDIT2: when using the anim-bp blend, you apparently need to use the method where the pose is stored into a variable. Since the named-pose path is stored internally in the current anim-bp, one cannot save the pose to the NEW anim-bp and hence loses the pose when switching to the new anim-bp…

Only noting this b/c the docs and tooltip itself suggest the named-pose is somewhat more performant… Otherwise this seems to work great.

1 Like
30

My head struggles to know what kind of game needs to switch between animations blueprints :sweat_smile:

31

Think DarkSouls with many many weapons . The situation I found myself in was wanting to make an action RPG and for each weapon, each-weapon-tree, combo-set, I’d need to add more and more logic to parts of the locomotion blueprint: how each weapon is held during idle, walk, run, or any other weapon-specific changes I want. Each weapon might have a different stance, etc and it started to become a bit unwieldy having to cram all that into a single BP.

Rather than have a bunch of blends across multiple weapon-specific animations, for the sake of modularity, I looked into swapping BPs, and it seems Epic has this exact scenario in mind given the available nodes used to make it work.

Overall, more for organization, but this also gives me opportunities to tune my game to a smaller level of granularity. As well, a more dedicated anim BP will be less costly at runtime since it will only have the weapon-specific animations it needs and not all the rest it won’t.

Thoughts?

32

That’s why the running still has issues…

More granularity yes.
Performance doesn’t change.
Again, the animation being used is whatever it is at the time of it being used. Size on disk doesn’t really matter and size in memory does matter a bit, but its not like the whole ABP is always in the ram - as far as the print outs read anyway.
Also, if that were the case the ABP would need to be completely read into memory when swapping, so what we commonly do wouldn’t perform as well as it does on smaller footprint machines like mobiles…

33

You just never made something modular enough.
If you make stuff that can go anywhere like, movement modes you can swap out, then modular ABPs are great.

34

“Also, if that were the case the ABP would need to be completely read into memory when swapping, so what we commonly do wouldn’t perform as well as it does on smaller footprint machines like mobiles…”

THIS is the stuff I didn’t know, so thanks for the clarification. I can’t really assume and I don’t know enough about the engine low-level to know these kinds of things for sure.

As for the running issue, it’s something about the poses I am using. In some cases, idle and a few others, the poses blend beautifully, otherwise, not. It’s that the new state my player is in starts out walking and then has to transition to running, not running/sprinting as they were previously, so it’s something with the pose or something I am not tracking as I should.

If I get it to work, I’ll update the thread, else I have options either way. Good 2 know I wouldn’t be killing myself if I have to cram everything into one BP.

Thanks again. TGIF and enjoy your weekends.

35

I think DomusLudus had the right idea:

For stances, you would flip-flop between two variables that you change whenever you switch weapons. In other words, whenever you want to change a weapon, you set the opposite variable to the new stance, then you switch to it using a blend:
https://streamable.com/zmjljp
https://streamable.com/zmjljp

This way, you can change the animation completely through blueprints, which means you can have as many animations you want without having to manually add them to the animation graph. This also means you know only two animations are loaded at a time since there are only two variables.

This is also not limited to just stances; you can use this to solve your original “switching state machines/animation blueprints” problem. You can make one full state machine and switch the animations when the weapon is switched. This way, you only need one animation blueprint that will work with all weapons. Since the weapons will follow the same flow (e.g. attack1 → attack2 → attack3) you only need to change the animations (i.e. content), not the state machine (i.e. logic).

1 Like
36

image
image1800×769 163 KB

Yes correct, thanks for giving an example, it can also be used to change the blendapces.

You can use a montaje for the weapon change and below do the variable changes

2 Likes
37

If you are going though all that “trouble” use an array and a GET of the int of the right pose.

The problem with it is you get no blend when you switch, so you have to only switch before firing off the animation.

And/or it has its place if you do things right - forward distance detection + swap from run to hit a Boulder animation with the proper timing based on a distance curve.
When you rely on C++ it may be better to use hard switches.
Also true for most movement prediction but its a high level precision work that won’t stand to the changing of animations.

Personally, prefer to build a system that doesn’t rely on “good” animations and curves whenever possible - Simply because it takes days of work to refine the animation set enough otherwise.
And despite obviously liking the process of manually fine tuning everything, it still feels like a chore when you need ~46 animations per walk cycle to be refined and polished…

38

Hey hey.

Good input. I totally keep spacing on ‘expose as pin’; will continue to keep it in mind. All this feedback is much appreciated.

I managed to track down my issue with the new-state resetting. As I suspected it was an issue with my new anim-bp proc’ing a notify that reset my movement-state (back from sprint to walk). Once I carried the old-state forward, problem gone; I can change weapons almost seamlessly in any motion-state I want to… :smiley:

I know I didn’t get the direct answer from any one person, but all the collected input lead me here; kudos and again, thanks.

1 Like
39

Take a look at the UE5 release character. It includes some automated stuff by Laurent it seems - speed warping and animation something rather.

Moving it around, it still needs a lot of work compared to ALS4 or similar custom solutions, but the leg IK is working Ok-ish.
It’s not impressive by any means, but it’s a similar-yet-different approach to everything far as I poked around in.

1 Like