• Godot Help3D
  • Seamless mesh looping animation stops at the last frame before looping

alfredbaudisch

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.

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!

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.

      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.

        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.

          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).

          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:

              This looks great. I mostly work in 3D, but I tested the new 2D tilemap editor and it's really good. Amazing workflow for blocking out levels so quick. I might have to make a 2D game just to see how quick it can be done.

                cybereality Yeah I'm also 100% 3D. I'm not interested in 2D, but I'll keep an eye on Twitter to see what you create then. I already saw your new MM + Godot 4 experiment! Really cool.

                  7 days later
                  a month later

                  I fixed this bug in Godot today, details: https://github.com/godotengine/godot/issues/65513#issuecomment-1287828202

                  I mean, it's not a fix to the import but itself, but it removes the duplicated frames which cause the seamless animation to not be seamless anymore when imported into Godot.

                  It's unlikely it's going to be merged into Godot, so you have to get the code from my branch and build Godot yourself.