[Smooth2D] Rotation of Sprites

[fairhat]

Question:

Is it possible to smooth the rotation (and just the rotation) of a Sprite with the Smooth Addon? As far as i can see it is only possible to sync the whole Transform.

We could extend the Plugin to be able to selectively update transform properties (position, rotation, scale) and select the Node that is referenced (instead of taking the parent). This would allow to create invisible entities that are changed and bind the visuals (which might have different anchor points).

For example: A Sprite with an Anchor point (Changeable with V Key) outside the sprite boundaries A Node2D (lets call it SpriteRotation) which represents the data that we want to bind Binding rotation of Node2D to the Sprite would result in the sprite being rotated correctly

Right now making the Smooth2D a child of SpriteRotation and the Sprite a child of Smooth2D So: SpriteRotation -> Smooth2D -> Sprite Would make the Sprite rotate different than what one would want to accomplish

Suggestion: Smooth2D Configuration (in the Editor) From Node: Any Node2D (currently the parent) To Node: Any Node2D (currently the child of Smooth2D) Properties: Array<(PropertyName, PropertyType)>

So we could configure it to take any Node2D as a reference and apply the Properties to any Node (given that both have the property and the type is the same on both)

PR possible? I could give it a try

Edit: I can see that you decided against linking the nodes manually. Maybe they could just be initially selected as a trade off? If you don't want this to be part of the Addon to keep it simple, i'd create a fork of it

[Kehom]

I will think about this feature because the described use case seems interesting, specially the separation of which parts of the transform are going to be performed.

Regarding the possibility to link to other nodes I will have to think very carefully about how to implement it. The addon I'm currently working on requires this kind of linking (for one of the features) and it took me a lot of time to make it properly work without resulting in errors all around the place. Although admittedly it should be simpler in the case of the smoothing addon.

Based on the errors I had to deal with I will experiment a little here and depending on how things go, push the modifications to the repository.

[Kehom]

OOook. The last commit (1da12c1b2109c29d4d8238744f594e13c5ace015) I have pushed is majorly flawed. The fix to it will unfortunately break compatibility with the push itself. Depending on how things are done, it will probably result in some errors on existing projects. The thing is, I realized a bit too late about the scale within the transforms. Working on the fix now.

Regarding your idea of allowing the smooth nodes to be detached from the target and the smoothed nodes, I'm still thinking about one way to implement it without complicating usability. It will probably result in a third node though.

[fairhat]

A third node was what i was thinking of. Similar to the SnapEntity which is not the actual GameObject being transformed in the world but just a Package transferring state from Network to Entity (as far as i understand)

Maybe a "register(Node)/unregister(Node)" function on the Smooth Node could be a way to bind listening nodes? E.G. On the Smooth Node you only say which node should the data be "copied" from (eg parent) and nodes that want to listen to this would call register(self) ONCE (_ready) on the Smooth Node - which then knows which Nodes to update on every _process.

Btw i was able to just do the rotation myself by looking at your code so which was easier to apply to my usecase instead of changing the whole library for it

[Kehom]

I'm still considering the "edge" cases of the extra node. Allowing it to follow a selected target is, in a way, the easy part. Allowing it to affect node(s) that is(are) not child(ren) of the new node is a problem. For the moment lets call this extra node smooth_helper (that's not exactly how I will call the node, but for the sake of this discussion it's enough). This smooth_helper is added into the scene then the target to be followed is selected (lets call this node target. A few checks are done to verify if the target is valid and can be followed. You then select another node to be affected by smooth_helper (lets call it affected). The smooth_helper will interpolate the selected target transform data and apply to affected. But what if affected is a child of target and it does have a translation relative to target? This also has to be taken into account. While I do have some ideas on how to implement that, I honestly don't know if it would be really useful to be worth implementing such a thing. Would it be useful?