Plank & beam rotation axes?

Either I am overlooking something too obvious to find it mentioned or there something strange in how planks and beam rotate with the New Construction System.

It seems to me that:

A) With the [Up] and [Down] arrows, the element rotates around its own X axis

B) With the [PgUp] and [PgDn] arrows, the element rotates around its own Z axis

C) With the [Left] and [Right] arrows, the element rotates around the World Y axis

_______________________________

[ I ] Steps to reproduce B) and C):

1) Start with a beam at reset rotation ([BackSpace]) and default setr
2) Rotate it of 45° around the Y axis (3 x [Left]): the element rotates around the World vertical, with coincides with the element Y axis (no other rotation yet)
3) Rotate it with the [PgUp] or [PgDn] (Z axis): the element rotates around its own Z axis
4) Reset the rotation ([BackSpace])
5) Rotate the element of 45° around the Z axis (3 x [PgDn])
6) Rotate it with the [Left] or [Right] arrows (Y axis): the element still rotates around the World vertical (World Y axis) as in 2), and not around its own Y axis.

By replacing [PdUp]/[PgDn] (Z axis) with [Up]/[Down] (X axis), one can see that also A) above is true.
________________________________

[ II ] Another example:

1) Start with a beam at reset rotation ([BackSpace]) and default setr
2) Rotate it of 90° around the Z axis (6 x [PgDn])
3) Rotating it with either [Up]/[Down] (X axis) or [Left]/[Right] (Y axis) rotates around the same axis: the object X axis and World Y axis.

Now, rotation around two different axes should not be the same, should it?

My mistake or an inconsistency in the code?

Quote from botchikii

Just try to reproduce that and all work like intended (tested few times with changing position too)

Not sure to understand.

1) What should I reproduce to have everything working as intended?

OR

2) You reproduced my description and your results match mines? In that case, I doubt, the difference between A) and B) on one side and C) on the other side was "intended"; to me seems a structural inconsistency, which makes some orientations impossible (or very hard) to obtain.

@botchikii: selon le forum, tu es français (ou quand même en France); tu peux écrire en français aussi, si tu préfères; je croix que j'irai répondre en anglais, parce que mon orthographe française n'est pas grand chose...

"the final orientation of the beam is the same": exactly, this is the problem! It should not be the same. Rotations are not (should not be) commutative; if they are, something is going wrong. What I suspect is that X and Z rotations are applied to one coordinate system, Y rotation to another.

Just for clarity, I have added another example at the OP.

This issue is flagged as fixed, but I still see it in the latest version.

Am I missing something? Really nobody else notices this issue or is affected by it?

@red51: Thanks for the reply, I appreciate you spending time on commenting on this topic. I am not very familiar with the terminology used in game field, so I may fail to understand some detail, but I still believe there is a bug somewhere, rather than the choice of a given implementation over another.

Your description seems to imply that intrinsic rotations (i.e. relative to the reference frame being rotated, or "object coordinates") are used rather extrinsic ones (i.e. relative to the global, fixed reference frame, or "world coordinates"). I'll assume this to be true.

(Side note: as you quote three rotations around three different axes, while the "classical" Euler formalism only uses two, the first and the third rotation being around the same axis, it seems to me we are actually dealing with Tait-Bryan angles, but I'll assume them as just a variant of the Euler formalism).
______________________________

A) Euler angles should be able to represent any orientation with three appropriate elemental rotations. However, I have been unable to achieve the object orientation which can be described as:

0) the object is initially aligned with the world reference frame (grey outline)
1) rotate the object around its Z axis by, say, 45° (black outline)
2) rotate the object around its Y axis by, say, 45° (red outline)

as depicted by:

This orientation seems impossible to achieve with the current implementation. Possibly, I didn't try hard enough and I would be glad if somebody could find a way to do it, but so far this does not seem to be a complete implementation.
_____________________________

B) If intrinsic rotations are used, they should be used all over the place and, as they are "played back" in a specific order (Y - Z - X), generally different form the order in which they are created (in my example above they are created in the order Z - Y), the latter order should be converted into the former.

I'll try to explain myself elaborating on the example above.

0) Step 0 (initial rotation) can be described with the Tait-Bryan Y-Z-X angles as y = 0, z = 0, x = 0.

1) Step 1 (rotation around the object Z axis) can be described as y = 0, z = 45°, x = 0.

2) Step 2 (another, second, rotation around the object Y axis) cannot be represented as y = 45°, z = 45°, x = 0, because this represents a different final orientation in which the Y rotation is applied first, as per your description.

The actual representation of step 2 as a yaw - roll - pitch (Y-Z-X) sequence of elemental rotations should be derived by applying step 2 to step 1 obtaining a cumulative rotation matrix (or quaternion) from which to work out the individual Euler (or Tait-Bryan) angles in the chosen sequence (Y-Z-X).

I hope this might explain a bit more the issue I am facing.

FOLLOW-UP

@red51: I just made a little jMonkey project to play with 3D rotation calculations and this is a summary of my findings. I hope it further explains my point of view. All values are taken from jMonkey own calculations and getters.
_____________________

1) An initial rotation of 45° around the Z object axis is expressed by:

1a) the rotation matrix
| 0.71 -0.71 0.00 |
| 0.71 0.71 0.00 |
| 0.00 0.00 1.00 |

1b) the quaternion <0.00 0.00 0.38 0.92>

1c) the 'Euler' angles 0.00X 0.00Y 0.79Z
_______________________

2) An additional rotation of 45° around the object Y axis yields:

2a) the rotation matrix:
| 0.50 -0.71 0.50 |
| 0.50 0.71 0.50 |
| -0.71 0.00 0.71 |

2b) the quaternion <-0.15 0.35 0.35 0.85>

2c) The 'Euler' angles -0.62X 0.96Y 0.52Z

It is clear that adding a second rotation around an axis does not simply add to one of the 'Euler' angles, but affects all of them.
_________________________

Just for reference, a single rotation of 45° around the object Y axis yields:

*) the rotation matrix
| 0.71 0.00 0.71 |
| 0.00 1.00 0.00 |
| -0.71 0.00 0.71 |

*) the quaternion <0.00 0.38 0.00 0.92>

*) the 'Euler' angles 0.00X 0.79Y 0.00Z

Thanks for the encouragement, @yahgiggle! Still, if you know a way to achieve this result and would like to share, I would be very grateful!

@yahgiggle: in addition, the example [II] in the OP seems to implies that the current implementation suffers from gimbal lock, which isn't a good thing and might imply that, no, not all orientations can be achieved.

@yahgiggle: thanks for the reply and for the time spent on this.

From your screen shot it is not easy to appreciate angles, so I may be wrong, but the rotation around the beam Y axis does not look as it be precisely 45°.

If you could list the individual rotations you did to reach the shown orientation (I don't think they are covered by some kind of intellectual property ), I could reproduce and tell if we are speaking of the same thing or not.

@yahgiggle & @Deirdre: I appreciate the time spent by those (few) who seem to care about this point which, if true, would be a serious flaw in a fundamental part of RW.

However, I am forced to note that so far nobody posted a list of steps to reach the test orientation I described above; this by itself would show that I am wrong to worry (and would teach me something I could not discover by myself).

And sorry but an approximation is not enough; even with the default setting of 15°, it should not be a problem to achieve angles which are integer multiples of it, as 45° is (yes, there might be internal floating point rounding errors, but if they show through in a process that, in the optimal implementation, is made of just TWO steps as my test orientation does, then something else is seriously screwed).

I am also surprised that nobody seems to care about the case I describe in part [II] of my original post. In my point of view, this alone shows that here something is not working as it should.

So as far as I am concerned, the issue is still pending (and incidentally, I know how to use str/l/p as it can be seen in the summary of their functioning I posted a little while ago).

Of course, thanks again for all contributions!

EDIT: Cross-posting!!! Deidre posted a step list while I was writing this post. I'll check it ASAP! Thanks!