Node animation doesn't register? "registerInstanceAnimation did not find targetname"?

I get this intermittent error when using the API to load and show (moderately) complex animated models:
registerInstanceAnimation did not find targetName (Stand_Parent_9.rotate) in the scene graph
In this example, I’ve got a node, Stand_Parent, that has some rotation keyframes in the FBX file. And, sure enough, when the API plays the animation, Stand_Parent doesn’t rotate. There are many other animated nodes in this model, but only this one throws an error. The others behave correctly.

I know the animation exists, and it animates correctly looking at it in the model viewer.
The node is a matrixTransform node. It’s just a simple rotate, nothing too fancy. The entire model is maybe 100 nodes. There is no other node with a conflicting name.

I’ve had this same error in other model files: some parts just don’t register their animation. Somehow the problem got fixed in other models but I don’t know how. Anyone know what is going on here?

1 Like

Hello,

Cannot reproduce, do you have a way to provide a model where it’s happening or a codepen/jsfiddle that reproduce the case ?

1 Like

let me look into how I might share that to support… the code is multiple module files

:face_with_raised_eyebrow: now it is behaving correctly… I don’t think I changed anything significant. Threat of support call sufficient to induce cooperation. :sweat_smile:
Previous experiences with this error have been likewise intermittent. As soon as I see it again, I’ll freeze the code in amber and send to support.

1 Like

Update: potential Heisenbug. Loaded a page, got the did not find target error, and those items indeed did not animate. Excited to find an instance I could send to support, I reloaded the page to verify. The model loaded correctly that time, no error message, animation working correctly. :face_with_raised_eyebrow:

Perhaps it cached something that made the second attempt succeed? Tried loading in incognito mode, no error. Tried Firefox, Microsoft Edge. No error. :expressionless:

I can’t believe I’m the only person to ever have this problem, but GoogL turns up nothing. Very annoyed that it’s intermittent and so far unreproducible. :unamused:

Found an instance that reproduces in Chrome. Sent files to support. Appreciate any help.

1 Like

Update:
Still unsolved, but I have figured out what code is causing the issue: api.getNodeMap()

In our code, as part of initializing the Sketchfab window, we get the animations, the materials, and the nodes, and store them for later use. When I disable api.getNodeMap(), the error does not occur. When I re-enable it, it does (about 50%+ of the time).

The error also shows up in the console log maybe 100ms after logging that the nodes have been got, and the Sketchfab window is active. But I don’t take that as determinative.

Saga update, for the sake of the one person who encounters this error in the future:
At the suggestion of Support, I tried adding delays to the code. Putting “await sleep(1000)” (1-second delay) before or after the getNodeMap call prevented the error in 20 out of 20 page loads, huzzah. Changing that to “await sleep(100)” (0.1 second) did not prevent the error.

Still trying to get to the bottom of this, and nobody loves an extra second of load time, but that does seem like progress.

fwiw, I’ve found in several cases that doing things in the viewerready event needs a little pause, because viewerready doesn’t mean it’s actually ready. For instance, creating new annotations: https://codepen.io/klaasnienhuis/pen/MWbQbrq or disabling mouse interaction: https://codepen.io/klaasnienhuis/pen/poNEyVQ

1 Like

Good to know, thanks! Yeah, it looks like something like that might be happening here.

fwiw, the most recent update of the sketchfab viewer fixes the issues I found with the viewerready event. The little pause I mentioned isn’t necessary anymore.

1 Like

Thanks for the note. Is there a more recent version than 1.9.0? I still have my issue in 1.9.0, alas.

Apparently this update is a sketchfab release, not a viewer API release. So it’s independent of the viewer api version.