calling clipAction.play() makes animated objects disappear. Blender exporter producing incorrect values.

[bakajin]

Description of the problem

Calling clipAction.play() makes animated objects vanish. Due to a bug in the JSON exporter for blender (io_three from dev r87). When checking "Scene" on the exporter writes (incorrect) matrix transformation data (only scaling it seems) into the geometry object. The animation track containing scaling correctly reflects scaling values of 1. Making the objects scale up radically so they seem to just vanish when you play the animation.

Hard to see because matrix values are not the same as transformation values. And the objects are actually not scaled.

I solved it by copy pasting the calculated scaling values leading from the matrix into the json scaling tracks. Not pretty, but because the scaling is actually not animated a workable solution.

Moreover the exporter also produces incorrect results generating the animations object. It just writes all of the tracks into the "animations" object. But threejs correctly expects a clip filled with tracks. So I restructered the animations object to animations > animation > tracks. If you compare the animations object in following files:

https://rawgit.com/bakajin/2e3d2f6a722103ed4aefd76f6250ec08/raw/cf9c783cd47617ed2f63e1b52d69ca06b344bae0/oomp-scene_balloons-oomp-6.9.4.json

https://rawgit.com/bakajin/2e3d2f6a722103ed4aefd76f6250ec08/raw/e15acf23d37060e2aa94748d86d4e7d8e833cb91/oomp-scene_balloons-oomp-6.9.4.json

And last but not least the durations for morphtargetInfluences tracks are incorrect. The data looks pretty random to me. Suddenly it looks like it writes durations in seconds, where the transformation tracks are in frames. But calculating the frame with these seconds also does not lead to the correct duration. I got very lucky that I added the frame number to the morphtarget name. Manually adding this to the JSON also showed that the tracks are not always correct. track which is not a start or end morphtarget should always start with a weight 0 then lead to 1 and back to 0. And I see tracks with only two keys (which are not start or end tracks).

My important exporter settings:

Keyframe Animation true
Morph true
Blendshape true (why are there two? These are simply different names for the same thing imho)
Scene true
Hierarchy true
Buffergeometry false
Apply modifiers false

Related to #10804 #8511 #11803 & #6050

I kept most of the old bug report below:

I created a jsfiddle here, maybe a little obsolete by now.

https://jsfiddle.net/oompol/qw5hgLtq/

please note I commented out calling action.play(). So you see the load and init work. See the function listed below

function playScene(scene) {
  for (parentName in srtMixers) {
    var clpName = parentName + "_" + scene;
    var clp = THREE.AnimationClip.findByName(animLib, clpName);
    var action = srtMixers[parentName].clipAction(clp);
    action.clampWhenFinished = true;
    console.log("playScene:", clpName, clp, parentName, srtMixers);
    //comment in the action.play() to see the problem
    action.play();


  }
}

Three.js version

• [ x ] Dev
• [ x ] r87

Browser

• All of them

OS

• All of them

[Mugen87]

So I am lost, and think this looks more and more like a bug.

I don't think that. It looks like the setup of your property binding (animation) is wrong. TBH, I also don't understand the logic of your buildAnimationLib() function. This kind of pre-processing should not be necessary if you properly export animations from a content creation tool like Blender.

Try to isolate the issue into a small test case and post a question at stackoverflow. Your fiddle is just too complex. If you can verify it's a bug, we can reopen the issue.

[Mugen87]

These examples might help to get a better understanding of the animation system:

https://threejs.org/examples/#webgl_loader_json_blender
https://threejs.org/examples/#misc_animation_keys

Also have a look at the docs: https://threejs.org/docs/#manual/introduction/Animation-system

[bakajin]

Hi @Mugen87 thanks for your reply. Actually the JSON Loader parses the SRT animation to the top level. Say object.animations and the (correct) morph tracks to object.child.geometry.animations. And then on top of all that to reduce filesize I am cloning things. So I think I kinda have to reparse the animations in a library.

If the bindings would be wrong though, howcome it would make the clones disappear?

Thanks for the two suggestions I will have a look at those. The intro to the Animation system is what I used to refactor this code. And actually in a previous release, the SRT animation worked fine. Makes me wonder if it has something to do with dropping the scene hierarchy (scene:object:action.track for ex.). Actually, no I think not.

PS. I realise the fiddle is way too complex. Not sure how I can simplify though. I need to set up the scene, load a json makes clones and link up the animations.

[bakajin]

Ok @Mugen87 total bug & what a mission to figure out!

Related to bugs: #10804 #8511 #11803 & #6050 So the blender export made for a weird incorrect matrix transform. Making the initial scaling values come out super tiny. Then the scale track had values of one (correctly in my view), so as soon as animation started the model just blew up out of view (and didnt actually vanish). I see from the other bug reports that it is probably related to checking or unchecking "scene", which needs to be checked in my case but then also writes the wrong matrix transformation in your object.

Moreover it is really hard to see because the the Object contains no initial scaling values but a matrix transform that leads to this erroneous scaling value.

Shame that the initial response is then to quickly dismiss, ie you are doing it wrong (and didn't you work on many of these referenced bugs?).

Oh and on top of that the animation object is also written all wrong by the exporter. It just lobs all tracks in one "animations" object. That should be tracks collected in a clip. As you can see in my edited json in my fiddle. I edited the animations object animations > 0 > tracks, 1 > tracks, 2 tracks etc. Which is the exporter and not me exporting it incorrectly.

But but, at least I can get things to work now. If you like I can edit this bug report to properly reflect what is going on.

[mrdoob]

But but, at least I can get things to work now. If you like I can edit this bug report to properly reflect what is going on.

Yes please 👍

[bakajin]

@mrdoob There you go. Not sure if the rewrite is that coherent tho. It was a little difficult because of the initial bug report led to a different problem (the Blender Exporter). And as you can tell more problems with the exporter.

But at least making headway again, which is nice

[wilson0x4d]

this issue appears closed, but not fixed. is that correct? original post was updated to describe a real bug?

[mrdoob]

@wilson0x4d do you mind elaborating your issue?