glTF-Blender-IO
glTF-Blender-IO copied to clipboard
KhronosGroup
Animation seems to always use frame_start = 0
A BabylonJS user was confronted to an issue, not specific of BabylonJS, and found that the issue came from difference between Blender default starting frame (1) and what seems to be the default gltf export starting frame (0).
So I've made a few checks and it seems custom starting frame is indeed not take into account.
Here a simple Blender animation starting from 5 to 25, the animation loop without break:
Here the glb export (into BabylonJS Sandbox) where we can see a break into the animation, which seems to be ghost frames from 0 to 5:
It's maybe a gltf standard limitation for animations to start at frame = 0, if so I think it deserves to be mentionned in the Blender Manual.
There is actually an option which I would have expected to deal with that in the export settings. The tab animations contains the option "Limit to playback range", which is true by default. Searching through the code, it seems like the functionality for this option is not implemented yet.
This also means that the end of animations is not properly cut off, if the dope sheet channels are longer than the animation range.
ok! (I've forgot to mention I've play with some exporter options too), thanks for the clarify. So wait&see :)
The tab animations contains the option "Limit to playback range", which is true by default. Searching through the code, it seems like the functionality for this option is not implemented yet.
If we have an un-implemented option still in the mix at this point, that's a bug. We should yank the option out, at least until someone has time to write the supporting code.
I also ran into this issue when trying to export low FPS looping scene. There was a noticeable freeze in the exported animation because of this issue.
Here is a very minimal .blend file to better see and test the issue: 2_point_loop_anim_blend.zip
It is a 3 frame scene played back at 1 fps that loops a cube back and forth with linear interpolation.
When exported with the old Blender 2.79 gltf exporter that has the "keyframes start at 0" option enabled by default, the exported file loops flawlessly without any gaps. GlTF-Blender-IO export however has the animation frozen for first 1 second of the loop.
This happens because first exported sampler keyframe is placed at timestamp matching frame 1 (exported keyframe times are [1,2,3] when they should be [0,1,2]). It produces a frozen duration equal of 1 frame because glTF spec states that sampler times are to be considered relative to time=0 and clamped if first keyframe is later than that.
Marking this as a bug rather than an enhancement - and confirmed the example above does work if the keyframes are shifted back to 0–2. Since animations start at 1 by default in Blender, we should fix this to ensure exports loop cleanly.
Looking into the code the range is set by bake_range_start and bake_range_end.
Has this bug been resolved yet?? Running into this issue and the option is still available in 2.9
Would be nice to get this looked at: NLA tracks with a defined Frame Start and End aren't clipped at all, as far as I can tell. That's a big problem for even something as simple as a walk cycle, where offsetting frames (for naturalness' sake) leads to negative keyframes and keyframes after the animation's end and a baked range for the animation to loop right.
I have not checked the code in a while, i actually never use this addon. Would an easy fix be to use current_frame vs start_frame. Im not 100% sure though that start_frame is always 0 or if start_frame is always the start IN of the timeline.
On the other hand. perhaps the option "limit to Playback Range" fix this issue. Though normally this means the end of the animation.
Could be also updated by adding start and end frame like other exporters have
I think the issue with this goes deeper and is more challenging. It seems the addon export complete actions and NLA strips. Therefor it doesnt check the main timeline and thus i wonder if this current_frame and use playback range even have any use. The Limit playback Range doesnt do anything, im also seeing the "Current Frame" does do anything
With this file attached the current frame and frame range was 5-15, it still exports the complete animation. This proved it looks at the action or NLA and simply seems to export that in full range. I did see some fix in a different issue #1517 Which is about Custom Range, this is perhaps something new in Blender 3.1 i saw a this in dev section, https://developer.blender.org/rB5d59b38605d61b
here' you can check the export i made, very clean play and doesnt spike the CPU as much as other do https://sandbox.babylonjs.com/ The cubes should not go from top to bottom, these other cubes represent total frames 0-40
IMHO this could be fixed (Inelegantly? Or misses out on cases with Action Strips offset in time?) by simply subtracting the "Frame Start" value from every keyframe's frame number when calculating the keyframe's glTF time.
Perhaps by changing this line:
self.seconds = frame / bpy.context.scene.render.fps
to simply:
self.seconds = (frame - bpy.context.scene.frame_start) / bpy.context.scene.render.fps
It works for me in simple tests, anyhow.
Hello, This is now fixed in current main branch, after animation refactor 64e3532f48ebdf878a1c9b81ade6d1a19c8ff890
There is now an option ("Set all glTF animation starting at 0") that shift animations to start at 0 during export. This way, animations can be looped smoothly
