Plank & beam rotation axes?

Oh well, this is going to be long and boring; please bear with me... I have warned you If nothing else, if you care, please read at least the final comments. Thanks!

Thanks to @Deirdre for the steps she provided. I had a look at them, re-played them locally and I learned a few interesting things.

Step 0: a beam (0.5m wide, 3 m long, if you care) at default, un-rotated orientation. This is how it looks along the Z axis (I tried to take the screen shot as orthogonally as I could and I overlaid the axis names for added clarity):

and along the X axis:

So far nothing strange.
________________________________________________________________

Step 1: 3 x UP arrow (according to Deirdre list). This should mean +45° around the X axis (currently, as the beam is not rotated, the axes of the object and of the world coincide). View along the Z axis:

and along the X axis:

Everything as expected!
______________________________________________

Step 2: 3 x PgDn arrow: this should mean -45° around the Z axis. View along the Z axis:

And along the X axis:

and also along the Y axis (looking down):

Now things start to look strange. From the screen shots a sharp eye may be needed, but while viewing the rotation on the screen, it is rather clear that this rotation is neither around the object Z axis or the world Z axis; it looks like around some undefined axis which presumably depends on the previous rotations.
__________________________________________________

Step 3: 4 x Left arrow: which should be -60° along the Y axis. This is rather clearly the world Y axis, not the object axis (or any variable axis resulting from 'obscure' calculations). View along the Z axis:

View along the X axis:

And view along the Y axis, showing that the object is not actually parallel to the XY plane::

Finally, a detail showing that the 'tilting' of the beam around ITS OWN Y axis is far from being 45°:

_________________________________________

Comments:

1) The implementation, instead of the X, Y, Z axes (as described in the F1 help screen), rotates the object around axes largely counter-intuitive and very hard to visualize; they are surely the result of internal calculations, but from the user perspective look arbitrary.

For what is worth (and from some @red51 comments above), I suspect that the implementation simply alters the X, Y or Z value of an internal representation in Euler angles, rather that implementing rotations consistently intrinsic or extrinsic. A hint might be the suspect of gimbal lock shown in OP [II], as an Euler angle representation may suffer from it.

2) By small (non-intuitive) corrections, the intended orientation might perhaps be obtained (still not sure, though). Each correction will however affect the orientation of the object around all the 3 axes and will require further corrections. It is not a matter of having half degrees available, it is a potentially never ending chase of corrections after corrections.

3) JME directly supports consistent intrinsic rotations and one could wonder which reason is strong enough to ignore this easy support. If Euler angles are preferred to persistently store the rotation data of an object, as they are the most compact representation (sparing one floating-point value over quaternions and 6 f.-p. values over matrices), the conversion could happen when writing the data to a file.

4) I am still not sure that implementation is logically complete (the suspect of gimbal lock is a strong hint that some orientation cannot be reached); right now, it definitely looks operatively incomplete, as a simple case like the one I pursued in this thread is proving very hard to reach, possibly impossible to reach with the needed precision.

5) I am glad that all of this seems not to affect many users (those looking for 'balls', as @yahgiggle says ); still the eventual lack of precision does affect architectural realisations.

6) I am aware that angles, quaternions, Euler angles and so on are not glamour nor make for a popular update; still, the building capabilities of RW will remain as one of its strong points and I feel that this matter should be raised a bit in priority.

Quote from Deirdre

@Miwarre Your explanations are very complicated for me. I'm a builder, no mathematician, no architect, I'm only playing with one, and trying to translate it in my language and in my understanding, but I'm trying to help as well as I can do. When I see the pictures I can imagine it better.
I have the wish for more precision, more measurements, bigger glass size for instance. Who really needs 0,5° differents, if he wants to build no ogival or absolutely accurate.

Thanks for the reply @Deirdre. I fully understand you; the whole matter was much like black magic for me too, when I started. So, I'll try to elaborate on the final comments of my previous post.

1) Precision is not optional: if you don't need it and it is there, it does no harm; but if you need it and it is not there, you are out of business. Also please note that I am not speaking of residual approximations: the beam shown in my previous post is several degrees off, both along its own Y axis (as shown in the final detail screen shot) and along the world Y axis (as shown in the penultimate picture). I'll make a few examples, not theoretical but from my actual experience with RW:

1a) The beam we are mistreating all along this thread might be the corner beam of a, say, 4-sided roof as in:

Once I needed to use it, rather than in "square section" as shown here (with its edges two above and two below), in "diamond section" (i.e. with its edges on top, middle left, middle right and bottom, i.e. rotated by 45° around its length (Y) axis): I had to give up because the intended orientation was practically impossible to obtain without it being visibly off the mark.

1b) Another time I was working with dormer-windows:

but the junction between the roof side slope and the dormer-window roof slope was impossible to reach decently; so I had to 'cheat' make both as larger rectangle and close the access to the inside of it, as it was a mess of intersecting rectangles:

1c) Then, I tried with 'Gothic' tracery windows, just a simple one; I hoped to use beam again in "diamond section", but again the result was a mess of mismatching beams, so I gave up again and resorted to "square section":

This are all practical cases, involving a limited number of pieces and not really in complex relationships to each other (at least easy to visualise).

2) Counter-intuitiveness: In the current implementation, the rotation commands rotate the object around non-evident -- and in several cases counter-intuitive -- axes: in general, neither the object OWN axes or the world 'global' axes, which are the reference systems that a user can visualise more easily.

3) Incomplete?: I am not 100% sure of this, so I still add a question mark. However, the fact that nobody was able to solve the relatively simple problem I posed at the start of this thread makes quite serious the hypothesis that the current implementation is incomplete and does not allow to reach all the possible orientations a solid body can assume.

I also ask to try the example I describe in section [II] of my first post: it shows a case when one rotation around one of the possible axes is lost, as this also is a serious hint about the potential incompleteness of the current implementation.

4) Unnecessary: Above anything else, all of this is unnecessary, as far as I can tell. Object-relative reference systems are very common and relatively easy to implement; they allow to add rotations which are really and precisely around the object OWN axes (also called intrinsic rotations), which are much easier to visualise, as you have the object before your eyes. They can also be implemented in a way which is really complete (demonstrably).

They would allow to easily (at least much more easily than now) and precisely reach any orientation you can visualise. Under these context, the 1° degree precision now available would be enough for most objects, surely for the 3 smallish objects I show in the pictures above.

Now, jMonkey (the framework RW is developed upon) comes with built-in support for them and I cannot think of a reason strong enough for NOT using it, as RW apparently does now.

Finally, while I am aware that the attentions of users is currently toward other aspects of the game, the building system is and will remain one of the RW strong points and dragging along the (unnecessary) weak points I describe above does not seem to me 100% wise. So, I feel the priority of this aspect should be raised.

Thanks for reading another over-long post! If I made errors or arbitrary assumptions, I will be glad to learn more!

At this point, I think to be ready to formalise my

1) Given a reference line

1a) parallel to one of the coordinate planes (XY, YX or ZX; the example shows a green beam parallel to the XY plane)

2) and slanted of 45° (the two blue beams of equal length show that the green beam is indeed slanted of 45°)

the goal is to place

3) one single (solid) beam rotated of 45° around the reference line (here outlined with red beams);

The 45° rotation requirement is considered satisfied when the middle vertices of the beam start and end sides are horizontal:

4) The beam shall be at least 4 blocks long and of the maximum width a beam can have.

5) The positioning and rotations shall look precise at visual inspection when seen from a distance of at least 4 blocks from any of the beam points (visible precision at super close inspection distance is not required)

6) Proof of solution shall be the list of rotation commands issued to achieve the requested orientation from the default upright orientation of a beam (as set by pressing [Backspace]).

7) The prizes for anyone solving the problem will be:
- my ever-lasting gratitude
- the satisfaction to be proven "Master of Rising World Construction"!

Note: in the pictures above, the red beams outlining the goal beam are not correct and the start and end 'squares' are actually rhombi. This is because I am currently unable to achieve the request orientation and I believe it cannot be obtained with the current RW implementation.

I hope to be proven wrong!

@red51, WOW! I am very grateful that, in the midst of releasing an update, you found the time to look into this matter!

Precision:
I am aware that any floating point operation involves roundings and that this kind of things requires several steps often with trigonometric functions and so on. One more reason for finding a way which requires as few steps as possible to reach the intended result!

Also, I think the level of "required" precision is visual more than instrumental: luckily, RW does not have (nor does it requires) goniometers! If it looks precise, it is precise enough. As an example, the orientation of your beam is precise enough, while the final orientation of the beam in my post near the top of this page is visibly non-precise.

Your example:
your example shows that the test orientation I though impossible to reach can be reached indeed! This, for me at least, is great new, as it falsifies a hint that the current implementation might be incomplete (and, again, thanks for finding the time to work on it!!!).

However (there was a "however" coming... ), at the moment your example cannot be properly replicated, without a list of steps. As you say: "you have to experiment with the x and z rotation a little bit". I may easily be wrong and I will try (for sure you know RW much more than I do!), but I have the feeling that the list of steps would be rather long for something which ultimately can be described at the sum of two rotations.

I believe this raises some concerns of actual usability (and of user experience, to quote a term now fashionable) for a wide range of projects (three of them I have described above).

Couple of details:

Quote from red51

all rotations are basically intrinsic rotations, but they don't work exactly as you may expect. [...] When rotating a construction element (while placing it), you basically just increment (or decrement) the particular rotation values (rotation around x, y and z axis).
When converting these euler angles to a quaternion,...

Sorry, but I beg to dissent. When increasing / decreasing one of the three values of an Euler (or Tait-Bryan) representation, in general the rotation applied is not an equivalent intrinsic rotation around the corresponding object axis.

This might be true, occasionally, for instance if the other two values are 0, but not in general; I think this to be clearly shown in this my previous post of this same thread. In other words, if <a, b, c> represents a rotation in Tait-Bryan angles, <a+n, b, c> does not necessarily correspond to adding a rotation of an angle n around the object X axis (and similarly for the other axes).

Quote from red51

since we're going to rework the construction system in the future anyway, we will check out if there is a more convenient way for the rotations

I am sure the dev team has all the required expertise, but if it can be of any help, I can try to work out the math involved in adding a real intrinsic rotation to a Tait-Bryan representation.

Quote from dagoline

.... but you all know that RW is a building/survival game not a CAD programm?

Indeed! Did you mention building?