Has anyone gotten any problems before when exporting a skeletal mesh with animation using a damped track, into Unreal Engine? (Happens in other engines too, such as Godot)
My animation is getting stopped short for some reason and I’m not sure why so the looping doesn’t look great.
I’ve baked my animation so I’ve gotten the correct keyframes, following the solution in this thread, but no luck. rigging - Help! problem encounter when exporting animation (with constraint) - Blender Stack Exchange
2 Likes
Not very helpful, I think, but are you using a special kind of bone structure?
2 Likes
Not that I’m aware of.
This is the guide I followed: https://youtu.be/j4aS7UUd8cA?si=QPq-yP6ikrPjyZ60
So I created an armature (DEF), duplicated it (CTRL), re moved parent of CTRL and moved it to the CTRL bone group.
Scaled CTRL bones down with individual origins, parented the CTRL bones to the previous DEF bone in the chain.
Moved into pose mode, added damped track to DEF bones, one at a time, from furthest to previous bone. (Video explains this better)
Changed the shape of the CTRL bones to a circle and rotated then on X axis.
Copy rotation from CTRL to DEF bone, reordered the modifier so Damped Track was in top.
From now, I believe I was able to move every CTRL bone to rotate the DEF bone.
Then I parented armature with automatic weights and it worked.
I could cut out the CTRL bones and just work with the DEF bones, but I’m not an expert in blender so I’m still working things out 
3 Likes
Blender and other packages do have their own standards of doing things.
While a bone a very simple concept, which can be easily exported.
It can be, that something as a damped track is very specific (or implemented in the Blender way) in Blender.
And not such as a default functional feature, to be understand else where.
You should explore how something like a damped track is done in Unreal Engine, GoDot, because there you can program bones the way you want to animate.
3 Likes
Are you sure it’s nothing to do with the animation export settings as a whole vs. just the inclusion of a damped track? I see 120 frames in the source animation, while the UE dopesheet goes to ~140. Have you had problems importing simpler animations, or has everything gone smoothly until this specific one?
While there may be more involved, I think the primary issue comes from start- and end-point misalignment. In Blender, the tail starts pointing up and continues for 2 cycles. In UE, it starts pointing down and continues for not quite 3 cycles before jumping back to the start (pointing down again). From what I can tell It’s less that UE is making the animation too short or cutting it off, and more that the bounds simply aren’t correct. How that would’ve happened though, I don’t know.
I think baking is a good idea, but maybe the bake didn’t turn out as you expected it to. In Blender, are we watching the baked result or the source animation? Seems like this is baked already since every channel has a key on every frame, but I could be wrong.
3 Likes
Sorry for the late reply.
It is possible, I did notice that another version of the fox where I didn’t use Damped Track, but instead was manually creating keyframes using movement in pose mode. Which worked correctly.
Whereas using Damped Track, it seemed to be cutting the final 20 or so frames out, so I also put it down to something similar, but I have done my research but I haven’t found anyone mention this problem much.
Yeah I did also think maybe I should create the models in Blender then animate them in the specific game engines, though if I want to create an asset pack for Godot, Unity and Unreal, that’s going to triple my work load, which again, I’m surprised I haven’t found this being a problem online.
I will continue to look into what the problem is and if I find a solution, I’ll let you know. 
2 Likes
Sorry for the late reply.
Yes I also just noticed this in the video, and at some point I was playing around with the frame length in Unreal, because it looked like it was cutting out the final 20 frames or so, thus tried to increase the frame length hoping it would fix it (but it didn’t).
I’m fairly new to this, so I haven’t done much exporting from Blender and importing into Unreal, Unity or Godot, however I can confirm that when I export another iteration of my fox animation that does not use Damped Track, it is purely individually created key frames in Pose Mode, this works fine and captures all movement correctly.
I also thought something similar, though I didn’t notice the start position of the tail, what I did notice is when I baked the animation initially, the first frame the tail was pointing directly outwards (not up, nor down), in the default (T?) pose it was in initially, so what I did was duplicate the animation three times, (overlapping the copied start frame and the final original frame each time), baked it, then removed the first 120 and the last 120 frames, leaving the middle 120 frames which should have the smooth movement from start to finish which loops nicely in Blender, but unfortunately not when exported.
I 100% suspect this is an issue due to inexperience on my part, being I can’t find many similar problems online regarding Damped Tracks animation that have been exported.
You’re watching the baked result
I can provide the Blender file if anyone is interested in finding out the issue for experience like me, but this isn’t necessary, we all have different lives and time scales we work to
3 Likes
No worries, because
Anyway, that’s quite interesting. I’d say you’re definitely correct to point at the damped track as part of the problem in that case, and if you had to harvest the middle cycle of your baked result just to get something usable, then it certainly sounds like a bad bake (don’t worry, baking is finicky and you’re not the only one who’s had issues). As much as I applaud the creativity (seriously, that’s a neat idea), it shouldn’t be necessary to trim it like that.
Godot is my area of expertise, and I wouldn’t mind having a go at importing your fox into that, especially because Godot has more direct support for Blender than the other two major engines (so we’re somewhat less likely to see weird stuff). Maybe I’ll see something that we’re collectively overlooking, and it’s an opportunity for me to learn something too =)
4 Likes
Thank you for offering, that’s really kind, I’m really looking forward to solving this and learning from this experience.
I have shared two files, Fox_Damped_Track (This is before baking) and Fox_Damped_Track_Baked (After baking, and specifically the animation is baked using the DEF bones (bones) not the CTRL bones (Circles), which originally I thought the issue was), but no success.
Over the next couple of days, I will attempt to remove the CTRL bones, as I don’t believe they’re entirely necessary, and see if only using the DEF bones works, then will update my progress here.
Fox_Damped_Track: Fox_Damped_Track.blend - Google Drive
Fox_Damped_Track_Baked: Fox_Damped_Track_Baked.blend - Google Drive
Thank you again, I hope you find this as interesting as I do
Edit: It’s worth mentioning that I’m using Blender 4.1, so it could mean this was a bug that has gotten fixed in a minor update, I’ll check this route too.
2 Likes
You have some kind of cyclic problem. I can tell this because if I go to frame 0 and keep pressing left arrow the tail slowly moves to the rest position. This may be with the damp track itself I haven’t played with it enough to figure it out, but I have a way you can bake it despite the problem. Start on frame 1. Press spacebar and let it run thru the loop at least twice so that the looping will be smooth. Then when it gets close to the final frame(120) hit spacebar. Use right arrow key to move it to frame 121. Then press alt+a to deselect all bones. Select only the Tail Def bones. Click Pose->Animation->Bake Action. The options I checked was Only selected, Visual Keying, Clear Constraints, and Clean Curves.
2 Likes
Thanks for looking at this Dwayne.
So I’ve tried your solution and couldn’t get it quite right, though… it is exportable and it replicates exactly what I’m seeing in Blender to Unreal using this method!
I found the first time doing this, the tail movement was 90% replicated, but when the tail swishes from left to right, the tip of the tail wasn’t moving in a clean way, and didn’t replicate the previous animation.
So I thought I’d try it on the CTRL bones and this worked out mostly OK, though there is a small movement from the end of the animation to the start, which makes it skip.
I have recorded both methods (though I recorded how I implemented the DEF bone process to show you I was doing everything you said (or perhaps in case I missed something!)).
Weirdly… when I did the DEF bones process again, the animation was different to the first time, it’s a lot more exaggerated in the up and down motion, vs what it was before, which makes me think that it’s to do when potentially the placement of the ‘3D Cursor’ or Playhead, in the animation timeline, though both times it was at frame 121.
I’m convinced this is a bug, I haven’t tried this in newer Blender versions, but I will to test if this has changed.
Please do let me know if I missed anything during the video of the DEF bones.
Once again, thank you so much for your effort towards this, I really appreciate everyone’s help.
CTRL Bones result: Fox_Baked_Small_Glitch_CTRL_Bones.mp4 - Google Drive
DEF Bones process: Fox_Baked_Unpredictable_DEF_Bones.mp4 - Google Drive
2 Likes
I can take a look when I get home. (5:30pm CST(GMT-6)) If you want I can also jump on game dev’s discord around that time. I believe the voice channel is called voice hangout or blender buddies I don’t remember which one it’s called. Note: I’m still pretty new to using discord even though I originally signed up on it like 2 years ago.
1 Like
To get rid of the glitching I had to do things a little different. The main thing was using ESC instead of hitting spacebar to stop the animation. Here are the steps I did.
I started with your file fresh. One thing I can’t figure out is what does spine.012 do? I deleted the keyframes for it. I also delete the scale keyframe for spine.028. I then ctrl+left arrow to go to frame 1. Pressed spacebar and let it run thru 2 times then I hit ESC. Then I used right arrow to get to frame 121.(You can hold arrow key down to go thru quicker.) Then I Pressed alt+a to deselect everything. I turned the eyes off of all bone collections except for Tail DEF. Then Pressed A to select all bones and then baked the action.
Then I changed the action name to Baked in the action editor. Oh I also changed Idle to Damp track just so I could tell which was which when I imported into unreal. I used the Default FBX settings.
I’ve include the files I created. Damp_Track is before the bake and Damp_Track_Bake is after the bake. No number at end are your files. 1 is where I cleaned it up and added the Rig UI while I was trying to figure out how to get rid of the glitch which was worse in my attempts. 2. Is the one described above.
The files are here: https://drive.google.com/drive/folders/1dYP4OzNbxDjJH-l3CdobMJRI1yW9A3-f?usp=sharing
Edit I am using blender 4.2 and UE 5.5
2 Likes
Hey Dwayne,
Thank you so much! You’ve done most of the work and I’d say we’re nearly there.
I’m noticing that the animation isn’t exactly replicated though, the tail movement from left to right seems quite rigid compared to the Damped Track version, also for some reason the baked version it seems to turn the tail more to the right (very odd!). Is this a limitation of Damped Track or Baking? Am I using this in the wrong way? Or is Damped Track a fairly new feature? (May do some research on this )
I’ve recorded both versions side by side so you can see, I must admit, it does look subtle, and I’m sorry if it seems like I’m nit picking, to clarify, I’m so happy with the progress you have made and I really appreciate it. I haven’t been able to spend much time on this myself since my son and I are a little ill currently, so my focus is else where, but to know that I’m still receiving help is really warming, and if I can ever help you, I will definitely do so.
Here’s the video of the side by side animation: SideBySideFoxAnimations.mp4 - Google Drive
Thank you again
Edit: The baked animation on the right is using your “Fox_Damped_Track_Baked2” file and the one on the left is a fresh version of my “Fox_Damped_Track” that I initially shared. And I’ve also tried all of your files in Blender 4.1 and 4.2.3, which is the same result.
2 Likes
I think it’s a baking thing vs the damp track. Baking sets exact numbers with a limited amount of precision. Where the Damp Track has more subtle influence not limited by the precision. As for the pulling to the right, I don’t know. It could be the removal of the Spine.012 keyframe and/or the removal of the scale keyframe on the armature itself.
Edit I think it’s coming from the clean curves option. I uploaded a Baked3 blend and fbx. I did it quickly so I didn’t spent a lot of time comparing. Also I hope y’all get well soon. Nope that’s not it. Just took a closer look and the animations is the same as 2.
3 Likes
I have a progress update, I noticed if I check the “Manual Frame Range” in Blender to 140. Then export to FBX (after baking like we have been).
Once in Unreal, import the FBX, change the “Animation Length” to “Set Range” and change the “Max” to 126, then import. It cuts down the frames 140 to 126, which loops perfectly.
But I’m now trying to see the logic on why I need to do this.
So the below questions I will be looking into:
Why, do I need to change the “Manual Frame Range” to 140, when my animation is 120. (Perhaps 130 would work too, or anything over 126)
Why do I need to set a custom Range of frames in Unreal when importing, and why does the end frame need to be 126, when the animation is 120 frames (that’s 5% on top of the total animation, I’m not sure if this is a consistent 5% when using Damped Track with the frames, or if it’s coinsidence that it’s 5%)
Will let you know when I have answers
2 Likes
I’ve now created a Blender issue, as I still believe this is an Damped Track bug: #130426 - Damped Track Exporting - blender - Blender Projects
5 Likes
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.