To anyone out there with extensive experience with using Animation Blueprints, performance-wise, should they be avoided unless absolutely necessary? Or is the impact so insignificant (at least on a smaller scale of less than 4 actors) that it won’t really matter?
I’m aware ticking events are fine, as long as they’re not abused, and used for complex calculations, however, is an Animation Blueprint, by its very nature, complex?
I’m going to avoid them, as a practice, but I’m realizing I will need them for certain situations involving humanoids and combat.
To be honest it varies depending on the person. Some people like them, some completely avoid them. I use them here and there and never found them to be very complex.
Animation Blueprints are by themselves not that expansive. They also have the ability to be set to run in parallel and they have indicators when you are doing something a little bit more epansive. They show the easy fast calculations with a flash icon to indicate fast path support.
You can also use the new thread-safe functions of the animBP to further parallelize the performance.
Making it more performant. In conjunction with fast path it shouldn’t really be that much of a problem.
Unreal is fine up to about 100 bots, 200 is max. And it is mostly because collision, and dynamic avoidance of each bot vs rest of them. And no animation blueprints are not that heavy compared to collision checks. Just do not do intensive checks on tick in animation blueprint, and all will be fine.
So much information. It’ll take me a while to process it. (Particularly the video, which is a completely new approach that I’ll need to tackle and test later; but it is clearly something I need to learn).
As far as I understand all nodes are still executed one after the other.
The nodes itself are not executed in parallel but instances of the anim instance itself can be executed parallel to other anim instances or processes. This is what improves performance.
For our project we have been using animation blueprints, along with outer uses, and is neither good or bad with out taking into consideration other factors. For one thing you do not have to be a coder, “doing it in C++” to work on necessary assets to keep the project moving forward taking into account as what you originally planned as being the intended result does not work out that way before you get to the end of the overall design.
As an example we started our project with UE 4.0 and over time the technology it’s self has continued to improved that made where we started obsolete. Blueprint us in this case made things easier to quick change the animation frame work that was built using blueprints rather that having to dissemble C++ code to other wise patch in a new desirable feature.
Another example of future proofing is we make use of Genesis, G3 at the time, but switched to Genesis 9 when made available which is designed to be closer in structure and much better as being more compatible to Unreal 5 which if integrated as code would have been difficult, as to the limited number of coders available, which tool less work as to the need to restructure a few blueprints and retarget a few animations.
The way to look at is that blueprints are very good at dealing with frame work development from the top down which you can then rework from the bottom up using code based solutions but by then you will probably come to the same conclusion we have as a team that BP adds little if any performance impact as compared to other resource hits.
