Can't get api.transform to move my node

Development and API
#1

I am trying to do some simple transform animation with the viewer api, and getting nothing.
Here’s a jsfiddle link https://jsfiddle.net/adamgravois/utL1g6e9/17

The “pose A” and “pose B” buttons should be moving the room on the left -SOMEWHERE- but they don’t. Here’s what I’ve tried:

-I know I’m referencing the correct NodeID – the show/hide buttons work fine.
-The node in question is a MatrixTransform node, as required by API (is not geometry, not a material)
-I’m using the syntax as described in the API docs (interestingly, feeding garbage into the “easing” parameter doesn’t throw an error).
-It logs successful completion, with numbers that are close to what I expect
-I know the numbers are OK because I’ve used them to set camera position through the API previously.
(Not using the shaderbytes api, as I discovered it too late in development)

But I get no movement at all. What am I doing wrong? Appreciate any help.

#2

Hi,

sorry if documentation is unclear, as it happens your model is animated, and anything under animated nodes cannot be “animation overriden” by viewer api setMatrix.

Nodes needs to be totally outside any animated node hierarchy

#3

Thanks for the response. Would it be more precise to say there can’t be animation anywhere in the node hierarchy, if you want to use api.setMatrix/transform/rotate on any part of it? The nodes in question are not animated, nor are nodes above them, but nodes underneath them are. The entire hierarchy cannot be modified by setMatrix. Do I have that right?

That’s a bummer of a limitation :frowning_face: and definitely worth a mention in the docs.

Follow-up question: are values passed through api.translate interpreted in local (i.e. parent) coordinates, or world coordinates?

#4

OK, my experiments indicate that having any animated objects in a model file prevents that entire model from being affected by api.setMatrix/transform/rotation. And, when there isn’t animation, translation (and I presume matrix) values are interpreted relative to parent coordinate system, as you would expect.

#5

yes, you have it right on all point: you would need a different hierarchy for “nodes to be animated by script”, and they are local and it definitely needs a documentation update.