Let’s say I have a scene with five doors. These doors all have the same Animation Blueprint attached to them. When a character approach one of the doors I want that door to animate (open) while the other doors remain closed. Is this possible somehow?
That’s how animation blueprints work. They each target the actor they’re attached to; you get one copy per actor.
If this is not working for you, then you’re doing something else wrong, perhaps in how you detect the triggering?
1 Like
You shouldn’t be using animations and skeletal meshes for doors in the first place.
Either way, the blueprint is Instanced, so you could theoretically do it, even if it’s bad practice.
Yes the problem is the triggering. When one is triggered they are all triggered. The doors themselves are Blueprints. What I need is a reference in the Animation Blueprint to the instance of the door Blueprint onto which it is attached. Is this possible?
I was able to solve it to some satisfaction. In my Event Graph in my Animation Blueprint I used a “Get Owning Actor” to get a reference to that specific door from the Animation Blueprint.
Why does the animation blueprint need to do anything like this at all?
Typically, all the logic will go into the door blueprint. It will have a trigger volume, an interactable interface, or something like that.
When it decides it needs to be open, it plays the “open” animation forwards. When it decides it needs to be closed, it plays the “close” animation (or play the “open” animation backwards.)
There’s very little logic needed in the animation blueprint at all – in fact, you may not even need a blueprint for this animation. Of course, if you have an involved sci-fi collapsing-door animation, a blueprint can help, but it sounds like you’re trying to put the logic in the wrong place, and are running into trouble because of it here.
And if your door is not an intricately collapsing skinned mesh, but rather just a boring rigid door, you don’t need a skinned mesh, nor an animation blueprint, at all.
I’d argue that even an insanely complex door collapsing should just be done in material shader…
You are technically correct, which is the best kind of correct!
My counter-argument is that most modelers/animators do not have a very well tuned art pipe to go from authoring to collapsing-door-animation with the appropriate controls and tweakables along the way, if the choice is “material shader.” If you do, then good for you!