Add Pose node

[ad-daniel]

This PR aims at introducing a new node named Pose which basically inherits from Group, adding only the translation and rotation field. The Transform node inherit from Pose adding the scale node.
All Solid nodes inherit from Pose and not from Transform any more.
The Transform node may only contain Shape, CadShape, Group, Pose or Transform nodes in its children list.
This has 3 mains advantages:

• It makes it clearer for the end-user that it is not possible to scale Solid nodes (however PROTOs of Solid nodes may still have a working scale parameter, which may be either scalar or vector).
• It simplifies of the management of Solid nodes and bounding objects.
• It simplifies the management of Device nodes (which inherit from Solid).

Scaling Solid node is not something realistic as in the real world, it is not possible (or very difficult) to scale objects, whereas it is super easy to change their translation and rotation.

See the most relevant update documentation pages:

• https://cyberbotics.com/doc/reference/transform?version=feature-pose-node
• https://cyberbotics.com/doc/reference/pose?version=feature-pose-node
• https://cyberbotics.com/doc/reference/solid?version=feature-pose-node
• https://cyberbotics.com/doc/reference/group?version=feature-pose-node

[BenjaminDeleze]

Seems good to me

[omichel]

@stefaniapedrazzi and @ygoumaz: can you please also review this PR again before I merge it?

[stefaniapedrazzi]

I didn't find any major issue.

• However, I'm not sure it is good to allow to transform a Solid node into a Transform node (as in the example of the Table described by @BenjaminDeleze) if the Solid has Solid children because unexpectedly all the children are removed.
  I think it would be more user-friendly to prevent this operation.

• The c3d_viewer.py controller is throwing an error because it imports a C3dBocyRepresentation with the scale field that has been removed.

[omichel]

However, I'm not sure it is good to allow to transform a Solid node into a Transform node (as in the example of the Table described by @BenjaminDeleze) if the Solid has Solid children because unexpectedly all the children are removed.
I think it would be more user-friendly to prevent this operation.

Yes, we discussed this point with @BenjaminDeleze yesterday and I believe we could indeed remove this option. However, since there is a warning about loss of information during this operation, I believe it is okay for the user. And also, it seems odd to allow users to transform a Transform into a Solid, but prevent the other way round. For example, with the BiscuitBox, it works better than with the Table because the children of the Solid are Pose nodes. Hence, in that case, you can transform the BiscuitBox to a Solid, and to a Transform and back to a Solid without loosing the geometries (but you will loose the physics, boundingObjects, etc.).

[stefaniapedrazzi]

Loosing boundingObject or physics is expected and not as problematic as loosing all the children information.
Personally, I don't think that the info is enough in this case and should be more specific.
It is not possible to undo a node transform so it is really annoying to revert it.
Even more because this is a new behavior and was working the same in previous versions.

[ygoumaz]

I agree with @stefaniapedrazzi that the warning should at least be more specific and list the information that will be lost, in particular children Solid objects.

[omichel]

I am improving this warning...

[omichel]

I just fixed the two issues reported by @stefaniapedrazzi. I guess we can merge it now?

[ygoumaz]

When changing the scale of a simple Transform node, it affects the translation and rotation arrows in the view in a wrong way that is not present in develop. It makes them unusable.

[stefaniapedrazzi]

When changing the scale of a simple Transform node, it affects the translation and rotation arrows in the view in a wrong way that is not present in develop. It makes them unusable.

Just for note, I could reproduce similar issues on master/develop branches ( reported here #6063).

[ygoumaz]

Ok, I still can produce a different behavior between both branches:

1. Adding a Transform at the root of the scene tree.
2. Changing the scale in develop doesn't affect handles, but in feature-pose-node, the handles are scaled too.

However, this additional behavior may be a side effect from the existing bug and not directly related to the addition of the Pose node. We may merge the PR and fix it when addressing #6063.

[omichel]

However, this additional behavior may be a side effect from the existing bug and not directly related to the addition of the Pose node. We may merge the PR and fix it when addressing #6063.

Yes, in any case #6063 needs to be fixed and it will change this code. So, I agree we can merge this PR and fix #6063 in a separate PR (this one is already very big).