Incorrect conversion from fbx to json


I’m importing a very simple animation of a box into playcanvas using fbx. When the animation is converted to json, it loses keyframe data that was originally there.

You can see in this test project. If you download the fbx file, there is animation where the ball moves up on the Y-axis on the 2nd frame. But in the json file, that motion is not there at all.

Has anyone seen anything similar, or could suggest a fix.

The fbx was exported from Maya, and I’ve tried multiple versions of the fbx plugin. Is there a specific fbx plugin version that is supported?

Hi @adam.katz and welcome!

Indeed this seems like an issue with the animation importer. I’ve tried importing your FBX to Blender and exporting a new FBX from there, but I got the same issue. Animation worked in Blender but in Playcanvas there isn’t any transforming happening on the Y-axis.

Downloading the Playcanvas animation .json file verifies that fact, all Y-axis frame positions are 0.

  "animation": {
    "version": 4,
    "name": "pCube1|pCube1|Take 001|Layer0",
    "duration": 1,
    "nodes": [
        "name": "pCube1",
        "defaults": { "r": [90, -0, 0], "s": [0.01, 0.01, 0.01] },
        "keys": [
          { "t": 0, "p": [0, 0, 0] },
          { "t": 0.1, "p": [2, 0, 1.84] },
          { "t": 0.2, "p": [2, 0, 1.36] },
          { "t": 0.3, "p": [2, 0, 0.88] },
          { "t": 0.4, "p": [2, 0, 0.4] },
          { "t": 0.5, "p": [2, 0, 0] },
          { "t": 0.6, "p": [2, 0, 0] },
          { "t": 0.7, "p": [2, 0, 0] },
          { "t": 0.8, "p": [2, 0, 0] },
          { "t": 0.9, "p": [2, 0, 0] },
          { "t": 1, "p": [2, 0, 0] }

Invoking @will @vaios to take a look.

Great, thanks for the quick reply. I should mention that in the production animation that I first noticed the problem in, it’s not simply the y-animation that’s getting lost.

But instead, it almost looks like Playcanvas is choosing it’s own keyframes, and then doing custom linear reinterpolations between them

1 Like

I ran into something similar with wheel rotations. In short, if there was more than 60 degrees of rotation per frame, the imported animation would show a reversed direction. My solution was to scale my keyframes in the original animation so that everything was slower and to then run the animation at a faster speed in PlayCanvas.

1 Like

Looks like there is some work in progress to use GLB files (glTF) which also includes animation.

Is it possible this wasn’t a bad conversion of quaternions to euler angles?

Thanks, I’ll have to check that out. Do you know if this lets you see the animations in the viewport, or if everything needs to happen within the code?

Hi @adam.katz, right now that is going to work only using code to load the files and the models will be visible on runtime only, not in editor.

But the Playcanvas team has pledged that eventually GLB support will land to the editor as well. Having the engine support it is the first step.

Ok, good to know, thanks. Is there any update about the buggy fbx importing?

Someone from the Playcanvas editor team should comment on that.

Try submitting in the meanwhile an issue on the Playcanvas Editor repo about that:

Thanks for the link, I’ll post the bug there as well.

I have no clue as to the why and the problem I had may be unrelated to yours. But the solution of scaling the timeline in the original animation might work nonetheless.

hmm, that’s true. Strange workaround, but it might help.

The playcanvas converter samples FBX animation data at 0.1 second intervals. Keyframes smaller than this can get missed.

1 Like

Really? That seems like an extraordinarily poor approach given that typical animation rates would be 24, 25 and 30 fps. I may be misapplying Nyquist, but a 0.1 second sampling interval would only be reliable for animations with frame rates up to 5 fps (0.2) second intervals. If I’m understanding this correctly, that means that in a 30 fps animation, you would need to scale keyframe intervals by a factor of six or more to make the animation effectively 5 fps.

But that number seems to be consistent with my experience. So it is probably right.

I found that the threshold when reversed rotation would be seen was when the wheel rotated by more than 60 degrees per frame. That’s 1/6th of a 360 degree rotation - the inverse of the minimum scaling factor that would need to be applied for accuracy. The “reverse” rotation that I saw in my wheel is actually a temporal keyframe aliasing artifact produced by insufficient sampling at conversion.

Yeah, I found that slowing my animation down 6x gave me the correct data I needed when imported into Playcanvas. Unfortunately, that means that every animation clip takes up 6x the data.

Another unfortunate side effect of this, is that you can’t reduce file size by having less keyframes in the animation, since the conversion to json will always create a keyframe every 0.1 seconds.

I suppose you could animate at a compromised slower frame rate such as 10 or 15 fps. Playcanvas will tween between the keyframes. So that might be a reasonable compromise. Going in with eyes wide open as to what is actually happening with the conversion/frame sampling is certainly helpful either way.

Yeah, true. Knowing what’s happening helps, although it makes very detailed, quick motion difficult to get correct.

Sure. But that’s a typical problem with game technology … right?

Well yes, there’s always workarounds that can help. Although I’m working with animation that has specific interactions with the environment. And the lerping that playcanvas is adding is making body parts go through the environment objects.

But the slowed down animation that you suggested above is working, so thanks for that!