Is there any chance of the Axes to Rotation node landing in 4.1?

Introducing Quaternions properly into Geometry nodes is fantastic, but in my experience working with Quaternions, creating a Quaternion via two axes in this way is the most common operation, and I think itâ€™s really important to have this node.

Thank you for the reply, I hope we can get that node in 4.2!

Although 4.1 is feature locked, there seem to be lots of inconsistencies with rotation sockets, that I hope can be improved before release:

We have Quaternions now, but the term â€śRotationâ€ť is being used to refer to Eulers and Quaternions interchangeably which doesnâ€™t make sense.

It looks like most of the nodes have been updated to officially refer to the new Quaternion type as â€śQuaternionâ€ť which I think is good, but the following nodes still call it a â€śRotationâ€ť socket type:

Simulation input / output

Repeat Zone input / output

Mix

Switch

Group Input

Group Output

The following nodes use the new pink Quaternion socket, but the default value inputs and outputs are Eulers each with XYZ inputs in degrees:

Rotate Vector

Rotate Rotation

Rotation to Axis Angle

Rotation to Euler

Rotation to Quaternion

Other feedback:

Align Euler to Vector - the input and output sockets are called â€śRotationâ€ť but they are both still using the Vector type. Should these sockets be renamed to â€śEulerâ€ť instead of â€śRotationâ€ť? (Euler to Rotation node already uses this convention).

I feel like â€śRotation to Quaternionâ€ť, should be called Separate Quaternion or Spearate WXYZ
and â€śQuaternion to Rotationâ€ť should be called Combine Quaternion or Combine WXYZ

I think we need a Constant Quaternion node to match the other constants
It would be nice to get a Quaternion option in the Random Value node

Vector Rotate node should have a quaternion mode.

Also, question: does the Mix nodes blend via Linear Interpolation or Spherical Linear Interpolation (Lerp vs Slerp)?

â€śRotationâ€ť is the name of the socket type. Itâ€™s designed so that you donâ€™t have to know how rotations are stored internally. And in the future it might even depend on which formats are fastest for each computation.

The rotation sockets still have XYZ Euler controls on input sockets because thatâ€™s usually the most intuitive way to control the values by hand, and we had to choose something.

The attribute type is â€śQuaternionâ€ť because for attributes itâ€™s important to be specific about the actual type used for storage.

â€śAlign Euler to Vectorâ€ť indeed doesnâ€™t have an equivalent yet.