I’m trying to create a first person shooter with visible hands and a firearm.
Both the hands and the firearm have multiple bones that are animated and I want the hands to have different models depending on what armor the player is wearing.
Currently, I have two split Skeletal meshes and skeletons - one for the gun and one for the hands.
I can import the seperate baked animations for both just fine and testing a few animations works without a hitch, however I’d like to know if there was a better solution to this problem.
If I was to set up animation montages, I would have to identically recreate them for both the gun and firearm skeleton - so I could create desynching and errors every time I change one of them and forget to modify the other one
Is there a way to create animations that make use of multiple skeletal meshes?
Simply attaching the weapon to the hand like in the ShooterExample won’t work because I want to have multiple bones on the firearm aswell.
As seen I have both “pretty much ready”, however I am having trouble seeing how I could best implement firing off what animations are meant to be played without having to put a lot of possibly unneeded effort into making sure the animations don’t desynch.
Hi BMAliens:
I encountered some similar problems like you, but my weapon is sword with very complex animations so I think I’ll have to use multiple skeletons, so currently how do you deal with this problem, do you still use 2 skeletons in your animations?
Well there had been another thread about the same problem : 1st Person Hands, what workflow when exporting? - Asset Creation - Epic Developer Community Forums .
This solution creates a skeleton including both the arms and the gun for each weapon and they’ll stay in synch since they belong to the same skeleton. Solves the problem when the aim is a standard first person view ; however I’d love to have additonal things such as dual wielding which will turn into a problem with that workflow.
I decided to create a controlling blueprint the gun class calls upon for animations whenever one needs to be played, the blueprint in turn plays the required animation on every skeletal mesh. This keeps everything in synch.
The animation blueprints on the skeletal meshes are straightforward and they basically only blend the animations they’re supposed to be playing, doing anything more with them would case desynchs.
I decided that effects such as the viewmodel bobbing when moving and rotating when strafing are solved better in code anyway, dedicated animations for that are an unnecessary effort.
Hi BMAliens:
Thank you for your reply, you said “bobbing when moving and rotating when strafing are solved better in code anyway”, so you think for a complex animation action (like extracting a sword from sheath), you control and sync them in C++ ?
Currently I simply created a single skeleton for character and all weapons, then the number of joints is more than 75 which is not mobile compatiable. So that’s why I think I need to break them into mutiple skeletons trees. I saw the play rate of animations between anim blueprints can be synced by variables, but really don’t know how to do with the animation montages, can anim sections’ play rate also got synced by some variables?..
what I meant by the “code animations” are simple transformations - in this case simply moving and rotating all viewmodels in respect to the cameras location.
I’ll use this to simulate the bobbing which occurs when your character is walking.
I won’t be really playing around with the speed at which animations are being played, so I haven’t got the experience with that yet.
I have a similar scenario where the player can perform grab attacks with enemies, and the player and enemy both must play concurrent animations at the same time.
My solution was to cast; I use the Event Graph of the AnimBP on the player to call an event which plays the montage on the enemy’s AnimBP whenever it’s about to play its own montage. This eliminates a lot of headaches; the only way one montage can be played is via the same execution path which plays the other. No worry about trying to synchronize the playback in each individual BP.
