The run animation of fox seems lost two frames

[XiaofengdiZhu]

As title

[scottpetrovic]

@XiaofengdiZhu - Does the source animation Blender file look correct? At least with my eyes the animation looks fine. I am not the best animator, so maybe the animation is just not as good as it could be.

You can see the Blender animations here
https://github.com/Mesh2Motion/mesh2motion-assets/tree/main/rigs/fox

[XiaofengdiZhu]

@XiaofengdiZhu - Does the source animation Blender file look correct? At least with my eyes the animation looks fine. I am not the best animator, so maybe the animation is just not as good as it could be.

You can see the Blender animations here https://github.com/Mesh2Motion/mesh2motion-assets/tree/main/rigs/fox

Not correct. The sneak and walk animation looks correct, because the end frame is very similar to the start frame. For run animation, the end frame is much more different from the start frame.

[scottpetrovic]

Alright. I can make sure the start and end frame are the same for that run animation and re-export it out. The start and end are a bit different.

[XiaofengdiZhu]

Alright. I can make sure the start and end frame are the same for that run animation and re-export it out. The start and end are a bit different.

I think I’ve found the true bug: in the .blend file, the main viewport is set to 24 FPS, which makes fast movements look choppy. However, the preview in the bottom-right corner seems to match the monitor's refresh rate and looks very smooth.

The true bug is in the Mesh2Motion web animation previewer. It doesn’t seem to interpolate between the last frame and the first frame, resulting in a jarring stutter.

My suggestion: for looping animations, add interpolation between the start and end frames; for one-shot animations (like Death), no interpolation is needed.

[scottpetrovic]

I will have to see how possible that is with what three.js provides. All the animations are all set to loop, so I would have thought the three.js library would take care of that. The first and last keyframes weren't identical for the run animation, so that could also cause some "popping" when the loop starts back at the front. I am pretty deep working on a new feature, so I will try to get a new build pushed out whenever I have time with the updated animation.