Setting position.x clobbers .y and .z

[donmccurdy]

• A-Frame Version: v0.7.0
• Reproducible Code Snippet or URL:

Open https://aframe.io/aframe/examples/boilerplate/hello-world/, and select the sphere element in Dev Tools. Then:

$0.setAttribute('position', {y: 2});
$0.flushToDOM();

Sphere's position changes from 0 1.25 -5 to 0 2 0. As of A-Frame 0.5.0 this behaved correctly, leaving .x and .z alone; I didn't check 0.6.0.

Issue filed here from comments from @MichaelHazani and others in Slack.

[michaelybecker]

Thanks @donmccurdy! I wonder if this is a threejs issue - gonna try to break it in three when I get home.

[ngokevin]

Perhaps turn them into multi prop components?

[ngokevin]

That would also allow for .setAttribute('position', 'x', 10) to not have to instantiate a JS object.

[donmccurdy]

Hm I'm not opposed to that change, but do you know why it's broken with single-prop components now when it worked in 0.5.0?

I'm assuming this applies to position and rotation components, and user-defined components too (like my velocity and quaternion).

[ngokevin]

Not sure. Before it probably worked by coincidence, but component code got refactored or changed, and now does not work. But making it multi-prop would make things easier, before if I wanted to update position, I'd have to getAttribute + change + clone (because getAttribute returns the data object) + setAttribute with another object.

[dmarcos]

Position, rotation, scale are really faux multiproperty components. They are single property components of the vec3 type (that has multiple attributes). We could make it a multiple property with a custom parser that would still allow for the form: el.setAttribute('position', '0 0 0');

[machenmusik]

(I thought those wanted to be THREE.Vector3 for performance efficiency)

[ngokevin]

You could still pass in a Vector3 if we move it to multi-prop.

[ngokevin]

A better way to update position now is el.object3D.position.y = 2. It will still be reflected in the A-Frame level.

[donmccurdy]

@ngokevin that's #3245 right? If we're fairly confident it will be a longterm feature, would be great to have some documentation of what to expect... is object3D.position the underlying storage for the position component? So object3D.position.x = 20 should not force any copying? It looks like getAttribute('position') returns a THREE.Vector3 now? But rotation is still an Object, since we need to convert from radians to degrees?

This feels like the right direction i think, just trying to make the API changes explicit.. seems possible this could break some components.

[ngokevin]

Docs will be added during the pre-release preparation, yeah. The explicit change is modifications to underlying object3D position/rotation/scale will be reflected at the A-Frame level through .getAttribute without any explicit syncing phase. It's a top highlight for me for 0.8.0 for ergonomics and likely performance.

[ngokevin]

object3D.position.y +=2; - shipped and docced