Standardize the order in which transformations are applied in Sofa components

[marques-bruno]

There is no unified way of applying transformations in current SOFA components (rotation > translation > scale / translation > scale > rotation ...) even though the order matters a lot in this case.

[marques-bruno]

@damienmarchal if you're motivated too

[damienmarchal]

well... for Sofa 17.12 or 18.06 :)

[maxime-tournier]

The natural order is translation/rotation/scaling.

That being said, specifying such transformations inside Components is a bad idea as this complicates and duplicates the code. They really should be performed using Engines or Mappings.

[epernod]

So we agree that even if the object is not at the scene origin, making a rotation should only rotate the object around its center of gravity and not over the whole scene ?

something like this (x is the origin): x---------M 180 rotation give x-------------W and not: x---------M give W---------x

[maxime-tournier]

This is how Rigid behaves, so I would agree.

But really, coordinate transformations should go in Engines/Mappings where they can be performed in any order depending on what the user needs.

[JeremieA]

Alternate proposal (in agreement with Maxime's comment): deprecate custom transform codes within components and always rely on TransformEngine. I think that was already the plan, but maybe it should be more explicit. This is also linked with the deprecation of the sofa::helper::io::Mesh loaders, as TransformEngine cannot be used when a component is loading the mesh directly through these classes (see #42, #118). Note that using external engines is more verbose and a little bit more work to use, but it brings additional benefits such as a standard transformation order, an easy way to chain multiple transform in whichever order is wanted, and the (very useful for us) ability to apply the same translation to multiple meshes or associated info related to the same virtual object, such as both visual mesh(es) and collision mesh(es) of a tool, or when globally changing the frame of reference for the whole scene.

[epernod]

As mention above, we will work on that task using engine as soon as the work on DataGraph has started.

[damienmarchal]

I really suggest to really start deprecating all the hard coded transformation code in component for release 22.06 for complete removal in 22.12 or 23.06 :)

This is relatively trivial to do it just requires an explicit deprecation workflow and a planning for that.