Gizmo doesn't follow what it is attached to

[kungfooman]

Testable in: https://playcanvas.vercel.app/#/gizmos/transform-translate

If you move the box afterwards, it suddenly isn't attached any longer:

gizmo.attach([box]);
box.translate(1, 2, 3);

Result:

The only way around this seems to be to call:

gizmo._updatePosition()

But this is an internal function and even if it were public, it would still be strange to "reinforce" an attachment - as attaching something implies a strong link between things.

[kpal81xd]

This behavior is intended. The gizmo transform is calculated and then applied to each node attached to the gizmo updating its own position last. The nodes attached to the gizmo were not intended to be programmatically moved

[kungfooman]

The nodes attached to the gizmo were not intended to be programmatically moved

But the translation gizmo should move along with the entity when it's translated, as the gizmo is attached to the entity and is designed to move in tandem with it. Why is the method even called attach if there is no attachment implemented? Test any other gizmo implementation (Three, Babylon) and they properly attach the gizmo both ways.

[kpal81xd]

Okay I will change the name then because to allow for the gizmo to move along with the entity requires an update loop to check for all the attached node positions which seems messy

[mvaligursky]

maybe consider add a boolean to control this, default to false?
even though it feels strange to have both ways sync to me? if both the gizmo's position and also the entity's position change in a frame, who wins?

[MAG-AdrianMeredith]

We had this issue, but its solved as part of the application which is the correct place to do imo as it requires application specific knowledge

[kungfooman]

if both the gizmo's position and also the entity's position change in a frame, who wins?

If it were possible I would give priority to the gizmo to ensure that user intend is reflected. For example a cube is moved up and down via Math.sin for testing a shadow implementation, but you could still just grab the gizmo to test the shadow for other positions.

But as @MAG-AdrianMeredith points out, it's application specific and it would be easy enough to simply disable the cube-up-and-down-script via gizmo events so the gizmo is in charge during user-gizmo-interaction-time.

I wouldn't try to mess too much with the script execution order here. What's created first is handled first (aka whatever appended methods via app.on('update', ...)).

I never needed gizmos so far for controlling animated entities (at best a static target entity for dynamic IK). I only have them on static entities that I want to move around through a gizmo, but every once in a while I also need to reposition those entities programmatically after something "important" happens (e.g. a promise finished and a new/better position is available).