3D animations values offset on top of skeleton pose


We are running some tests to determine if we can make our next project in 3D on Defold. So far it’s going really well!

We are having a small issue with the animations:
To be able to have customisable characters made out of different meshes (hat, hands, body, etc.), which share the same skeleton and animations, we have those things in separate collada files.

It seems that, if there’s a difference between the pose in the Skeleton collada, and the pose on the first frame of the animation collada, the values set on the animation are added on top to the Skeleton’s initial pose values causing an offset in the final values.
For example, if the skeleton has a bone at X=0, and on the animation that bone starts at X=-1, then moves to X=1, what we’re getting in Defold is an animation where the bone starts at X=0 (skeleton position) and moves to X=2 (position from animation).

I would expect that the Skeleton would assume the pose set on frame 1 of the animation.
In this case, in the example above the bone would be moved to X=-1 on the first frame.

In order to fix this, we’re making the first frame of each animation exactly identical to the skeleton’s pose, and then offsetting the cursor to skip it.

It works, but I wonder if there’s something we’re missing or a more elegant way of dealing with this.

Any help is appreciated!
Thanks :slight_smile:

Here is our test project:
3D Customisation.zip (60.4 KB)

1 Like


Hi @cormano and thank you for your question. I do not know the answer myself, but let’s see if @sven has time to provide you with an answer!

1 Like


Hi, it’s been a while since I looked into the code but I remember some issue regarding this… Sadly I can’t find the correct jira/github-issue. But, could you try one thing for me?

Add at least one keyframe for all bones. This makes them all appear in the “posed” position.

(It’s my own comment I found to a similar issue in an old Jira tracker… :thinking:)



Thanks for your reply and sorry for the delay.
I tested having a keyframe for all attributes on all bones at the first and last frames of the animation and unfortunately the problem persists.