This may be a dumb question because I haven't done any animations in Godot yet, but are you sure the timeline doesn't go maybe one frame too far, thus introducing the stutter ?
Seamless mesh looping animation stops at the last frame before looping
- Edited
Pixophir That's the most important question 
And it's the 1st thing I thought, then to make sure, I tried all engines, the animation plays perfectly in all engines and in Blender - so that's why I think it's an issue with Godot.
EDIT: I even recently tested in Flax Engine as well and it loops perfectly there too.
So, yeah, I checked that. In Blender the animation was 60 frames. Exporting at 60 FPS should give 1 second of animation. However, the render setting in the options was set to 24 FPS, causing a strange export (it was like 2 and a half odd seconds in Godot). This was the first thing I checked. In the Godot import settings, it was set to 60 FPS, which should have brought it in correctly, but I guess there is a double conversion happening. However, even after I fixed it in Blender (to be 60 FPS) it was still 1.017 seconds in Godot (one extra half frame). I manually changed it to 1.0 second, but that did not fix it. I even tried putting wild values for the timeline, like 0.8 seconds or 1.5 seconds. In either case, there was a slight pause (looked like 1 or 2 frames) and then an interpolation, to the first frame. The one thing I did not try was deleting the last frame in Blender, and allowing Godot to do it's interpolation. I imagine this might result in acceptable behavior, but the fact that the animation works in Blender, Unity, and Unreal, leads me to think there is a bug.
- Edited
cybereality
Thanks for further testing it! I did the same, and I even re-instantiated the anim in Godot and tried tweaking the frames and rotation there. No success.
but the fact that the animation works in Blender, Unity, and Unreal, leads me to think there is a bug.
Yes, precisely If it were looping wrongly anywhere else, I'd be the one to blame, but since it works everywhere else, I see this as a Godot problem.
Biggest proof that it just works everywhere else. The wheel animation for my game trailer (starts at 0:11) is EXACTLY the same unaltered in UE, it's the same mesh and NLA action. For the sample project that I gave above I just removed the other parts of the mesh.
Is that your game? I really do love Brazilian street food. I bet you'll make a over 1 Brazilian dollars!!!
Self-interview:
If it works in UE and you even made the trailer in UE, why insist to make it work in Godot? Why not just keep using UE?
Because I made the trailer in UE and I'm trying to make the game in Godot - but Godot is pushing me away with issues like this that are common sense in other engines.
- Edited
cybereality Yes, it is my game! The trailer exploded in Brazil, I went all over the news in all of BR's tech and gaming websites and even had many interviews about it!
I came up with a workaround by myself. Posted here:
https://github.com/godotengine/godot/issues/65513#issuecomment-1240907596
@cybereality thanks for all your attention
Logically that makes sense, but I wonder if it should still be considered a bug since it differs from other 3D packages. Also, in Blender, you can set a particular timetime region to export, so you don't need to change the animation.
It looks like the old looping clip problem with Adobe After Effect CS6. Users have a similar work around of adding extra frame after the last frame. It was never fix so I believe if they were to fix it would break other stuffs so they just left it. 
cybereality but I wonder if it should still be considered a bug
Functionally? No. UX? Maybe. Personally I prefer starting from 0 but consistency with other tools has it's value.
- Edited
cybereality in Blender, you can set a particular timetime region to export, so you don't need to change the animation.
Yes, that's what I did instead of changing the animations.
Megalomaniak UX? Maybe. Personally I prefer starting from 0 but consistency with other tools has it's value.
I think consistency with other tools is more important than trying to force Godot's weird ways. After all, no project is made in a single tool, plus there's millions of existing assets that can be re-used in the pipeline.
Maybe a good compromise would be a text box on the import settings that says start frame (default on 0) but you could put in 1 if you are using assets from other engines.
- Edited
alfredbaudisch Godot's weird way
I wouldn't really say it's a "godot's weird way", there are other animation tools that typically start from frame 0 but most of these are more sim oriented. Frame 0 is then used to initialize the sim and frame 1 is meant to be the first relevant 'animation frame'.
But this is also to say that there really should be a way to have that frame 0 but set the animation track to start at and loop to frame 1. IMO.
Megalomaniak But this is also to say that there really should be a way to have that frame 0 but set the animation track to start at and loop to frame 1. IMO.
Yeah, this would be the better idea. If you can set a start and end frame for the animation on the timeline.
- Edited
Megalomaniak you're right and I agree with providing both options and your suggestion would be very welcoming
But when I say "Godot's weird way", it's the same that used to be with Blender - it had its own way of doing everything completely different from every other package, basically nothing up to 2.79 Blender was consistent with any other software out there - it was weird in that sense (and I used it from 2.4 to 2.79 massively).
Then with Blender 2.8 they decided to add compatibility modes and get consistent with the "industry" and now Blender is getting (or already is) "industry standard" too (i.e. wide adoption, more funding, etc).
Imagine being able to rely on the Unity's Asset Store and UE's Marketplace and seamless dragging and dropping the assets into Godot? But 90% of the time everything breaks due to these incompatible decisions (and I'm talking about just re-using FBX files and the like).
- Edited
oh yeah, in UX terms godot's definitely got some of that, I was just saying that the animation timeline starting from 0 isn't as much it. But also blenders UX wasn't as non standard as some made it out to be, it is just a very old application and it's UI design originates from amiga days where there were actually quite a lot of applications in similar vein.
As for the UI/UX redesign that was actually started with 2.5 and was left unfinished, even the 2.8 work wasn't finished, there's still things that were discussed back then that never got tackled so I foresee yet another further rework coming in the future.
On that note, godot 4.0 brings some rework of it's own in regards for an example multi window support and I'm sure each following major release will be doing some rework as well. 3.0 had some of that too, for an example the inspector got reworked. It's just a matter of time.
As for FBX...that's an AutoDesk problem.
Megalomaniak As for FBX...that's an AutoDesk problem.
FBX is not a problem for Autodesk. It was intentional designed to make them money, and it's working.
cybereality No I mean, Autodesk is the problem. Their EULA on the FBX framework/middleware prohibits it's use in open source software projects.
Megalomaniak Good points!
Megalomaniak On that note, godot 4.0 brings some rework of it's own in regards for an example multi window support and I'm sure each following major release will be doing some rework as well.
Definitely! So much 3D improvements with 4.0 both on UI and 3D Pipeline. One of the UX improvements was even contributed by me 
Yesterday I posted a summary of 3D pipeline improvements from Godot 4 from a prototype I made in 2 days: